A few years back I wrote a blog post regarding a then-new authentication standard called DMARC. The adoption of DMARC was causing a lot of questions and uncertainty at the time, such as:
- How will DMARC help us?
- Will mail without DMARC be penalized?
- Would using DMARC allow a sender to bypass spam filters, thus getting better inbox placement?
- How does one deploy it?
Four years have passed, a great deal has happened, and we’ve learned a lot. Let’s take a look at what it means for marketers trying to improve their email deliverability.
DMARC: What It Is
Briefly, DMARC is an authentication standard created to bolster anti-phishing programs by addressing some of the shortfalls of DKIM and SPF. By utilizing a short entry in a domain's zone file, it allows senders to specify what actions they wish a mailbox provider to take with unauthenticated email. It enables a sender to request aggregated and anonymized data from ISPs about email that claims to be from their domains, and creates a way for ISPs to supply that data in a standardized format. It does not allow senders to bypass spam filters and did not affect inbox placement.
Here’s an example DNS entry for DMARC: _dmarc.greenapple.com TXT “v=DMARC1; p=none; rua=mailto:firstname.lastname@example.org ruf=mailto:email@example.com”
Alignment is critical to passing a DMARC check. A DMARC check means a message must pass "SPF authentication" and "SPF alignment" and/or "DKIM authentication" and "DKIM alignment." An email MUST come from the domain that it says it comes from:
- For "DKIM alignment": the domain in the RFC5322.From (header-from) must match the domain in the "d=" tag in the DKIM signature
- For "SPF alignment": the RFC5321.MailFrom (envelope from, return path) domain used during an SPF check must match the header-from domain
If a message fails the DMARC check, the policy declarations come into play. There are three possible "p" tags. All three of them will cause reports to be sent to the email address(es) if there’s one specified in the "rua" (aggregated reporting) and "ruf" (forensic reporting) fields:
- "p=none" — take no action on unauthenticated mail
- "p=quarantine" — treat with greater suspicion, perform additional checks
- "p=reject" — reject mail that fails any DKIM and/or SPF checks
There are additional optional tags that allow a sender to declare what percentage of mail should be examined, what format the reports should be in, how to treat unauthenticated mail from subdomains, SPF and DKIM alignment, and more. If the tags are not declared — given a value — they will operate at the standard's default. In the case of SPF and DKIM tags, the default is "r" (relaxed), meaning that it allows any authenticated subdomains to pass the DMARC check.
The intention was that senders would begin with p=none, and over time, using the percentage tags and a well-thought-out strategy, move through "p=quarantine" to "p=reject" as experience was gained and infrastructure corrected. Following this path creates incrementally increased domain security across the Internet by decreasing successful phishing delivery, minimizing false positives, etc.
What This Means for Email Senders
It quickly became clear that there were some major side effects to DMARC that needed addressing. On April 8, 2014, Yahoo! made an abrupt change to its DMARC policy, setting it to p=reject. On April 22, AOL followed suit. In October 2015, Google announced its intention of making the change in June of 2016.
Since by default and without malice, most mailing list software and forwarding breaks authentication, the immediate result of these changes is that many mailing list and email-forwarding operators saw a sudden failure in their long-established models.
Since then, various efforts have been under way to mitigate the problem, one of the most promising of which is ARC (Authenticated Received Chain). Very briefly, ARC is designed to allow the inclusion of DKIM, SPF, and DMARC results as seen by the first "hop" with those signatures remaining intact, and allowing signatures from intermediaries (Mailman software, forwarders, etc) to be reliably linked with their domain name. A recipient seeing an authentication failure may choose to check for an ARC signature to help their decision making process. The specification is still being developed; for more information, please visit the ARC website.
Regarding deliverability, in the last couple of years we’ve increasingly seen that unaligned mail is being sent to the spam folder by ISPs like Yahoo!, AOL and Gmail. We’re also seeing this happening to email sent from domains that don’t have a published DMARC policy, clearly indicating that DMARC-style alignment is being used as a metric for reputation. Furthermore, at several recent industry conferences, Gmail has made it clear that it will be putting unauthenticated mail in the spam folder, though it has been vague regarding what exactly about authentication that entails, and when it would implement this.
What that means to senders is that getting your email signed with DKIM and SPF, getting it correctly aligned and publishing a basic DMARC policy should be a top priority. Also, since Gmail has been taking steps to point out what mail is and isn’t being sent with TLS encryption, getting opportunistic TLS turned on as soon as possible would be a smart move, since Gmail has exhibited a trend of slowly but relentlessly tightening the screws on both authentication and encryption. Given that where Gmail leads, most follow, why wait to put the basics into place?
More Email and Deliverability Tips:
1) Ebook: “15 Post-Purchase Emails That Build Loyalty and Revenue”
2) Blog: “Breaking the Myth of ISPs, Email Throttling and the Holidays”
3) Tip Sheet: “Transactional Emails: 10 Tips for Driving Value and Engagement”