DMARC: Quickly spot misuse of your email domain
IONOS editorial team6 mins
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.
The challenge: protect domain reputations
To protect against phishing attacks, several different security mechanisms were introduced:
- SPF (Sender Policy Framework), to check the sender address of emails
- DKIM (DomainKeys Identified Mail), to check the authenticity of emails by means of digital signatures
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.
The solution? DMARC
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 idea behind DMARC
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:
- Reject the suspicious message,
- Quarantine it
- Accept it and simply report it to the domain owner
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.
Content of a DMARC record
| 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: - fo=0: If a message fails both checks (SPF and DKIM). This is the default setting. - fo=1: If a message only passes one of the checks (SPF and DKIM). - fo=d: Report DKIM as failed if the signature was incorrect, even if the key was correct. - fo=s: Report SPF as failed if the SPF evaluation failed for some reason, even if the SPF entry in the header and the DNS record match. Other options can also be added to the DMARC record, separated by colons. |
| rf | Reporting format: - afrf: Authentication Failure Reporting Format - iodef: Incident Object Description Exchange Format The default setting is afrf 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: - s=Strict: The domains must be an exact match, e.g. martin.mann@test.com - r=Relaxed: Sub-domains are also included, e.g. martin.mann@newsletter.test.com |
Setting up a DMARC record
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 (DKIM-Domainkeys), 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.
Adding the DMARC record to your name server
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.
Checking the DMARC record
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.
Setting up an email address for reporting
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.
