Fraud­u­lent emails are becoming more and more dangerous. These days it is often very hard for re­cip­i­ents to dis­tin­guish them from genuine messages. They come from a known sender name and look just like normal news­let­ters and service emails. The DMARC veri­fic­a­tion mechanism – Domain-based Message Au­then­tic­a­tion Reporting and Con­form­ance – was created to combat this threat.

The challenge: protect domain repu­ta­tions

To protect against phishing attacks, several different security mech­an­isms were in­tro­duced:

No domain owner wants fraud­sters to send harmful messages or spam using their name, because this could lead to their domain being black­lis­ted 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 black­lis­ted and messages from martin.mann@test.com would be blocked by incoming mail servers.

The solution? DMARC

DMARC is short for “Domain-based Message Au­then­tic­a­tion Reporting and Con­form­ance”. The concept was developed so that incoming mail servers not only check the au­then­ti­city of emails (using SPF and DKIM), but also trigger actions (pre-defined by the owner of the sender name) if an email fails the au­then­tic­a­tion tests.

The idea behind DMARC

The domain owner informs all potential email re­cip­i­ents (or rather, their mail servers) that he/she signs emails with DKIM and/or au­then­tic­ates them using SPF. The servers are in­struc­ted to check all emails from the domain and to apply certain measures if a sus­pi­cious 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 au­then­tic­ated by at least one of the protocols – DKIM or SPF. Any message that cannot be au­then­tic­ated is treated as “sus­pi­cious”, because it might be fraud­u­lent, 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:

  1. Reject the sus­pi­cious message,
  2. Quar­ant­ine it
  3. 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 sus­pi­cious emails, i.e. emails that could not be au­then­tic­ated using DKIM or SPF. The email addresses used for reporting are also listed in the DMARC record.

Note

Incoming mail servers are not obliged to take the DMARC record into account. Con­sequently, 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 au­then­tic­a­tion checks fail: - none: Do nothing; process the message as usual. - quar­ant­ine: Quar­ant­ine the message. - reject: Reject (bounce) the message. “p” stands for the “policy” of the domain. “sp” stands for “sub-domain policy”.
pct= The per­cent­age 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 “ag­greg­ated” summary reports about sus­pi­cious emails, and where they should send them. (Warning: comply with data pro­tec­tion reg­u­la­tions!)
ruf Similar to “rua”, but refers to “forensic” reports that give message-level details about sus­pi­cious emails. (Warning: comply with data pro­tec­tion reg­u­la­tions!)
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 eval­u­ation 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: Au­then­tic­a­tion Failure Reporting Format
- iodef: Incident Object De­scrip­tion 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 re­spect­ively:
- 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@news­let­ter.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, 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.

Image: Screenshot of the DMARC Record Generator tool provided by EasyDMARC
In the DMARC Record Generator, you fill in a form to create the DMARC record shown in green at the bottom.

It is re­com­men­ded to set the policy to “none” (setting called “mon­it­or­ing” 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.

Tip

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 suc­cess­fully published, you can use one of the online tools designed for this purpose, such as the DMARC Record Lookup Tool provided by EasyDMARC.

Image: Screenshot of the DMARC Record Lookup Tool provided by easyDMARC.com
Looking up a DMARC record using a free tool, for example the domain nytimes.com

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 con­figured 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 con­figured for DMARC reports.

Go to Main Menu