DMARC - Domain-based Message Authentication, Reporting and Conformance
What is DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication method that verifies a message came from a legitimate sender. DMARC is an open standard for email authentication that helps to prevent fraudsters from forging
(spoofing) your domain.
DMARC checks that the From field matches the domain in DKIM and SPF authentication checks. DMARC also tells email servers how to handle messages that fail these checks and allows recipients to receive reports on emails that fail authentication.
How DMARC works with SPF and DKIM
DMARC works in conjunction with SPF and DKIM to verify that the sender of an email is genuine. Here's how the three authentication methods work together:
- SPF (Sender Policy Framework) verifies that an email has been sent from an IP address authorized to send emails from the sender's domain.
- DKIM (DomainKeys Identified Mail) cryptographically verifies that the sender's address and message contents haven't been changed in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance) ensures that the domain in DKIM and SPF checks matches the sender's domain in the From field. It also specifies how email servers should handle a message that fails both DKIM and SPF — accept, reject, or mark it as spam.
DMARC Alignment
DMARC Domain alignment is a concept in DMARC that expands the domain validation intrinsic to SPF and DKIM . DMARC domain alignment matches a message's From: domain with information relevant to these other standards:
- For SPF , the message's From: domain in email header and its Return-Path: in email envelope domain must match
- example: From: user@example.com domaian part must match Return-Path:user@example.com domain part
- For DKIM , the message's From: domain part in email header and its DKIM d= domain part must match
- example: From: user@example.com domain part must match with d=example.com
- The alignment can be relaxed (matching base domains, but allowing different subdomains) or strict (precisely matching the entire domain). This choice is specified in the published DMARC policy of the sending domain.
- Strict alignment means that the Return-Path domain or the signing domain "d=" must be an exact match with the domain in the "From:" address.
- Relaxed alignment means that the Return-Path domain or the signing domain "d=" can be a subdomain of the "From:" address and vice versa.
DMARC Alignment Example
example For SPF:
MAIL-FROM/RETURN-PATH: user@example.com # SMTP envelope
From: user@subdomain.example.com # email header
In the above example, if DMARC was set to strict SPF mode then an email coming from subdomain.example.com would DMARC fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode DMARC would pass.
example For DKIM:
d="example.com" # DKIM in email header
From: user@subdomain.example.com # email header
In the above example, if DMARC was set to strict DKIM mode then an email coming from subdomain.example.com would DMARC fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode DMARC would pass.
How does DMARC work
After setting up SPF and/or DKIM, you must publish a DMARC record , which contains a DMARC policy . The DMARC policy tells email servers what action to take with messages that fail both SPF and DKIM checks. There are three options:
DMARC policy | Server action |
---|---|
None | Take no action — the message continues to the recipient's inbox. |
Quarantine | Move the message to spam or another folder instead of the inbox. |
Reject | Block the message — the message isn’t delivered. |
Once you've published your DMARC record , you're ready to send emails with DMARC as follows:
- You send an email, for example, from the address you@yourdomain.com.
- The receiving mail server looks up your domain's DMARC policy
in your DMARC record
on the DNS server.
- Following the DMARC policy, the receiving mail server does the DMARC, SPF, and DKIM authentication tests, checking that the domain in the message's From field is aligned with (matches) the domain in SPF and DKIM.
- For SPF, the From field should align with the domain in the Return-Path field in the email header .
- For DKIM, the From field should align with the domain (d) in the DKIM signature .
- If the message passes both the authentication and the alignment test for either SPF or DKIM, then it passes DMARC. If it fails either the authentication or the alignment test for both SPF and DKIM, it fails DMARC.
- When a message fails DMARC, the mail server routes it according to the DMARC policy (none/quarantine/reject).
- Mail servers receiving messages from your domain send regular emails with authentication results to you, the domain owner (assuming you’ve included a reporting address in your DMARC record and the mail server is set up to send DMARC reports).
DMARC policy
There are three options for DMARC policies, which are indicated by the p= tag in a DMARC record:
DMARC policy | Server action |
---|---|
None | Take no action, so all messages that fail authentication will be delivered. |
Quarantine | Send failed messages to the spam folder. |
Reject | Block failed messages, so they won’t be delivered. |
p=none may be useful when you have a new domain and want to check that your legitimate emails are being delivered. With p=none, all messages are delivered regardless of authentication, and you receive email reports that you can use to spot authentication issues.
However, once you're confident your email is configured correctly, we recommend switching to p=quarantine, which sends failed messages to the spam folder.
If you think you're likely to be the target of email spoofing , set p=reject. For example, sites like PayPal and eBay use p=reject because they're targeted by spammers and scammers impersonating their domains.
DMARC DNS record
Typically, DMARC records include:
- A DMARC policy, which tells receiving mail servers what to do when an email fails SPF and DKIM authentication
- An optional email address where mail servers can send DMARC reports about the authentication of emails sent from that domain.
DMARC records are published in DNS with a subdomain label _dmarc, for example _dmarc.example.com. The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM. For example:
_dmarc.example.com TXT "v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"
Here, v is the version, p is the policy, sp the subdomain policy, pct is the percent of "bad" emails on which to apply the policy, and rua is the URI to send aggregate reports to. In this example, the entity controlling the example.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn't expect emails to be sent from subdomains of example.com.
The following chart illustrates some of the available tags:
Tag Name | Purpose | Sample |
---|---|---|
v | Protocol version | v=DMARC1 |
pct | Percentage of messages subjected to filtering | pct=20 |
ruf | Reporting URI for forensic reports | ruf=mailto:authfail@example.com |
rua | Reporting URI of aggregate reports | rua=mailto:aggrep@example.com |
p | Policy for organizational domain | p=quarantine |
sp | Policy for subdomains | sp=reject |
adkim | Alignment mode for DKIM | adkim=s/adkim=r |
aspf | Alignment mode for SPF | aspf=r/aspf=s |
Reports
DMARC is capable of producing two separate types of reports. Aggregate reports are sent to the address specified following the rua. Forensic reports are emailed to the address following the ruf tag. These mail addresses must be specified in URI mailto format (e.g. mailto:worker@example.net ). Multiple reporting addresses are valid and must each be in full URI format, separated by a comma.