Skip to contentSkip to navigationSkip to topbar
On this page

Everything about DMARC


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(link takes you to an external page) to get the most from this article. If you need a refresher on these topics, resources are linked throughout this page.


What is DMARC?

what-is-dmarc page anchor

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).

(information)

Info

Twilio SendGrid now offers additional DMARC enforcement and monitoring options in partnership with Valimail(link takes you to an external page). Click here(link takes you to an external page) for more information.


The strategy employed by SPF is to add a TXT record(link takes you to an external page) to a domain's DNS. The TXT record specifies which IP addresses are allowed to send email for the domain.

SPF mail flow

spf-mail-flow page anchor

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.

  1. The receiving email server retrieves the SPF record from the DNS records for the example.com domain.
  2. The receiving server then checks the SPF record for all the IP addresses that are approved to send email on behalf of the domain.
  3. 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.
  4. If the SPF check fails, the message is likely illegitimate and will be processed using the receiving server's failure process.
A diagram of the SPF traffic flow described in the steps above this.

For more on SPF, see SPF Records Explained.


DomainKeys Identified Mail

domainkeys-identified-mail page anchor

DomainKeys Identified Mail (DKIM) uses public-key cryptography(link takes you to an external page) 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:

  1. Before sending the message, the sending server signs the email using a private key.
  2. When the message is delivered, the receiving server obtains the DKIM record from the DNS records for example.com.
  3. The receiving server then uses the public key in the DKIM record to verify the message's signature.
  4. If the DKIM check passes, the receiving server can be confident the message was sent by the address in the return-path and wasn't altered in transit.
  5. If the DKIM check fails, the message is likely illegitimate and will be processed using the receiving server's failure process.
A diagram of the DKIM traffic flow described in the steps above this.

For more information about DKIM, see DKIM Records Explained.


Domain-based Message Authentication, Reporting and Conformance

domain-based-message-authentication-reporting-and-conformance page anchor

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 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.

(information)

Info

"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(link takes you to an external page)

Example DMARC record

example-dmarc-record page anchor
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).

Version tag
version-tag page anchor

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.

  1. 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.
  2. 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.
  3. 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.

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-path domains that match the domain set in the SPF or DKIM record exactly will pass.
  • Relaxed: Any return-path domain 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 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.

A diagram of the DMARC mail flow.

How DMARC Applies to a Sender Identity

how-dmarc-applies-to-a-sender-identity page anchor

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.


Need some help?

Terms of service

Copyright © 2024 Twilio Inc.