Authentication Failures

On the fourth day of Listmas, my data showed to me four authentication failures…

Hey, it’s a song, okay? So, there are a number of ways to go to get 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 is dependent upon the first two.

RFC 7208 is the current standard for SPF. SPF exists in order to provide a mechanism to allow domain owners to “explicitly authorize the hosts that are allowed to use their domain names.” Incoming mail will have the domain in the MAIL FROM: line checked against the SPF record. Mail which passes the check should be allowed through (to the next test, at least). The SPF specification doesn’t say what should happen with mail that fails the check.

RFC 6376 is the current standard for DKIM. DKIM exists to allow “a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message.” This is accomplished by means of “signing” the message with a cryptographic signature. As with SPF, DKIM does not specify what should happen to mail that fails the check.

Finally, RFC 7489 defines DMARC. DMARC is the standard for evaluation of the domain found in the “From” address. It is based upon an evaluation of the responses to SPF and DKIM checks. Unlike SPF and DKIM, the specification does allow for a domain to say what it wants to happen to mail that fails authentication.

Taken together, these three RFCs tell receivers whether a message is:

1. Authorized to be sent from the IP address that it is arriving from,
2. a message sent by the organization that purports to be sending it, and
3. (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 which pass SPF and DKIM should pass DMARC. In fact, step 8 of the “Flow Diagram” (Section 4.3) 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 (not shown).” But, there’s actually a little more to it than that.

You see, SPF checks what is referred to as the “RFC5321.MailFrom” domain (Section 2.4) — and a receiver might also check the EHLO/HELO domain (Section 2.3) — while the DMARC specification looks at the “RFC5322.From” domain. 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.”

What that means is that you need for the 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 have a look at the results of SPF and DKIM and use all of that data to help 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, then you can find yourself in a situation where messages are rejected (especially if you have a DMARC policy that tells receivers to do that) or sent to the bulk folder. And, as more and more providers use message authentication as part of the basic package of things that needs 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.

Bibliography

1. Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, Scott Kitterman (2014, April). Retrieved December 12, 2017 from Internet Engineering Task Force: https://tools.ietf.org/html/rfc7208.
2. DomainKeys Identified Mail (DKIM) Signatures, Dave Crocker et.al. (2011, September). Retrieved December 12, 2017 from Internet Engineering Task Force: https://tools.ietf.org/html/rfc6376.
3. Domain-based Message Authentication, Reporting, and Conformance (DMARC), Murray Kucherawy and Elizabeth Zwicky (2011, September). Retrieved December 12, 2017 from Internet Engineering Task Force: https://tools.ietf.org/html/rfc7489.