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:
- Authorized to be sent from the IP address that it is arriving from,
- 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 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
- 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.
- 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.
- 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.
Archives
- November 2021
- July 2020
- June 2020
- March 2020
- February 2020
- January 2020
- November 2018
- February 2018
- January 2018
- December 2017
- January 2017
- August 2016
- June 2016
- April 2016
- March 2016
- February 2016
- July 2015
- June 2015
- March 2015
- February 2015
- November 2014
- June 2014
- April 2014
- February 2014
- December 2013
- November 2013
- September 2013
- May 2013
- June 2012
- April 2012
- September 2011
- August 2011
- March 2011
- January 2011
- November 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- November 2009
- October 2009
- July 2009
- June 2009
- May 2009
- March 2009
- January 2009
- October 2008
- September 2008
- April 2008