The 3 Layers of Email Authentication Protocol
To succeed with scalable email marketing, it’s critical for brands to follow best practices for email authentication. In addition to playing a role in the acceptance of your email by an ISP, your authentication results will also play a role in determining inbox placement. Fail to use the right authentication methods, and your brand’s email marketing campaigns could suffer in a major way.
In most cases, recipients rely on one of the following to determine who an email is from:
Unfortunately, the Simple Mail Transfer Protocol (SMTP) that guides how email moves from one inbox to another, and allows for a computer to identify any domain as its sending domain (or “from” address) is vulnerable. Specifically, it’s vulnerable to the malicious intentions of unscrupulous marketers and digital thieves (spamming, phishing, spoofing, etc.).
Since an email’s path and its true sender details aren’t easily readable, most recipients fail to check a sender’s full credentials (or an email’s authentication results). This reality makes it easier for malicious parties to send mail using a reputable “From Address”, and get their emails opened by unsuspecting consumers.
For enterprise marketers, this presents a serious problem because it means their reputable brand name (trusted in the eyes of consumers) can be hijacked by malicious parties to deceive recipients, via a basic manipulation of the From Name, From Address, or Subject Line. Done at scale, such deceit can have grievous consequences for a brand.
Email authentication protocols (in addition to sending laws) were developed and adopted by ISPs to counteract this vulnerability by providing unsuspecting consumers with a layer of protection.
Of course, these email authentication protocols were very basic at the beginning. But with the progress of time and technology, these layers of protection advanced from Sender Policy Framework (SPF) to DomainKeys Identified Mail (DKIM) to Domain-based Message Authentication, Reporting & Conformance (DMARC).
In this whitepaper, Zeta will talk in greater detail about the three cornerstones of authentication, as well as highlight the best practices for email authentication going forward.
In its simplest form, SPF is a permission check. More formally, SPF is an authentication policy
that specifies which IP and mail servers are authorized to send on behalf of a domain. This specification means that domains protected by SPF are less likely to be utilized for phishing by scammers.
Based on the comparison, an email will “pass” or “fail” the protocol. The results of this pass/fail are written into the header and used to determine if email acceptance is granted (and if it is granted, determine inbox placement as well).
There are limitations to SPF.
First of all, SPF does not protect a domain from scammers willing to spoof the friendly “from address” or name.
Secondly, SPF can create false positives due to how the message path changes.
For example, forwarded emails typically fail an SPF permission check even when the email being shared is legitimate. Why?—Because forwarded emails are sourced from the IP used by the forwarding sender, not the IP of the original sender.
DKIM is an email authentication protocol that gives the recipient a way to validate the identity of the domain that’s taking responsibility for sending the message. It also allows the recipient to determine if the message or headers were altered at any point between the time of transmission to the time of reception. DKIM doesn’t solve for everything, but is a great addition to SPF as it now assigns a level of data integrity and accountability to the domain owner that signed it.
DKIM isn’t bulletproof. If a message fails the DKIM protocol, it won’t necessarily be rejected. The failure will be incorporated into the overall filtering decision in terms of acceptance and placement. Even though it isn’t perfect, it’s still a great addition to SPF because it assigns a level of data integrity and accountability to the domain owner.
DMARC is another layer of authentication that ensures the sender identity shown to the recipient of an email is the same sender identity that’s shown to the receiving server. It works to further protect consumers from disguised emails that might slip by SPF and DKIM protocols. Using DMARC, a domain owner can control what happens to mail that’s being sent by unauthorized sources. In other words, a domain owner doesn’t need to rely on an ISPs filters to determine acceptance and placement.
If an email passes another authentication method with proper alignment, it will always pass DMARC. For example, if a message fails a DKIM authentication check, it will still pass DMARC assuming it cleared the SPF authentication protocol and the identifier alignment test.
When an email does fail DMARC, the existing policy will dictate what happens to the message (quarantine, reject, or accept).
A couple more details about DMARC…
DMARC gives marketers the option to receive reports detailing which messages passed or failed, and—if any do fail—where in the authentication process those failures occurred (SPF, DKIM, or domain alignment). Such insight is incredibly valuable because it can help identify phishing attacks and infrastructure vulnerabilities.
DMARC can be published on an organizational level, and—when it is published at the organizational level—will cover all subdomains unless there is a unique subdomain policy set to override DMARC. The advantage here is that it allows email marketers to set up one policy for their entire organization without having to create unique DMARC policies for every single domain affiliated with the business.
By combining all three authentication protocols (SPF, DKIM, and DMARC), receiving servers can confirm that…
For this reason, Zeta requires the use of SPF and DKIM for all clients, and recommends the deployment of DMARC as well.
Due to their technical nature, email authentication processes can be difficult to understand and implement. For that reason, Zeta wants you to reach out with any questions you may have about the process, or how you can use email authentication to achieve better results with your enterprise marketing.
The origins of email authentication protocol
In most cases, recipients rely on one of the following to determine who an email is from:
- From Name
- From Address
- Subject Line
Unfortunately, the Simple Mail Transfer Protocol (SMTP) that guides how email moves from one inbox to another, and allows for a computer to identify any domain as its sending domain (or “from” address) is vulnerable. Specifically, it’s vulnerable to the malicious intentions of unscrupulous marketers and digital thieves (spamming, phishing, spoofing, etc.).
Since an email’s path and its true sender details aren’t easily readable, most recipients fail to check a sender’s full credentials (or an email’s authentication results). This reality makes it easier for malicious parties to send mail using a reputable “From Address”, and get their emails opened by unsuspecting consumers.
For enterprise marketers, this presents a serious problem because it means their reputable brand name (trusted in the eyes of consumers) can be hijacked by malicious parties to deceive recipients, via a basic manipulation of the From Name, From Address, or Subject Line. Done at scale, such deceit can have grievous consequences for a brand.
Email authentication protocols (in addition to sending laws) were developed and adopted by ISPs to counteract this vulnerability by providing unsuspecting consumers with a layer of protection.
Of course, these email authentication protocols were very basic at the beginning. But with the progress of time and technology, these layers of protection advanced from Sender Policy Framework (SPF) to DomainKeys Identified Mail (DKIM) to Domain-based Message Authentication, Reporting & Conformance (DMARC).
In this whitepaper, Zeta will talk in greater detail about the three cornerstones of authentication, as well as highlight the best practices for email authentication going forward.
Email Authentication Protocol #1 – Sender Policy Framework (SPF)
What is Sender Policy Framework?
In its simplest form, SPF is a permission check. More formally, SPF is an authentication policy
that specifies which IP and mail servers are authorized to send on behalf of a domain. This specification means that domains protected by SPF are less likely to be utilized for phishing by scammers.
How does SPF work?
Based on the comparison, an email will “pass” or “fail” the protocol. The results of this pass/fail are written into the header and used to determine if email acceptance is granted (and if it is granted, determine inbox placement as well).
Be careful though…
There are limitations to SPF.
First of all, SPF does not protect a domain from scammers willing to spoof the friendly “from address” or name.
Secondly, SPF can create false positives due to how the message path changes.
For example, forwarded emails typically fail an SPF permission check even when the email being shared is legitimate. Why?—Because forwarded emails are sourced from the IP used by the forwarding sender, not the IP of the original sender.
What are the technical details of SPF?
Email Authentication Protocol #2 – DomainKeys Identified Mail (DKIM)
What is DomainKeys Identified Mail?
DKIM is an email authentication protocol that gives the recipient a way to validate the identity of the domain that’s taking responsibility for sending the message. It also allows the recipient to determine if the message or headers were altered at any point between the time of transmission to the time of reception. DKIM doesn’t solve for everything, but is a great addition to SPF as it now assigns a level of data integrity and accountability to the domain owner that signed it.
How does DKIM work?
Be careful though…
DKIM isn’t bulletproof. If a message fails the DKIM protocol, it won’t necessarily be rejected. The failure will be incorporated into the overall filtering decision in terms of acceptance and placement. Even though it isn’t perfect, it’s still a great addition to SPF because it assigns a level of data integrity and accountability to the domain owner.
What are the technical details of DKIM?
Email Authentication Protocol #3 – Domain-based Message Authentication, Reporting & Conformance (DMARC)
What is Domain-Based Message Authentication, Reporting & Conformance?
DMARC is another layer of authentication that ensures the sender identity shown to the recipient of an email is the same sender identity that’s shown to the receiving server. It works to further protect consumers from disguised emails that might slip by SPF and DKIM protocols. Using DMARC, a domain owner can control what happens to mail that’s being sent by unauthorized sources. In other words, a domain owner doesn’t need to rely on an ISPs filters to determine acceptance and placement.
How does DMARC work?
Be careful though…
If an email passes another authentication method with proper alignment, it will always pass DMARC. For example, if a message fails a DKIM authentication check, it will still pass DMARC assuming it cleared the SPF authentication protocol and the identifier alignment test.
When an email does fail DMARC, the existing policy will dictate what happens to the message (quarantine, reject, or accept).
What are the technical details of DMARC?
A couple more details about DMARC…
#1 – Report reception
DMARC gives marketers the option to receive reports detailing which messages passed or failed, and—if any do fail—where in the authentication process those failures occurred (SPF, DKIM, or domain alignment). Such insight is incredibly valuable because it can help identify phishing attacks and infrastructure vulnerabilities.
#2 – Organization-wide coverage
DMARC can be published on an organizational level, and—when it is published at the organizational level—will cover all subdomains unless there is a unique subdomain policy set to override DMARC. The advantage here is that it allows email marketers to set up one policy for their entire organization without having to create unique DMARC policies for every single domain affiliated with the business.
Tying It All Together
By combining all three authentication protocols (SPF, DKIM, and DMARC), receiving servers can confirm that…
- An that an IP is authorized to mail
- The sender is who they say they are
- The sender is being transparent about their identity to the recipient
For this reason, Zeta requires the use of SPF and DKIM for all clients, and recommends the deployment of DMARC as well.
Due to their technical nature, email authentication processes can be difficult to understand and implement. For that reason, Zeta wants you to reach out with any questions you may have about the process, or how you can use email authentication to achieve better results with your enterprise marketing.
