DMARC: A practical guide

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is one of the three pillars of modern email security. DMARC works with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to protect against spoofing, spam, and phishing attacks.

DMARC adds reporting and policy to email security:

• DMARC reporting notifies administrators when SPF or DKIM configuration errors prevent delivery of legitimate email for the domain.
• DMARC reporting allows administrators to monitor spoofing attempts for the domain.
• DMARC policy fixes shortcomings in SPF and DKIM typically abused by spammers.

DMARC is specified in RFC 7489.

How DMARC works

The DMARC record for a domain appears in the DNS as a TXT record. The name of this record must begin with the label “_dmarc”, followed by the domain name. This TXT record contains the DMARC policy for the domain as a set of tags and values.

When a mail server receives an email, it extracts the domain from the From header. It performs a DNS TXT lookup to check if there is a DMARC record for the domain. The mail server then performs three checks on the mail:

1. Does the mail’s DKIM signature successfully validate the contents of the mail?
2. Did the message come from an IP address permitted to send mail for the domain by the domain’s SPF records?
3. Do the domains in the email’s headers pass “domain alignment” checks?

After performing these three checks, the receiving mail server is ready to apply the domain’s DMARC policy. This policy dictates whether the email will be delivered, rejected, or flagged as suspicious.

At the end of this process, the receiving mail server reports the outcome to the sending domain’s administrator. The final step is a critical part of DMARC. DMARC reports can be used to monitor for SPF and DKIM errors and to debug problems.

Mail header fields used by DMARC and SPF

SPF uses the “Return-Path” field during validation, while DMARC uses the “From” field.

Bounce messages are sent to the address in the Return-Path field. The From field is the sender’s address commonly displayed to users by email clients.

These two fields are sometimes referred to by the RFC in which they are defined. So Return-Path is also known as RFC5321.MailFrom. This is the field that SPF uses. From is also known as RFC5322.From. This is the field used by DMARC.

DMARC and SPF use different fields for historical reasons and to increase overall security. DMARC’s domain alignment policy ensures that malicious parties cannot abuse these fields.

DMARC record format

DMARC records are stored as TXT records. Unlike SPF records, DMARC records are not stored at the name of the domain. DMARC records are stored using the label “_dmarc” immediately below the root of the domain. So the DMARC record for example.org must be at _dmarc.example.org.

DMARC records consist of tag/value pairs. The tag’s name is followed by an equals sign and then the tag’s value. Tags are separated by semicolons. We’ll discuss tags in detail later.

Below is the current DMARC record for MailChimp, found at _dmarc.mailchimp.com. This record defines a DMARC policy where the failure of any DMARC check results in email rejection. Aggregate DMARC reports are emailed to 19ezfriw@ag.dmarcian.com. Message-specific DMARC reports are emailed to 19ezfriw@fr.dmarcian.com.

v=DMARC1; p=reject; rua=mailto:19ezfriw@ag.dmarcian.com; ruf=mailto:19ezfriw@fr.dmarcian.com

DMARC tags

DMARC tags specify the desired policy and options for the domain. Every DMARC record must begin with the version tag “v”. Its value must be “DMARC1”. More versions may be added in the future. The “p” tag must always be present immediately after the “v” tag. All other tags are optional and may appear in any order. DMARC is case-insensitive. Either upper- or lower-case may be used.

The Internet Assigned Numbers Authority (IANA) maintains the official registry of DMARC tags. DMARC supports these tags:

• “v” Version. The value must be “DMARC1”. This tag must appear first in every DMARC record.
• “p” Policy. Values are “None”, “Quarantine”, or “Reject”. This tag must appear second in every DMARC record.
• “sp” Subdomain Policy. Specifies how mail from subdomains is treated. If omitted, the “p” tag value is used for email from subdomains.
• “np” Non-existent Domain Policy. Specifies how mail from non-existent subdomains is treated. Added in RFC 9091.
• “pct” Percent. The percentage of email subject to filtering. The value must be an integer from 1 to 100. If this tag is omitted, the default is 100.
• “rua” Aggregate Report Email Addresses. The email addresses where aggregate reports are sent.
• “ruf” Message-specific Report Email Addresses. The email addresses where message-specific forensic reports are sent.
• “fo” Failure Reporting Options. Specifies how forensic reports are created.
• “aspf” SPF Domain Alignment Mode. May be “r” for relaxed or “s” for strict. The default is “r”.
• “adkim” DKIM Identifier Alignment Mode. May be “r” for relaxed or “s” for strict. The default is “r”.
• “ri” Reporting Interval. The number of seconds between aggregate reports. The default is 86400 (one day).
• “rf” Report Format. The format used for message-specific failure reports.

DMARC policies

The “p” tag sets the overall DMARC policy for the domain. This policy applies to any email that fails any of the DMARC checks. A value of “None” means that the email will be delivered, but reports will flag the failure. “None” is useful when testing a new policy. “Quarantine” causes a failing email to be placed into a spam folder or held for administrator review. This is a cautious policy setting. “Reject” cases all failing emails to be rejected. “Reject” is the most secure policy.

The “sp” tag sets the policy for mail sent from subdomains. The “sp” tag has the same three possible values as the “p” tag. Omit this tag if mail should be allowed from subdomains with the same policy. Specify “sp=reject” if subdomains are not permitted to send email.

The “aspf” tag sets the SPF Domain Alignment Mode. The default value is “r” for relaxed mode. Strict mode is specified using the value “s”.

The “adkim” tag sets the DKIM Identifier Alignment Mode. The default value is “r” for relaxed mode. Strict mode is specified using the value “s”.

Strict and relaxed alignment

The “aspf” and “adkim” tags both use the concept of domain alignment. DMARC allows strict or relaxed alignment policy for each tag.

Domain alignment controls how DMARC compares DNS domain names. For “aspf”, the two domain names are taken from the Return-Path and From fields. For “adkim”, the two domain names are taken from the DKIM signature and the From field.

Strict alignment means that the domain names must be exactly equal. Relaxed alignment means that the Return-Path or DKIM signature domain must be equal to or a child of the From domain.

For the From domain example.org, in strict mode only example.org will pass. But in relaxed mode any child domain will also pass. So these domains would all result in a pass in relaxed mode:

• example.org
• mail.example.org
• accounts.example.org

Notice that at least some portion of the names must match in both modes. DMARC requires that the domain names for SPF and DKIM are always at least a partial match.

Reporting

DMARC has two types of reporting: aggregate and message-specific. Aggregate reports are sent to the email addresses specified by the “rua” tag. The reports are sent daily by default. Every ISP or mail provider who receives mail from a domain will send a daily report.

Aggregate reports are XML files compressed using the popular .ZIP format. These reports contain a lot of information but are challenging to read. There are a number of services and tools that will parse these XML files into useful reports and charts.

Message-specific reports are sent to the email addresses specified by the “ruf” tag. Some mail providers will ignore this tag and not send any message-specific failure report. For example, gmail.com ignores the “ruf” tag. Message-specific reports are helpful when monitoring the initial rollout of DMARC or when making a change to DMARC, SPF, or DKIM for a domain. The administrator might choose to remove the “ruf” tag when deployment is finished to cut down on reporting volume.

Reports can be large. DMARC allows setting a maximum report file size by optionally adding an exclamation point and file size after each email address. For example, use “rua=rua_mailbox@example.org!10m” to limit aggregate report files to 10 megabytes. File size can be specified in kilobytes and other units. See RFC 7489 section 6.4 for details.

Gradual deployment with None and “pct”

When deploying email security, it is best to deploy gradually. This allows errors to be caught before they can cause significant problems.

DMARC supports gradual deployment. Start with a policy value of None and a percent value of 100. Since policy is None, emails that fail DMARC checks won’t be rejected (yet):

v=DMARC1; p=none; pct=100; rua=mailto:rua_mailbox@example.org

The daily reports can be examined to see if any legitimate mails would have been rejected or flagged. DMARC policy can be changed to Quarantine with a small percentage value once the reports look clean:

v=DMARC1; p=quarantine; pct=10; rua=mailto:rua_mailbox@example.org

Monitor for issues using the daily reports and tickets from email users. If there are no issues, increase the value of percent gradually.

Once everything looks good, change the policy value to Reject for 100% of the domain’s emails:

v=DMARC1; p=reject; rua=mailto:rua_mailbox@example.org

Finding the DMARC record for a domain

DMARC records are stored as TXT records, so a standard TXT lookup will retrieve DMARC records. DMARC record names always begin with the label “_dmarc”. The dig or nslookup command line tools can be used. To find the DMARC record for Google, use this command:

dig TXT _dmarc.google.com

On operating systems that support nslookup, you can use the following:

nslookup -type=TXT _dmarc.google.com

DMARC requires SPF and DKIM

DMARC specifies policy for the disposition of email messages that fail SPF or DKIM checks.

Additionally, SPF and DKIM must both pass either relaxed or strict domain alignment checks. For example, if the DKIM domain is not equal to or a child of the From domain, then DMARC will always generate a failure.

Even with these restrictions, it is possible to create DMARC before SPF or DKIM. If the “p” tag is set to “None”, failure reports will be generated but mail will be delivered. This can be used as a temporary measure while SPF and DKIM are being deployed.

Read my next article to learn the difference between MX, SPF, DKIM, DMARC and BIMI.