This article provides an overview of Domain-based Message Authentication, Reporting and Conformance (DMARC). You will learn how DMARC works and how it applies to your Sender Identity or From address. You should already be familiar with DNS records, IP addresses, and the general flow of web traffic to get the most from this article. If you need a refresher on these topics, resources are linked throughout this page.
DMARC is a powerful way to verify the authenticity of an email’s sender and prevent malicious senders from damaging your sender reputation.
To understand DMARC, let's first understand the problem DMARC attempts to solve: email spoofing.
Email spoofing is the practice of sending email with a forged From address. Note that an email actually has two From addresses: the Header From and Envelope From. DMARC is concerned only with the spoofing of the Envelope From (also known as the
return-path) address. See our spoofing glossary entry for more information about spoofing and From addresses.
DMARC relies on two authentication protocols to prevent spoofing: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
Imagine an email server receives a message and checks the Envelope From (
return-path). The return path is
firstname.lastname@example.org. To perform an SPF check, the following steps take place.
- The receiving email server retrieves the SPF record from the DNS records for the
- The receiving server then checks the SPF record for all the IP addresses that are approved to send email on behalf of the domain.
- If the SPF check passes, the receiving server can be confident the message was sent from an approved sending server and will continue processing the message.
- If the SPF check fails, the message is likely illegitimate and will be processed using the receiving server’s failure process.
For more on SPF, see SPF Records Explained.
DomainKeys Identified Mail (DKIM) uses public-key cryptography to sign a message. Like SPF, DKIM is implemented with a TXT record. Unlike SPF, the DKIM TXT record provides a public key that receiving mail servers can use to verify the authenticity of a message.
Remember, the problem with spoofing is forgery of the From address. However, by signing the From address, among other headers, and providing a public key to verify the signature, receiving servers can corroborate the authenticity of the sender.
Let’s again imagine an email sent by
email@example.com. For DKIM to work properly, the following steps take place:
- Before sending the message, the sending server signs the email using a private key.
- When the message is delivered, the receiving server obtains the DKIM record from the DNS records for
- The receiving server then uses the public key in the DKIM record to verify the message’s signature.
- If the DKIM check passes, the receiving server can be confident the message was sent by the address in the
return-pathand wasn’t altered in transit.
- If the DKIM check fails, the message is likely illegitimate and will be processed using the receiving server’s failure process.
For more information about DKIM, see DKIM Records Explained.
If SPF and DKIM already help validate an email's sender, what does DMARC add?
Think of DMARC not as an independent authentication protocol but as a framework for handling SPF and DKIM failures and reporting those failures to domain owners.
- DMARC allows domain owners to specify what should happen if either or both SPF and DKIM checks fail. Neither SPF nor DKIM provide this functionality on their own. This means that without DMARC a sender has no say in whether a failing message is bounced, sent to a spam folder, or handled in some other way.
- A sender receives no feedback about SPF and DKIM failures without DMARC, so senders have little chance to combat or even understand the delivery trends of their domain, often called a "reputation monitoring."
- SPF and DKIM are independent of each other, but neither provide thorough spoofing protection on their own.
DMARC addresses these issues by building on top of SPF and DKIM. SPF and DKIM handle the Domain-based Message Authentication part of DMARC.
DMARC adds the Reporting and Conformance piece on its own. Like SPF and DKIM, DMARC is implemented using a TXT DNS record. This record allows receiving email servers to fetch failure processing instructions from domain owners.
"If you know how to view DNS records (e.g. using the 'dig' command), you can also check to see if [service providers] publish a DMARC TXT Resource Record. This doesn’t necessarily mean they support DMARC for the email they receive (though it’s a good indication), but it does indicate they use DMARC to protect outbound mail." — DMARC.org
A DMARC record contains several tags separated by semicolons, ;. Two of the tags are required,
v (version) and
v=DMARC1, tells receiving servers that the DNS TXT record is a DMARC record.
p, can be one of three values,
reject. DMARC policies are the mechanism domain owners use to specify how a receiving email server should handle SPF and DKIM failures.
p=none: No action should be taken. Even if a failure occurs, the message should be delivered. Though no action is taken on the message, the failure is included in reports sent to the domain owner.
p=quarantine: Failures should be quarantined. This usually means the message is sent to the spam folder. Again, the failure will be included in reports to the domain owner.
p=reject: Failures will be rejected. This usually means that the message will be deleted. The message may also be bounced to the Envelope From address.
Where do the failure reports go? The address assigned to
rua= tells receiving email servers where to deliver aggregate reports. The address assigned to
ruf= tells receiving email servers where to send forensic reports.
- Aggregate reports are sent daily by default and don’t include detailed information about individual failures.
- Forensic reports send detailed information about individual failures at the time of failure. The email address assigned to
rufmust also use the domain on which the DMARC record exists.
The request format,
rf=afrf, tells receiving servers how to format reports for the domain owner. Authentication Failure Reporting Format,
afrf, is the default and is an extension of Abuse Reporting Format.
fo tag tells receiving servers what type of failures to report. There are four possible values for this tag.
fo=0: Send a report if both SPF and DKIM checks do not pass. This is the default value.
fo=1: Send a report if either SPF or DKIM checks do not pass.
fo=d: Send a report only if the DKIM check does not pass.
fo=s: Send a report only if the SPF check does not pass.
ri tag sets the interval in seconds at which a domain owner wishes to receive aggregate reports. The default is,
86400—that’s 24 hours in case you don’t have your calculator out.
There are tags for both SPF,
aspf, and DKIM,
adkim, alignment. Alignment is a way of qualifying how strictly DKIM and SPF values should be applied to pass a check. The options are either
s for strict or
r for relaxed.
- Strict: Only
return-pathdomains that match the domain set in the SPF or DKIM record exactly will pass.
- Relaxed: Any
return-pathdomain matching the root of the domain set in the SPF or DKIM record will pass. This allows CNAME addresses to pass a check.
If a domain owner needs to specify different policies for subdomains, they can use the
sp tag. Like the policy tag,
p, the possible values for the
sp tag are
reject. This means you can, for example, apply a reject policy to your root domain and a quarantine policy for all its subdomains.
The percent tag,
pct, specifies the percentage of email to which your DMARC policy will be applied. The possible values are
100. For example, if your policy is set to
quarantine, and your percent is set to
50, half of all failing mail will be quarantined. This tag value can be adjusted as you learn more about DMARC failures on your domain.
When sending email via a service provider such as SendGrid, you will be asked to authenticate a domain or verify a Single Sender. However, what happens if you verify a Sender Identity using a
aol.com, or a similar address? In other words, what happens if your Envelope From address is
As you can guess, major mail providers such as Google, Microsoft, and others implement DMARC to protect their customers and prevent abuse. Let's use Yahoo and the email address
firstname.lastname@example.org, as an example.
Yahoo has SPF, DKIM, and DMARC policies. Yahoo’s DNS records will approve domains such as yahoo.com and the IP addresses Yahoo controls. SendGrid domains and IP addresses will not be included in Yahoo's approved domains and IP addresses.
When you send a message from
email@example.com using SendGrid, a Gmail server will receive the message. Gmail will then look up Yahoo’s SPF and DKIM records because
yahoo.com is the domain in the return-path message header.
The Gmail receiving server will determine that the message was sent using a SendGrid IP address and was not signed by a Yahoo private key. Both SPF and DKIM will fail, causing Gmail to employ the DMARC failure policy specified by Yahoo.
Essentially, Gmail, or any other receiving email server, has no way of knowing whether you are using SendGrid to send email for legitimate purposes or spoofing Yahoo's domain.
This is why SendGrid recommends authenticating a domain that you do control. The SendGrid domain authentication process provides CNAME records that you place on your own domain to approve SendGrid's IP addresses. SendGrid will automatically manage your SPF and DKIM records, protecting your domain’s reputation.
Many of the popular email providers implement DMARC, including:
- Microsoft (Hotmail, MSN)
Providers with DMARC policies may reject email with messages like, "521 5.2.1 : (DMARC) This message failed DMARC Evaluation and is being refused due to provided DMARC Policy".
If you see a bounce with one of these failure messages, the message has been discarded and tracked as a Block. You will need to adjust your From address field settings, and then try resending from your side.