On the fourth day of Listmas, my data showed to me: four authentication failures…
Hey, it’s a song, okay? So, there are several ways to trigger authentication failures. Not everybody checks authentication; we could still be counting either DomainKeys or SenderID, etc. But, honestly, this is day 4 because that’s just how it worked out.
Most sender authentication these days is accomplished by three mechanisms: SPF, DKIM, and DMARC. The first two are independent of other factors, and the last one depends on the first two.
RFC 7208 defines SPF — the standard for evaluating whether a message is authorized to be sent from a given IP address.1 RFC 6376 defines DKIM, which authenticates the domain that affixed a cryptographic signature to the message.2 RFC 7489 defines DMARC, the standard for evaluating the domain in the “From” address. It is based upon an evaluation of the responses to SPF and DKIM checks. Unlike SPF and DKIM, the specification allows a domain to specify what it wants to happen to mail that fails authentication.3
Taken together, these three RFCs tell receivers whether a message is:
- Authorized to be sent from the IP address from which it is arriving,
- a message sent by the organization that purports to be sending it, and
- (broadly) what to do with messages that fail these checks.
Often, you will hear people say that DMARC checks DKIM and SPF. And that’s generally true; messages that pass SPF and DKIM should pass DMARC. In fact, step 8 of RFC 7489’s “Flow Diagram” of RFC 7489 says: “If a policy is found, it is combined with the Author’s domain and the SPF and DKIM results to produce a DMARC policy result (a ‘pass’ or ‘fail’) and can optionally cause one of two kinds of reports to be generated.”4 But, there’s actually a little more to it than that.
You see, SPF checks the “RFC5321.MailFrom” domain,5 and a receiver might also check the EHLO/HELO domain.6 DMARC, though, looks at the “RFC5322.From” domain.7 The DMARC document specifies that “Email authentication technologies authenticate various (and disparate) aspects of an individual message. For example, DKIM authenticates the domain that affixed a signature to the message, while SPF can authenticate either the domain that appears in the RFC5321.MailFrom (MAIL FROM) portion of SMTP or the RFC5321.EHLO/HELO domain, or both. These may be different domains, and they are typically not visible to the end user.”8
What that means is that you need everything to line up. DMARC will check the policy record of the domain found in the email address in the From: field (which is almost always visible to the recipient). It will use that policy record to review the SPF and DKIM results and use all that data to determine what to do with the message. So, when you hear someone talk about “DMARC alignment,” they’re really talking about making certain that the domains used to check all three mechanisms (RFC5322.From, RFC5321.MailFrom, and the domain in the dkim-signature header) are the same.
When authentication fails, you may find yourself with messages rejected (especially if you have a DMARC policy that requires it) or sent to the bulk folder. And, as more and more providers use message authentication as part of the basic package of things that need to be done right just to get into the door, it will continue to be easier and easier for marketers who get it wrong to really hurt their own delivery rates.
Sending three times daily,
Two purchased lists, and
That’s why they’re having poor delivery.
Footnotes
- Scott Kitterman, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC 7208 (Apr. 2014), https://tools.ietf.org/html/rfc7208. ↩︎
- Dave Crocker et al., DomainKeys Identified Mail (DKIM) Signatures, RFC 6376 (Sept. 2011), https://tools.ietf.org/html/rfc6376. ↩︎
- Murray Kucherawy & Elizabeth Zwicky, Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC 7489 (Mar. 2015), https://tools.ietf.org/html/rfc7489. ↩︎
- Id., at § 4.3. ↩︎
- Kitterman, supra note 1 at § 2.4. ↩︎
- Id., at § 2.3. ↩︎
- Kucherawy, supra note 3 at § 5. ↩︎
- Id. at § 3.1. ↩︎
About the Author
Mickey Chandler is a Consultant & Attorney with over 28 years of experience in Email Deliverability & Privacy Law. He has a strong background in email authentication infrastructure (SPF, DKIM, DMARC), ISP and mailbox provider relations, anti-spam policy and compliance, CAN-SPAM and state anti-spam law gained through overseeing the Abuse & Compliance team at Salesforce Marketing Cloud, originating the ISP relations role at Informz (now part of Higher Logic), and working in the fight against spam since 1997. He holds a B.A. in Government, a B.S. in Computer Information Systems, and a J.D. from the University of Houston Law Center. He is a certified CIPP/US professional and a certified CIPM professional.
