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).
The strategy employed by SPF is to add a TXT record to a domain's DNS. The TXT record specifies which IP addresses are allowed to send email for the domain.
Imagine an email server receives a message and checks the Envelope From (return-path
). The return path is sender@example.com
. To perform an SPF check, the following steps take place.
example.com
domain.
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 sender@example.com
. For DKIM to work properly, the following steps take place:
example.com
.
return-path
and wasn't altered in transit.
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 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
v=DMARC1\;p=none\;rua=mailto:dmarc_agg@vali.email\;ruf=mailto:dmarc_agg@vali.email\;rf=afrf\;pct=100
A DMARC record contains several tags separated by semicolons, ;. Two of the tags are required, v
(version) and p
(policy).
The version, v=DMARC1
, tells receiving servers that the DNS TXT record is a DMARC record.
The policy, p
, can be one of three values, none
, quarantine
, or 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.
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 none
, quarantine
, and 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 1
through 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 gmail.com
, yahoo.com
, aol.com
, or a similar address? In other words, what happens if your Envelope From address is sender@gmail.com
?
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 sender@yahoo.com
, 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 sender@yahoo.com
to customer@gmail.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:
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.