DMARC records

Last updated: 5 April 2021

DMARC is short for Domain-based Message Authentication, Reporting and Conformance. As the name suggests, DMARC records enable a few different things:

• Tell receiving mail servers what to do with an email if the SPF and/or DKIM checks fail.
• Check if the domain the email was sent from is the same domain shown in the email’s ‘From’ header.
• Make it possible to receive reports on email deliveries and failures.

Put simply, you can think of a DMARC record as a DNS record that extends the functionality of SPF and DKIM records. One problem with SPF and DKIM records is that receiving mail servers don’t know what you want them to do if one or more checks fail. DMARC solves that issue, as the record tells receiving servers exactly what should happen. And because you define the rules you have control over how receiving servers deal with SPF and/or DKIM failures.

At the same time you – the sender – can receive reports on email deliveries and failures. Although most people don’t use the reporting option, it is useful to be able to monitor outgoing emails.

Adding a DMARC record.

You can add a DMARC record via cPanel:

• Select the Zone Editor
• Click on the Manage link for your domain
• Click on the drop-down arrow to the right of the Add Record button and select Add DMARC Record

Image: Adding a DMARC record via cPanel’s.

The Zone Editor automatically creates a name for the new record (here _dmarc.example.net.), and for the record’s value it suggests using the None policy. Which brings us to the first DMARC element…

DMARC Policies

A DMARC policy tells receiving mail servers what they should do with an email if the SPF or DKIM check fails. There are three options:

• None tells the server to accept the email. This option is also known as the reporting only policy.
• Quarantine tells the server to quarantine the email. In practice, this usually means that the email is delivered to the recipient’s junk folder.
• Reject tells the server to not deliver the email to the recipient.

It might seem odd that None is the default policy. There is a good reason for that though. Because DMARC can report on email deliveries you can first set the policy to None and then check the reports to see if any genuine emails would have been rejected. In other words, you don’t have to dive in head-first. Instead, you can first create a basic DMARC record and then gradually tweak the policy.

If your SPF and DKIM records have been set up correctly there shouldn’t be any accidental email rejections. However, there are many edge cases (such as the issue that SPF often doesn’t work well with email forwarding). It is therefore recommended to start with the None policy, and to only switch to a stricter policy when the email reports show there are no issues.

Other DMARC options

DMARC has a lot more options than just the policy. You can click on the Optional Parameters link to view all options.

Image: The DMARC options shown in cPanel’s Zone Editor.

Most of the default options are sensible choices and you probably want to keep them as they are. The only exceptions are the Send Aggregate Mail Reports To and Send Failure Reports To options. You can use these options to get information about emails sent from your domain. I will discuss these two options first and then briefly explain the other optional parameters.

Report email address

As said, when you use DMARC you can choose to receive aggregate reports and/or failure reports.

• Aggregate reports contain information about the domain that was used to sent email, the sender’s IP address and the number of emails that were sent.
• Failure reports are also known as forensic reports and include additional information, such as header information (the ‘From’, ‘To’ and ‘Subject’ fields). These reports are only generated when an email fails the DMARC checks.

By default the two parameters are blank, which means that no reports are sent. If you want to receive either or both reports then you can enter one or more email addresses in the Send Reports To fields.

Note that you should enter the email address in the format ‘mailto:<email-address>’. For instance, if you want to receive reports at mail@example.com then you enter the email address as ‘mailo:mail@example.net’.

See the DMARC reports page for more information about the reports.

Subdomain policy

The Subdomain policy section has the same options as the Policy section. This section is only relevant if you sent emails from a subdomain such as sales@shop.example.com (here the subdomain is shop.example.com).

DKIM and SPF Mode

DMARC checks if the domain an email was sent from is correct. It does this by checking if the domain shown in the email’s ‘From’ header matches. For instance, when I sent an email from mail@example.net then the domain example.net should show in the ‘From’ header. If the ‘From’ header shows a different domain, say ‘paypal.com’, then it is likely that the email address has been spoofed and that the email is spam.

There are two modes for both DKIM and SPF: Relaxed and Strict:

• Relaxed mode accepts emails from either the domain or a subdomain.
• Strict mode requires that the domains match exactly.

In Relaxed mode, which is the default option, an email from mail@example.net that has the subdomain shop.example.net in the ‘From’ header would pass. However, the same email doesn’t pass in Strict mode.

Percentage

The Percentage option specifies the percentage of emails from a domain that should be checked by receiving mail servers. This is an optional tag that was added to the DMARC specifications to allow domain owners to gradually roll out DMARC policies. We recommend keeping the default value (100). To test how DMARC affects email delivery it is better to start with the None policy, as discussed above.

When to generate failure reports

The Generate Failure Reports When option specifies if a failure should be reported when all checks fail or when any checks fail. The default option is to only report failures when all checks fail.

Report format

DMARC reports can be sent in one of two formats. AFRF (Authentication Failure Reporting Format) is the most common format and recommended.

Report interval

By default, aggregate reports are sent every day (86,400 seconds), while failure reports are sent in real time. You can change the reporting interval for aggregate reports to a lower value. However, the report interval is likely to be ignored – in all likelihood you will still receive your reports daily.