Why Email Authentication Matters and How it Works
Identity theft, hacking, spoofing, phishing, and other malicious activities are widespread problems across the Internet – especially email. Why? Because the way in which an email is sent (Simple Mail Transfer Protocol aka SMTP) from one computer to another, actually allows for a computer to identify any domain as its sending domain and “from” address. This vulnerability is one way in which email is exploited – hence why sending laws and authentication protocols were introduced (and why email authentication matters).
Initially, email authentication methods were few and simple; however, as technology advanced, so did the methodologies and the protection they provided. By utilizing the sender’s DNS (Domain Name System) as the base for authenticating a sender’s credentials, receivers can verify the incoming mail is truly being sent and authorized by the company the sender is identifying as.
Authentication results are used by Internet Service Providers (ISPs) as one of the many factors in their algorithms to determine acceptance and placement. If authentication methods are not used or do not pass, while the ISPs may still accept the mail the lack of authentication could impact placement – meaning your emails could end up in the junk folder.
Over the last decade, there have been three main methods that have emerged that are now considered best practices. Below, we outline what they are, how they work, and the benefits.
What is it?
SPF simply is a permission check. More formally, SPF is an authentication policy that specifies the Internet Protocol (IP) and mail servers authorized to send on behalf of a domain.
Technical details about SPF are:
How does it work?
When an email is received, the receiving server takes the sending domain, either from the envelope-from address (also known as the return-path) or HELO command, and looks up the authorized IP(s) allowed to send on its behalf in the SPF record. The authorized IPs are then compared to the sending IP identified during the connection. The result (pass/fail, listed/not listed) is written into the header and then incorporated into the filtering decisions that determine if acceptance is granted and, if so, placement. In some instances, SPF can create false positives due to how the message path changes. For example, forwarded emails, as mentioned above, will be sourced from the IP the forwarding customer is using instead of the originating IP of the sender, which will result in a failed SPF authentication test.
What Is DKIM?
DKIM essentially is an identity check. DKIM provides the recipient a way to validate the domain’s identity that is taking responsibility for the message.
Additional technical details about DKIM are:
How does it work?
When an email is received, the receiving server takes the domain specified in the DKIM signature (d) and looks up the public key in the DNS. If the public key matches the private key written into the DKIM signature (b), then the domain is authenticated and DKIM passes. If the keys do not match, DKIM fails, but does not necessarily cause the message to be rejected. In most cases, the result will be incorporated into the overall filtering decision for acceptance and placement.
What is DMARC?
In most cases, the subject line, “From” name, and “From” address are relied on to indicate to a recipient who is an email from and what it is about. DMARC was established to address disguised emails by adding another level of authentication that checks that the identity shown to the customer is the same identity shown to the receiving server.
The transparency check ensures the customer is seeing the same domain that is being authenticated through SPF and DKIM. The DMARC policy gives instructions on what to do with a message that fails to pass authentication AND domain alignment. Instead of relying on ISPs’ filters to determine acceptance and placement, DMARC gives the domain owner direct control over what happens to mail coming from unauthorized sources.
Another benefit of DMARC is that it gives the option to receive reports detailing which messages passed or failed and where in the authentication process the message failed (SPF, DKIM, and/or domain alignment tests), which can help to identify phishing attempts and infrastructure vulnerabilities.
Additional technical details about DMARC are:
How does it work?
Once an email goes through SPF and DKIM authentication checks, the receiving server checks for a DMARC policy associated with the From Address domain. If one exists, identifier (domain) alignment tests are performed to confirm the identity shared with the customer matches the identity shared with the receiving server. In other words, if a sender claims to be from @rhyzetamigrdev.wpengine.com to the customer, but states that they are @nonsender.com to the receiving server, the identifier alignment test will fail.
If DMARC is published on the organizational level, the policy will cover all subdomains unless a unique subdomain policy is set to override it. The organizational level is beneficial as it gives the sender the ability to set up one policy without having to create a unique DMARC policy for all domains that are mailing or could be spoofed.
DMARC requires that only one authentication method pass WITH proper alignment. For example, even if DKIM fails to pass the authentication check, as long as SPF passes authentication and the identifier alignment test, then DMARC too will pass. When DMARC does fail, the policy will dictate what will happen with the message, whether it be to send the email to quarantine, reject it, or allow it to move on.
Summary
By combining all three email authentication protocols, receiving servers can now check that an IP is authorized to mail, confirm the sender is who they say they are, and is transparent about their identity to the customer.
Email authentication can be a very technical and difficult topic to sort through and understand. If you have any questions or want to learn more about how Zeta Global can help improve your email program, reach out today.
Initially, email authentication methods were few and simple; however, as technology advanced, so did the methodologies and the protection they provided. By utilizing the sender’s DNS (Domain Name System) as the base for authenticating a sender’s credentials, receivers can verify the incoming mail is truly being sent and authorized by the company the sender is identifying as.
Authentication results are used by Internet Service Providers (ISPs) as one of the many factors in their algorithms to determine acceptance and placement. If authentication methods are not used or do not pass, while the ISPs may still accept the mail the lack of authentication could impact placement – meaning your emails could end up in the junk folder.
Over the last decade, there have been three main methods that have emerged that are now considered best practices. Below, we outline what they are, how they work, and the benefits.
Email Authentication Check #1 – Sender Policy Framework (SPF)
What is it?
SPF simply is a permission check. More formally, SPF is an authentication policy that specifies the Internet Protocol (IP) and mail servers authorized to send on behalf of a domain.
Technical details about SPF are:
- SPF is posted in a TXT record of a domain’s DNS.
- A failed SPF policy does not guarantee an email will be blocked or bulked, which is why the addition of DKIM and DMARC is important (more on these soon!)
- An SPF policy is not limited to permitting a single IP, but can specify one IP, multiple IPs, an IP range(s), a domain, or a list of domains.
- If a domain is used, the SPF policy for the listed domain will be used as the basis for authentication.
- Zeta Global creates SPF policies with the domain of our sending servers, providing the flexibility to add or change IPs without having to update the SPF policies already in use.
How does it work?
When an email is received, the receiving server takes the sending domain, either from the envelope-from address (also known as the return-path) or HELO command, and looks up the authorized IP(s) allowed to send on its behalf in the SPF record. The authorized IPs are then compared to the sending IP identified during the connection. The result (pass/fail, listed/not listed) is written into the header and then incorporated into the filtering decisions that determine if acceptance is granted and, if so, placement. In some instances, SPF can create false positives due to how the message path changes. For example, forwarded emails, as mentioned above, will be sourced from the IP the forwarding customer is using instead of the originating IP of the sender, which will result in a failed SPF authentication test.
Email Authentication Check #2 – Domain Keys Identified Mail (DKIM)
What Is DKIM?
DKIM essentially is an identity check. DKIM provides the recipient a way to validate the domain’s identity that is taking responsibility for the message.
Additional technical details about DKIM are:
- DKIM is posted in a TXT record of the domain’s DNS.
- DKIM relies on the content to remain intact between when authentication is signed and when it is received and validated.
- A failed DKIM policy does not guarantee an email will be blocked or bulked.
- DKIM uses two keys, public and private, that must match to authenticate a domain’s identity.
- Cryptographic authentication is used to match these keys.
- The private key (or hash) is written into the header of an email when it is assembled and mailed and the public key posted in the responsible party’s DNS.
- DKIM recommended length, at minimum, is 1024 bit – Zeta Global requires at least 1024 bit.
How does it work?
When an email is received, the receiving server takes the domain specified in the DKIM signature (d) and looks up the public key in the DNS. If the public key matches the private key written into the DKIM signature (b), then the domain is authenticated and DKIM passes. If the keys do not match, DKIM fails, but does not necessarily cause the message to be rejected. In most cases, the result will be incorporated into the overall filtering decision for acceptance and placement.
Email Authentication Check #3 – Domain-based Message Authentication, Reporting & Conformance (DMARC)
What is DMARC?
In most cases, the subject line, “From” name, and “From” address are relied on to indicate to a recipient who is an email from and what it is about. DMARC was established to address disguised emails by adding another level of authentication that checks that the identity shown to the customer is the same identity shown to the receiving server.
The transparency check ensures the customer is seeing the same domain that is being authenticated through SPF and DKIM. The DMARC policy gives instructions on what to do with a message that fails to pass authentication AND domain alignment. Instead of relying on ISPs’ filters to determine acceptance and placement, DMARC gives the domain owner direct control over what happens to mail coming from unauthorized sources.
Another benefit of DMARC is that it gives the option to receive reports detailing which messages passed or failed and where in the authentication process the message failed (SPF, DKIM, and/or domain alignment tests), which can help to identify phishing attempts and infrastructure vulnerabilities.
Additional technical details about DMARC are:
- DMARC is posted in a TXT record of a domain’s DNS.
- DMARC builds upon SPF and DKIM authentication credentials and results.
- The use of SPF AND DKIM are recommended even though only one authentication method is required.
- DMARC can be set up to monitor only, without affecting delivery.
- DMARC can follow a strict policy where only exact domain matches pass or a more relaxed set of policies that gives flexibility to the sending domains used.
- DMARC protection can be used on any organizational domain or subdomain regardless of whether it’s used in sending email or not.
How does it work?
Once an email goes through SPF and DKIM authentication checks, the receiving server checks for a DMARC policy associated with the From Address domain. If one exists, identifier (domain) alignment tests are performed to confirm the identity shared with the customer matches the identity shared with the receiving server. In other words, if a sender claims to be from @rhyzetamigrdev.wpengine.com to the customer, but states that they are @nonsender.com to the receiving server, the identifier alignment test will fail.
If DMARC is published on the organizational level, the policy will cover all subdomains unless a unique subdomain policy is set to override it. The organizational level is beneficial as it gives the sender the ability to set up one policy without having to create a unique DMARC policy for all domains that are mailing or could be spoofed.
DMARC requires that only one authentication method pass WITH proper alignment. For example, even if DKIM fails to pass the authentication check, as long as SPF passes authentication and the identifier alignment test, then DMARC too will pass. When DMARC does fail, the policy will dictate what will happen with the message, whether it be to send the email to quarantine, reject it, or allow it to move on.
Summary
By combining all three email authentication protocols, receiving servers can now check that an IP is authorized to mail, confirm the sender is who they say they are, and is transparent about their identity to the customer.
Email authentication can be a very technical and difficult topic to sort through and understand. If you have any questions or want to learn more about how Zeta Global can help improve your email program, reach out today.
