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 allows you, the domain owner, to protect your email reputation by:
- Announcing email authentication practices,
- Requesting treatment for mail that fails authentication checks, and
- Soliciting reports about mail claiming to be from its domain.
DMARC can be an effective tool for you to to use in your 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 leveraging DMARC to protect your email reputation, 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 to Protect Your Email Reputation
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!
Do not go gentle into that new normal
At SparkPost’s recent Insight user conference, Steve Jones, executive director of DMARC.org, didn’t hold back. He began his talk on email authentication by bluntly observing that “spam and phishing are the new normal.” I sucked in my breath. Steve’s comment felt like a punch to the gut. I felt like I wanted to defend the honor of email. Yeah, bad guys—sometimes really bad guys—are out there, I thought to myself, but it’s the exception, not the rule! But I knew he was right. I settled down and nodded my head, knowing that Steve’s perspective squared with the experiences of people who manage the front-lines of defense at ISPs and corporate email hosts, as well as the findings of email industry organizations like M3AAWG.
Steve noted that 28 billion spam messages are sent every day. By some estimates, phishing is a $3.7-million annual cost for the average enterprise. And for publicly-traded companies, a disclosure of phishing leads to a loss of stock value of $411 million or more. As Steve put it, costs like these are fraudulent email’s “hit to reputation and brand, made tangible. And there’s no bottom to what bad actors will do to get your money.”
So, spam and phishing really are the new normal. Companies must incorporate a security posture that takes into account email as a major attack vector that’s exploitable through phishing, malware, and socially engineered content designed to defraud recipients of sensitive information and to steal credentials that grant access to systems.
And this new normal is why Steve’s organization does its work. DMARC, or “Domain-based Message Authentication, Reporting & Conformance,” is a technical specification that builds on earlier SPF and DKIM email authentication mechanisms. In his talk at Insight, Steve presented an overview of the current landscape of email authentication, including why DMARC is important, how it works, and recent developments.
ISPs are moving to an authentication-only world. So should you.
The biggest consumer mailbox providers prefer authenticated email. But that preference may be changing to a mandate. In 2015, Yahoo took the plunge and published a “p=Reject” DMARC record. By doing so, Yahoo essentially told receivers, “if you can’t verify an email came from Yahoo, throw it away. No exceptions.” There are reports that Google may take a similar step for Gmail in 2016.
There have been issues with this “strict” posture—in some cases, legitimate email has suffered because of this spam counter-measure. But, I remind you that false positives are nothing new. It’s frankly just a cost of doing business for senders (and a much smaller cost than those that result from successful phishing attacks). Legitimate senders long have been operating in the shadow of compromised hosts, spam, phishing and other abusive digital communications, and incurring short-term inconveniences to stem that tide is worth the effort. Truth be told, what disturbs me more is the fact that everyone hasn’t yet adopted SPF, DKIM and DMARC as a means of combating spam and protecting their own reputations!
It’s time to splice email authentication into corporate DNA.
The watch guards of enterprise security (especially CISOs) often talk about a company’s “security posture,” the plan and cultural shift that a business puts into place to protect its employees, customers, intellectual property, and systems from attack, both cyber and physical. We’re likely all familiar with defenses like firewalls, multi-factor authentication mechanisms, access and password policies, and more.
But what about email? It’s the lifeblood of every company doing business on the internet today. But at too many businesses, email security is limited to spam filters or malware scans. Those are fine front-line tools to help protect against brute force bad guys, but they do little for phishing (and spear-phishing) attacks.
The simple power of email is its ability to connect people and businesses the world over. But the simplicity and ubiquity that makes email the Internet’s “connective tissue” also allows the spread of viruses, fraud, phishing, and compromises to accelerate to pandemic speed as they move from one email box to another.
Every company that works with customer data, financials, or has a broad national or global presence is nothing short of a flame in the night that draws all sorts of malicious attacks. In the digital marketing industry, ESPs, marketing automation companies, anyone who purports to be a marketing system of record… are just some of the inevitable targets for phishing attacks.
Adopting email authentication standards like DMARC (and transport layer encryption standards such as STARTTLS) will go a long, long way to improving your digital messaging security posture. What are you waiting for? Do it.
Ready to learn more about DMARC and email authentication? Here are a few resources to get going.
- How DMARC Is Saving Email, a great ebook written by our deliverability team
- The Validator, the free, all-in-one DKIM validation, SPF checker, and DMARC validator app from SparkPost
- Understanding SPF and DKIM In Sixth Grade English
- Twitter’s Email Privacy Report, powered by SparkPost