It’s that time again! Time to define more deliverability terminology, as we do every so often here in the DELIVTERMS series on Spam Resource.
Today, let’s define email authentication.
What is email authentication? Wikipedia defines it as “a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any [mail servers] who participated in transferring and possibly modifying a message.”
I’d call that mostly correct. Here’s what I’d say, instead: Email authentication is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domains responsible for originating that email message. In other words, it’s not about the mail servers – it’s about who the sender is. The mail servers are part of the equation, too, for sure, but the net result of email authentication is to prove, or disprove, that the domains used in the two from headers (the “visible from” – what you and I think of as the from address, and the MFROM, aka “return path”).
Email authentication doesn’t tell if a sender is good or bad; it just tells you if the domains involved authorized a given email message that you’ve received. It still provides valuable information that feeds into a determination of goodness or badness, in that correctly identifying the sending domain means a blocklist, mailbox provider, or spam filter can use that sending domain as an identifier to attach relevant feedback to, to eventually be able build a reputation profile (the “sender reputation”) for a given domain name. Both good and bad mail can be authenticated; so evidence of authentication alone is usually not enough to denote that an email message is non-spammy and that a sender is trustworthy.
Sending email messages with proper email authentication in place does not guarantee that your email will be delivered to the inbox. However, messages lacking proper authentication (or failing authentication checks) are much less likely to be delivered to the inbox. That’s an important distinction that some folks don’t understand. Let’s put it another way: Nowadays, you’ve got to have it. There’s no inbox delivery without it. But inbox success requires more than just email authentication. You still have to be sending wanted mail, and only to those who have explicitly requested to receive that mail.
When we talk about email authentication, we’re generally referring to three technological protocols: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC).
SPF (Sender Policy Framework) is effectively a domain setting that lets a domain owner publish a list of IP addresses allowed to send mail for that domain. Learn more about SPF here.
DKIM (DomainKeys Identified Mail) is an authentication mechanism based on public/private key cryptology that results in a hidden email header containing a cryptographic signature that allows receiving mail servers to confirm that message body and various headers were not modified after the message was created. Learn more about DKIM here.
DMARC (Domain-based Message Authentication, Reporting & Conformance) works hand-in-hand with SPF and DKIM. It allows domain owners to publish a specific “policy” regarding what receiving sites should do about mail referencing this domain that fails authentication checks. When fully implemented at its maximum potential, it effectively is a request that mailbox providers, internet service providers, spam filters and security servers do not accept or deliver spoofed mail that references the sender’s domain. Learn more about DMARC here.
It’s that time again! Time to define more deliverability terminology, as we do every so often here in the DELIVTERMS series on Spam Resource.
Today, let’s define email authentication.
What is email authentication? Wikipedia defines it as “a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any [mail servers] who participated in transferring and possibly modifying a message.”
I’d call that mostly correct. Here’s what I’d say, instead: Email authentication is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domains responsible for originating that email message. In other words, it’s not about the mail servers – it’s about who the sender is. The mail servers are part of the equation, too, for sure, but the net result of email authentication is to prove, or disprove, that the domains used in the two from headers (the “visible from” – what you and I think of as the from address, and the MFROM, aka “return path”).
Email authentication doesn’t tell if a sender is good or bad; it just tells you if the domains involved authorized a given email message that you’ve received. It still provides valuable information that feeds into a determination of goodness or badness, in that correctly identifying the sending domain means a blocklist, mailbox provider, or spam filter can use that sending domain as an identifier to attach relevant feedback to, to eventually be able build a reputation profile (the “sender reputation”) for a given domain name. Both good and bad mail can be authenticated; so evidence of authentication alone is usually not enough to denote that an email message is non-spammy and that a sender is trustworthy.
Sending email messages with proper email authentication in place does not guarantee that your email will be delivered to the inbox. However, messages lacking proper authentication (or failing authentication checks) are much less likely to be delivered to the inbox. That’s an important distinction that some folks don’t understand. Let’s put it another way: Nowadays, you’ve got to have it. There’s no inbox delivery without it. But inbox success requires more than just email authentication. You still have to be sending wanted mail, and only to those who have explicitly requested to receive that mail.
When we talk about email authentication, we’re generally referring to three technological protocols: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC).
- SPF (Sender Policy Framework) is effectively a domain setting that lets a domain owner publish a list of IP addresses allowed to send mail for that domain. Learn more about SPF here.
- DKIM (DomainKeys Identified Mail) is an authentication mechanism based on public/private key cryptology that results in a hidden email header containing a cryptographic signature that allows receiving mail servers to confirm that message body and various headers were not modified after the message was created. Learn more about DKIM here.
- DMARC (Domain-based Message Authentication, Reporting & Conformance) works hand-in-hand with SPF and DKIM. It allows domain owners to publish a specific “policy” regarding what receiving sites should do about mail referencing this domain that fails authentication checks. When fully implemented at its maximum potential, it effectively is a request that mailbox providers, internet service providers, spam filters and security servers do not accept or deliver spoofed mail that references the sender’s domain. Learn more about DMARC here.
Older technologies that either no longer matter in the email authentication sphere (or never fully took off) include Caller ID for Email, Sender ID, DomainKeys and Author Domain Signing Practices (ADSP).Want to learn more about deliverability terminology? Check out the DELIVTERMS section here on Spam Resource.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.