Setting up DMARC

How does DMARC (Domain-based Message Authentication, Reporting and Conformance) work?

To activate DMARC, store a DMARC policy in the DNS zone of your domain. As with SPF and DKIM, the DMARC policy is stored in an RFC-standardised TXT entry - DMARC entry for short.

The policy contains information on which checks must be carried out by the recipient - i.e. SPF and/or DKIM. It also specifies what the recipient should do if the checks fail: accept anyway, place in quarantine or reject.

The DMARC policy also specifies email addresses to which reports are to be sent - the R in DMARC stands for reporting. These reports are generated by all servers on the Internet that support DMARC when receiving emails and have received emails from the respective domain. To prevent the amount of data generated by the reports from becoming too large, the DMARC policy can also specify the percentage of emails for which a report is generated. Furthermore, the reports are collected and sent to the respective reporting address only once a day by default.

What does a DMARC entry look like?

The TXT entry used for a DMARC policy can contain the following fields:

Field

Meaning

Examples

v

Version of the DMARC entry

v=DMARC1

p

Policy on how to handle emails from the main domain whose authentication fails

p=none: do nothing p=quarantine: place in quarantine p=reject: reject

sp

Policy on how to handle emails from the main domain whose authentication fails

p=none: do nothing p=quarantine: place in quarantine p=reject: reject

pct

Percentage of emails to be reported according to the DMARC policy

pct=100 (default)

rua

Defines whether and to which email address an aggregated report on the emails received should be sent.

rua=mailto:report@example.com

ruf

Defines whether and to which email address a forensic report on the emails received should be sent. This contains all the details of the respective emails. Note data protection!

ruf=mailto:report@example.com

fo

Failure Reporting Options. Detailed setting for when emails are to be reported. Only applies in conjunction with "ruf".

fo=0: SPF and DKIM have failed (default) fo=1: SPF or DKIM have failed fo=d: DKIM is considered to have failed if the signature is incorrect, even if the key matches. fo=s: SPF is considered to have failed if the SPF evaluation fails for any reason, even if the SPF entries in the header and DNS entry match.

rf

Reporting format. The file format for the reports. Only applies in conjunction with "ruf".

rf=afrf: Authentication Failure Reporting Format (Default) rf=iodef: Incident Object Description Exchange Format

ri

Reporting Interval. Frequency in seconds at which reports are sent.

ri=86400, i.e. once a day (default)

aspf

Adjustment mode for checking SPF

s=strict, i.e. strict. The 'MAIL FROM' address must be exactly the same as the Header-From address. Example: info@example.com r=relaxed, i.e. loose. It may also be a subdomain. Example: info@newsletter.example.com Further information can be found at mxtoolbox.

adkim

Adjustment mode for checking SPF

see above.

Examples of DMARC entries

Example 1

v=DMARC1; p=reject; fo=0; rua=mailto:dmarc-reports@example.com, mailto:dmarc@example.com

All non-authenticated emails are rejected here if SPF and DKIM checks have failed (fo=0). In addition, summary reports are sent to the addresses provided.

Example 2

v=DMARC1; p=none; sp=quarantine; rua=mailto:reports@example.com

No action is taken here for non-authenticated emails to the main domain; non-authenticated emails to the subdomain are placed in quarantine. Since fo=0 is the default setting, these rules apply if SPF and DKIM checks have failed, even if it is not explicitly stated.

WARNING: We strongly advise against permanently using the policy p=none. See also DMARC Policy: Why p=none is a bad choice (blog article)

Best practices for the introduction of DMARC

We recommend implementing DMARC in several steps. Start by simply monitoring your domain and gradually extend the policy to reject all emails that do not pass the DMARC check (p=reject).

Monitor

Start by monitoring a subdomain and/or main domain only and request regular reports. The use of SPF and DKIM is not yet required for this step. The corresponding DMARC entry could look like this:

v=DMARC1; p=none; sp=none; rua=mailto:report@example.com

Set up a quarantine policy

Before you carry out this step, you must have fully implemented SPF and DKIM. Once you have done this, implement a DMARC quarantine policy. This instructs receiving servers to place emails from your domain that do not pass the DMARC check in the spam folder. The corresponding DMARC entry could look like this:

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:report@example.com

Reject all non-authenticated emails

In the last step, you instruct receiving servers to reject emails from your domain that do not pass the DMARC check. The corresponding DMARC entry could look like this:

v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com

See also

Setting up SPF

Setting up DMARC

Sender reputation and email security - Part 4: Domain-based Message Authentication, Reporting and Conformance (DMARC) (blog article)