Fraudulent emails are becoming more and more dangerous. These days it is often very hard for recipients to distinguish them from genuine messages. They come from a known sender name and look just like normal newsletters and service emails. The DMARC verification mechanism – Domain-based Message Authentication Reporting and Conformance – was created to combat this threat.
To protect against phishing attacks, several different security mechanisms were introduced:
No domain owner wants fraudsters to send harmful messages or spam using their name, because this could lead to their domain being blacklisted and their emails being rejected (bounced) or treated as junk mail by lots of mail servers.
For example: Martin Mann owns the domain test.com and sends emails from the address martin.mann@test.com. If a fraudster were to use the email address sales@test.com to send spam messages, test.com would be blacklisted and messages from martin.mann@test.com would be blocked by incoming mail servers.
DMARC is short for “Domain-based Message Authentication Reporting and Conformance”. The concept was developed so that incoming mail servers not only check the authenticity of emails (using SPF and DKIM), but also trigger actions (pre-defined by the owner of the sender name) if an email fails the authentication tests.
The domain owner informs all potential email recipients (or rather, their mail servers) that he/she signs emails with DKIM and/or authenticates them using SPF. The servers are instructed to check all emails from the domain and to apply certain measures if a suspicious message (one that fails the checks) arrives. This is done by adding a special record to the domain zone file and the email header.
The incoming mail server checks whether the email can be authenticated by at least one of the protocols – DKIM or SPF. Any message that cannot be authenticated is treated as “suspicious”, because it might be fraudulent, i.e. from someone misusing the sender address for their own purposes.
The domain owner can instruct the recipient server to take one of the following actions:
The domain owner specifies the action to be performed in the DMARC record (see below).
DMARC also includes a reporting function. The incoming mail servers should send reports to the domain owner at regular intervals, giving details of any suspicious emails, i.e. emails that could not be authenticated using DKIM or SPF. The email addresses used for reporting are also listed in the DMARC record.
Incoming mail servers are not obliged to take the DMARC record into account. Consequently, even if no failed DKIM or SPF checks are reported, there could still be a problem.
Field | Meaning |
v=DMARC1 | Version des DMARC-Eintrags; DMARC1 meint die aktuelle Version. |
p= sp= | Policy that the receiving server should apply if the DKIM and SPF authentication checks fail: - none: Do nothing; process the message as usual. - quarantine: Quarantine the message. - reject: Reject (bounce) the message. “p” stands for the “policy” of the domain. “sp” stands for “sub-domain policy”. |
pct= | The percentage of messages to be processed according to the defined policy. This value is usually set to 100. |
rua | Defines whether incoming mail servers should send “aggregated” summary reports about suspicious emails, and where they should send them. (Warning: comply with data protection regulations!) |
ruf | Similar to “rua”, but refers to “forensic” reports that give message-level details about suspicious emails. (Warning: comply with data protection regulations!) |
fo | Failure Reporting Options; fine-tuning setting to define when messages should be reported: |
rf | Reporting format: |
ri | Reporting interval in seconds. The default setting is 86,400 seconds, i.e. 24 hours (once a day). |
adkim aspf | Settings for checking DKIM and SPF respectively: |
Before you can create a DMARC record, you need to have set up DKIM and SPF records, which can be done as outlined in the articles on DKIM, and SPF.
You can use an online tool to create a DMARC record, for example the DMARC Record Generator provided by EasyDMARC. You then copy the record to the domain zone of your name server as a TXT record with the sub-domain _DMARC.
It is recommended to set the policy to “none” (setting called “monitoring” in this tool) at first and monitor the reports you receive for a while to make sure that DMARC is working as you want.
Once you’ve created the DMARC record, you need to add it to your name server as a TXT Resource Record. To do this, log in to the hosting service for your domain and go into the domain settings (in the example above, the domain is gmx.com). In the “cPanel” hosting tool, the menu is called “Zone Editor”. Here you can create a new TXT record under the sub-domain name _DMARC. In our example, the full name for the DMARC record is _DMARC.gmx.com.
In the Help Centre there is a guide that explains how to configure a DMARC record for a IONOS domain.
Depending on the name server you are using, it can take a few minutes or a few hours until the DMARC record is published. If you want to check whether the record has been successfully published, you can use one of the online tools designed for this purpose, such as the DMARC Record Lookup Tool provided by EasyDMARC.
The easiest option is to set up a new email address in your domain solely for receiving DMARC reports. In our example: DMARC@test.com.
In order to receive the reports, the recipient domains need to be configured to accept these. This is also done using a DNS record. If you’re not receiving any DMARC reports, this could therefore be because the incoming mail servers are not configured for DMARC reports.
If you send an e-mail without additional security measures, it’s like sending a postcard: if everything goes as planned, the information should arrive unchanged and unread in the recipient’s inbox. However, if someone intercepts the card or the e-mail in transit, they can read the contents without any problem and make as many changes as possible. Just like you would use an opaque envelope to...
The Domain Name System provides functions that enable internet communication in the first place. The MX record, for example, deals with the disclosure of mail servers. In order to find out where your email must be sent to begin with, the mail server performs an MX record check: It inquires after the specific address. To illustrate this concept, we explain MX records to you with the help of an...
The network protocol CalDAV allows you to synchronize calendar data such as appointments and meetings on your PC, smartphone or tablet. The events are then displayed presentably in iCalender format and managed in a WebDAV environment. We’ll explain what CalDAV is exactly and how you can use it yourself.
Provide powerful and reliable service to your clients with a web hosting package from IONOS.
View packages
