Often mentioned in the same breath as the email authentication protocols SPF and DKIM, DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is not in itself an authentication protocol. Instead, the purpose of DMARC is to allow a domain owner to:
- Announce its email authentication practices,
- Request treatment for mail that fails authentication checks, and
- Solicit reports about mail claiming to be from its domain.
DMARC can be an effective tool for domain owners to use in their fight against fraudulent mail that targets their domain name (e.g., phishing and spoofing), and that can promote higher trust by your recipients for your mail. This higher trust should in turn lead to higher engagement with your mail, and mail that’s opened and generating clicks drives sales and higher ROI for your email campaigns.
In addition to protecting your domain, I predict that implementing DMARC now will be an excellent way to “future-proof” your domain. Here at SparkPost, we believe that as the industry moves to IPv6, it is almost certain to move from an IP-based reputation model to a domain-based reputation model. Domain-based reputation will require domain-based authentication, and DMARC, in concert with DKIM and SPF, will help domains in establishing a domain-based reputation long before one might be absolutely necessary.
In this post, I’ll tell you all you need to know about DMARC, and give you pointers on how to set it up for your domains.
Terms To Know
Before I get into setting up DMARC for your domain, I want to make sure we’re speaking the same language. Let’s start by defining some terms I’ll use throughout the rest of this document.
The RFC5322.FromDomain is the domain part of the email address that’s usually seen by a recipient of your email when it’s being read. In the following example, the RFC5322.From domain is “joesbaitshop.com”
From: Joe’s Bait and Tackle <firstname.lastname@example.org>
DKIM d= Domain
DKIM is an authentication protocol that allows a domain to take responsibility for a message in a way that can be validated by the receiver of the message; this is done through the use of cryptographic signatures inserted into the message’s headers as it’s leaving its origination point. These signatures are effectively snapshots of what the message looked like at that point in time, and the receiver can use these snapshots to see if the message has arrived unchanged at its destination. The process of producing and inserting these snapshots is called DKIM signing, and the domain that takes responsibility for the message by signing it inserts its name into the header in a key-value tag as “d=signingDomain”, and so it’s referred to as the DKIM d= domain.
The Return-Path domain, sometimes called the RFC5321.From Domain or the Mail From domain, is the domain to which bounces are routed; it is also the domain on which SPF checks are done during the email transaction. This domain is usually not seen by the recipient unless the recipient is savvy enough to look at all the headers in a given message.
At this time, all mail sent through sparkpost.com will have sparkpostmail.com as its Return-Path domain, as in the following example:
We are contemplating giving our customers the ability to personalize this domain in the future.
The term “Organizational Domain” refers to the domain that was submitted to a registrar to create the domain’s presence on the internet. For SparkPost, our organizational domains are sparkpost.com and sparkpostmail.com.
The last term to understand regarding DMARC is “Domain Alignment,” and it comes in two variants: “relaxed” and “strict.”
Relaxed Domain Alignment
Any two domains are said to have relaxed domain alignment when their Organizational Domains are the same. For example, a.mail.sparkpost.com and b.foo.sparkpost.com have relaxed domain alignment, because of their common Organizational Domain, sparkpost.com.
Strict Domain Alignment
Two domains are said to be in strict domain alignment if and only if they are identical. So, foo.sparkpost.com and foo.sparkpost.com are in strict alignment, as the two domains are identical. On the other hand, foo.sparkpost.com and bar.foo.sparkpost.com, are only in relaxed alignment.
DMARC Domain Alignment Requirements
In order for DMARC validation checks to pass, DMARC requires that there be domain alignment as follows:
- For SPF, the RFC5322.From domain and the Return-Path domain must be in alignment
- For DKIM, the RFC5322.From domain and the DKIM d= domain must be in alignment
The alignment can be relaxed or strict, based on the published policy of the sending domain.
How DMARC Works
When I speak of a mailbox provider or other domain “checking DMARC”, or “validating DMARC”, or “applying DMARC policy”, what I mean is that the domain receiving a message is performing the following steps:
- Figure out the message’s RFC5322.From domain
- Look up that domain’s DMARC policy in DNS
- Perform DKIM Signature validation
- Perform SPF Validation
- Check domain alignment
- Apply DMARC policy
In order for a message to pass DMARC validation, the message must pass only one of the two authentication and alignment checks. So, a message will pass DMARC validation if any of the following are true:
- The message passes SPF checks and the RFC5322.From domain and Return-Path domain are in alignment, or
- The message passes DKIM validation and the RFC5322.From domain and DKIM d= domain are in alignment, or
- Both of the above are true
By default, mail sent through sparkpost.com will have “sparkpostmail*.com” as its Return-Path domain, so the only possible path to passing DMARC validation is through the DKIM check. We ensure that messages are signed twice, so there will be one DKIM-Signature with a d= domain matching the customer’s domain, and this domain should align with the RFC5322.From domain on the message.
It is possible for customers to get a custom Return-Path domain, as described by this support article. There are a number of reasons, in addition to DMARC, that a domain owner may want to pursue this option, but the choice is up to you.
Making DMARC Work for Your Domain
Now that I’ve explained the mechanics of DMARC, let’s talk about how to make DMARC work for you, which involves the following three steps:
- Making preparations to receive DMARC reports
- Deciding on what DMARC policy to use for your domain
- Publishing your DMARC record
I’ll cover each of these in detail below, but I’ll tell you straight out that step 1 above will consume about 95% of your preparation time.
Preparing to Receive DMARC Reports
Any domain that publishes a DMARC policy should first prepare to receive reports regarding their domain. These reports will be generated by any domain that does DMARC validation and sees mail claiming to be from your domain, and will be sent to you on at least a daily basis. The reports will come in two formats:
- Aggregate reports, which are XML documents showing statistical data of how much mail was seen by the reporter from each source, what the authentication results were, and how the messages were treated by the reporter. Aggregate reports are designed to be machine-parsed, with their data stored somewhere to allow for overall traffic analysis, auditing of your domain’s message streams, and perhaps identification of trends in sources of unauthenticated, potentially fraudulent, email.
- Forensic reports, which are individual copies of messages which failed authentication, each enclosed in a full email message using a format called AFRF. The forensic reports are supposed to contain full headers and message bodies, but many reporters strip or redact some information due to privacy concerns. Nonetheless, the forensic report can still be useful both for troubleshooting a domain’s own authentication issues and for identifying, from URIs in the message bodies, malicious domains and websites used to defraud the domain owner’s customers.
The preparation to receive these reports involves first creating two mailboxes in your domain to handle these reports, such as email@example.com and firstname.lastname@example.org. Note that those mailbox names are completely arbitrary, and there are no requirements for the naming of the local part of the mailbox; you are free to choose any names you wish, but keep the two separate for easier processing.
Once the mailbox names are selected and created in your domain, the next thing to do here is to put tools in place to read these mailboxes and make use of the data, especially the aggregate data reports, which again are designed to be machine-parsed, rather than read by a human. The forensic reports, on the other hand, might be manageable simply by reading them yourself, but your ability to do so will depend both on your mail client’s understanding of how to display messages in the AFRF format and on the volume of reports you receive.
While it’s possible for you to write your own tools to process DMARC reports, until such time as we provide such services for sparkpost.com customers (something we’re considering, but not promising yet), we recommend that you make use of tools that are already available for the task.
Which DMARC Policy to Use
The DMARC specification provides three choices for domain owners to use to specify their preferred treatment of mail that fails DMARC validation checks. They are:
- none, meaning treat the mail the same as it would be treated independent of DMARC validation checks
- quarantine, meaning accept the mail but place it somewhere other than the recipient’s Inbox (typically the spam folder)
- reject, meaning reject the message outright
It is important to keep in mind that the domain owner can only request such treatment in its DMARC record; it’s up to the recipient of the message to decide whether or not to honor the requested policy. Some will do so, while others may be a bit more lenient in applying policy, such as only spam-foldering mail when the domain’s policy is reject.
We recommend to all of our customers that they launch with a policy of none, simply to be safe. While we are confident in our ability to properly authenticate your mail through DKIM signing, it’s still best to take some time to examine reports about your domain before getting more aggressive with your DMARC policy.
Publishing Your DMARC Policy
A domain’s DMARC policy is announced by publishing a DNS TXT record at a specific place in the DNS namespace, namely “_dmarc.domainname.tld” (note the leading underscore). A basic DMARC policy record for our example domain from earlier, joesbaitshop.com, might look something like this:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:email@example.com\; ruf=mailto:firstname.lastname@example.org\; pct=100"
Breaking down this record, we have:
- v=DMARC1 specifies the DMARC version (1 is the only choice right now)
- p=none specifies the preferred treatment, or DMARC policy
- rua=mailto:email@example.com is the mailbox to which aggregate reports should be sent
- ruf=mailto:firstname.lastname@example.org is the mailbox to which forensic reports should be sent
- pct=100 is the percentage of mail to which the domain owner would like to have its policy applied. Domains just getting started with DMARC, especially those likely to generate a high volume of reports, may want to start with a much lower number here to see how their report-handling processes stand up to the load.
There are other configuration options available for a domain owner to use in its DMARC policy record as well, but the tips I’ve provided should be a good start.
There’s a lot to unpack in the information above! I hope you find the how-to for creating a DMARC policy record helpful. I also hope that my explanation of why DMARC matters helps make clear why you should start using this important tool for protecting your email reputation.
Of course, this isn’t a complete or authoritative document on the subject. If you want to dig in deeper or want more help, a great place to start is the official DMARC FAQ. And, it goes without saying that the crackerjack SparkPost support team is ready to help you with configuring your SparkPost account for DMARC as well.
Thanks for reading—and get started protecting your domains with DMARC today!