Email Authentication: the Ultimate Guide

Email authentication is becoming a big deal. Authentication allows the mailbox provider to confirm that the sender is the one who he pretends to be. If authentication fails, the emails are likely to be filtered as spam or rejected.

Thus, email marketers should set up authentication records for their sending domains to increase the trustworthiness in the eyes of the receiving email servers.

And it’s important to regularly test email authentication records using an email spam checker to make sure that the messages won’t go to the spam folder due to a failed authentication.

Here’s a guide to the key email authentication standards:

What is DKIM?

DKIM (DomainKeys Identified Mail) is an open, DNS-based email authentication standard that uses public key encryption to authenticate email messages. DKIM is used to ensure that the message has not been altered in transmission.

Message originators generate a hash of the email message, encrypt that hash using a private key, and include the encrypted hash (the cryptographic signature) in the message header. That signature is also associated with a DNS domain (included in the mail header with the signature).

The public key corresponding to the private key is published under a specific subdomain of the DNS domain used in the signature. Because only the domain owner (or someone they authorize) should be able to publish a DNS record for the subdomain, this associates the public key with the domain owner.

When a mail server receives a DKIM-signed message, it sees the public key in DNS. The mail server uses the public key to decrypt the signature included in the message header. The mail server then computes a hash of the incoming message using the same algorithm as the message originator. If the computed hash matches the decrypted signature, then the message is authenticated. Otherwise, DKIM authentication fails.

Learn More: What is DKIM – DKIM Checker

What is a DKIM selector?

To support many DKIM records for the same domain, the DKIM standard introduced the DKIM selector. A selector is simply a sequence of one or more DNS domain labels. The selector is included as a field in the DKIM message header.

A receiving mail server uses the selector and the domain included in the DKIM header to determine the exact domain to retrieve the DNS record containing the public key from.

The DKIM record domain is formed as follows:

<selector>._domainkey.<header domain>.

For example, if a DKIM signature has a selector abc.xyz and a domain of test.com then the corresponding DKIM record domain would be abc.xyz._domainkey.test.com.

Is it necessary to change the DKIM keys?

There is no rule for how frequently the sender needs to change the DKIM keys used to sign email messages.

But a frequent rotation of DKIM keys is the most effective measure you can take to increase the security of DKIM authentication. So updating the DKIM keys once a year is strongly recommended.

You should be aware that changing a DKIM key record can cause messages that may be in transit and that were signed with the original DKIM key to fail DKIM authentication. This can happen if the DNS record with the public key is changed.

The standard solution to this problem is to use multiple selectors for your DKIM signatures, and only change one at a time. This allows you to rotate DKIM keys without breaking any in-transit messages that may not have been processed by the receiving servers yet.

For example, you could set up two DKIM key DNS records in your domain with selectors “s1” and “s2.” You sign the messages with both “s1” and “s2” keys, generating two signatures on the message.

When updating the “s1” DKIM key, that signature will fail to verify in some circumstances, but the “s2” DKIM signature will continue to verify, authenticating the message.

At a later time, when updating the “s2” DKIM key, the “s1” DKIM key will be constant, and a similar process will occur.

What DKIM key size is recommended?

At a minimum, 1024 bit keys should be used. The Google’s server and some other receivers consider keys smaller than 1024 bits insecure, and will not use them for authentication.

Many cryptographers feel that a key size of 1024 bits will likely become insecure in the next few years. So, you may want to consider a larger key size (e.g. 2048), which is likely to be secure against cryptographic attacks for the foreseeable future.

If you are sending email campaigns with EasyMail7, see this tutorial on how to add a DKIM signature to your emails

What is SPF?

SPF (Sender Policy Framework) is an open, DNS-based email authentication system that allows sending domains to define which IP addresses are allowed to deliver email messages on behalf of the domain.

Here are the important things email marketers should know about the SPF authentication:

SPF is tested for the domain used in the “Envelope-From” addresses (aka MAIL FROM and Return-Path). In order SPF can be used to authenticate the message sender, the “Envelope-From” domain must match the “From” header field domain up to the second level. The use of the incorrect addresses for the “Envelope-From” is one of the most common errors of the SMTP server configuration which leads to the SPF authentication failure.

Some email messages (NDR, DSN) have a blank “Envelope-From” field. For such emails, SPF authentication is performed by the domain that the sending SMTP server uses in the HELO/EHLO command.

Invalid names in the HELO command is another common problem. You need to make sure that the domain name in the HELO is correct and set the appropriate SPF policy for it, for example, mailserver.example.org. TXT “v = spf1 a -all”.

You also need to check that the domain is not used in the delivery failure messages. Or if the domain is used, make sure it matches the domain in the HELO command up to the second level.

It is important to understand that the domain in the human readable “From” address will not be used for SPF record lookup unless it matches the “Envelope-From” or HELO/EHLO domain.

SPF is not applicable to subdomains. It is necessary to implement it for each subdomain or use wildcards DNS.

Read Also: How to Create SPF Record & Optimize it

What is the DNS lookup limit?

When checking whether or not an email message passes SPF authentication, a receiving mail server may have to make one or more DNS lookups.

Typical situations where such a lookup might be required include:

• when evaluating an “include” directive to pull in the SPF rule defined on another domain;
• when checking an IP address against an “a”, “mx”, or “ptr” directive which require an A, MX, or PTR DNS lookup respectively to evaluate.

To protect receiving mail servers from denial of service attacks the SPF standard includes a hard limit on the number of domain lookups such a server is permitted to make. That limit is 10 lookups.

Most email service providers publish an SPF record in DNS for use by their customers. These customer-focused SPF records frequently include other domains or have additional directives that require domain lookups, so that their total contribution to the lookup count may be much larger than 1.

Customers are then asked to ensure that the SPF record published on their own domain has an “include” directive referencing the domain on which the email service provider published their SPF record.

Unfortunately, this makes it very easy for domain owners to exceed the SPF domain lookup limit. It’s also not necessarily obvious when the SPF domain lookup limit has been exceeded. SPF records consist of a set of rules, each one evaluated sequentially. So if a message is validated by one of the rules defined early in the SPF record, the message will authenticate even though the SPF record as a whole is broken.

Messages which are intended to be authenticated by rules that appear later in the SPF record will fail, because the receiver will stop evaluating the record before it reaches those rules.

Domain owners should attempt to limit the number of “includes” in the SPF records for their domains, to help ensure that they don’t exceed this limit. And email service providers should not recommend or require that domain owners add an “include” directive unless it is absolutely necessary.

Here you can find more tips on how to optimize the SPF record to avoid SPF failures and DNS lookup errors.

What SPF policy is better?

The most commonly used policies are a neutral policy SPF (neutral,?) or a soft block (soft reject, ~). When SPF is used with DMARC it does not matter what kind of default SPF policy (neutral, soft reject ~ or reject -?) is used.

It is not recommended to use the “reject” policy (-) with the exception of the most secure domains, since this can negatively affect the delivery of legitimate emails sent to mailing lists.

Here’s an example of a simple SPF record authenticating a single service:

v=spf1 include:_spf.google.com –all

Here’s an example of a more complex record, with additional services and some dedicated IP addresses:

v=spf1 include:spf.protection.outlook.com ip6:2001:db8::/32 ip4:203.0.113.6 –all

How to authenticate messages sent with SPF in a DMARC-compatible way?

It depends on how you are handling bounce messages. Let’s consider three scenarios:

#1. You don’t need to intercept bounce messages.

In this case, just use the message’s “From” address for the “Return-Path” address. Publish an SPF record with your mail servers that your customers can include in their domain’s SPF record.

#2. You need to intercept bounce messages, and you can use a customer’s subdomain in the “Return-Path” address.

In this case, your customer has delegated a subdomain of their domain to you, using either a CNAME or NS record. Use this subdomain in the “Return-Path” address for messages you send on their behalf.

Publish an SPF record on the domain that includes the IP addresses of the mail servers sending email on the customer’s behalf.

#3. You need to intercept bounce messages, but you can’t use a customer’s subdomain in the “Return-Path” address.

In this case, SPF cannot be used to authenticate messages in a DMARC-compatible way. Instead, you should use DKIM to authenticate your messages.

How does SPF differ from Sender-ID?

Sender-ID is now an outdated alternative email authentication standard. It is similar to SPF but has a few differences.

The most significant difference between SPF and Sender-ID is how the two standards determine which domain(s) to use to determine the SPF rule to apply to the message. Because the lookup process is different between the two standards, messages that authenticate with SPF may not authenticate with Sender-ID and vice versa, even though all of the DNS records are the same.

As we described above, SPF uses the domain from the “Return-Path” address to determine the DNS record containing the relevant SPF record. Sender-ID may use this address (called the mfrom in Sender-ID parlance), the human-readable “From” address (called the pra in Sender-ID parlance), or both to determine whether a given message is properly authenticated.

Sender-ID records are DNS TXT records starting with v=spf2.0. These should not be confused with SPF records, which start with v=spf1.

As Sender-ID is now an obsolete standard, there is no longer any need to configure Sender-ID DNS records. If you have any Sender-ID records currently set in DNS, you may want to remove them.

Read also: How to Deploy SPF Email Authentication

What is DMARC?

DMARC (Domain-Based Message Authentication, Reporting, and Conformance) is an open email authentication standard that sending domains use to block fraudulent emails.

DMARC is built on top of two earlier standards — SPF and DKIM — and adds additional features like reporting, policy definition, and the notion of identity alignment.

When configured correctly, DMARC can completely stop phishing attacks in which the attacker sends an email with a “From” address that appears to originate from a protected domain. As this is the primary form of phishing attack, DMARC is a very effective tool to defend customers, employees, partners, and others from phishing.

Large mailbox providers email receivers, such as Google, Microsoft, and Yahoo!, require email messages to be properly authenticated in a DMARC-compliant way. So adding a DMARC record for a domain, in conjunction with properly configured SPF and/or DKIM records, will help ensure deliverability.

Furthermore, the proper use of DMARC ensures that messages sent by spammers using a sender’s domain will not negatively impact the domain’s overall reputation. Such spam emails will be blocked and the sender’s brand will be protected.

What are organizational domains?

To support flexible domain matching, DMARC introduced the concept of an organizational domain. Typically, this is the top level domain (TLD) plus one more label.

For some countries, that use second-level domains to categorize organizations, the organizational domain is this second-level domain plus one more label.

Examples of organizational domains are:

nytimes.com
bbc.co.uk
wikipedia.org

And the following domains share the same organizational domain (bbc.co.uk):

mail123.bbc.co.uk
abc.def.x-y.bbc.co.uk
bbc.co.uk

How does DMARC help SPF and DKIM?

DMARC contributes three major elements to the SPF and DKIM email authentication standards:

Reporting. DMARC-participating receivers agree to provide email authentication reports to sending domains. This allows the owners of these sending domains to understand the current state of email authentication for their domain, see legitimate services that may not be properly authenticating, and identify sources of domain abuse.

Policy. With DMARC, sending domains can recommend how a receiver should treat an email that fails authentication, rather than leaving it to the discretion of the receiver. This allows sending domains to authenticate all sources of legitimate email over time, rather than requiring domain owners to fix all authentication issues immediately. A report-only policy of “p=none” can be useful during this investigation phase, but domain owners should strive to reach an enforcement level of “p=quarantine” or “p=reject”.

Identity alignment. Among multiple sources of identity in an email message (including the “From” address, DKIM signature identity, and “Return-Path” address), DMARC prioritizes the human-readable “From” address as a source of identity, and only considers authentication results for identities that are aligned with this “From” address.

SPF and DKIM use different sources of identity, and so the authentication they provide will only prevent fraud if their source of identity matches the human-readable “From” address in some way. In this situation, the identities are considered “aligned.”

In cases where SPF or DKIM authenticates with an identity whose domain doesn’t match the domain in the human-readable “From” address, the non-matching authentication result is simply discarded. DMARC does not cause any change in the underlying SPF or DKIM behavior and the corresponding identities against which they authenticate.

Therefore, passing SPF or DKIM isn’t enough to ensure that a message passes DMARC. Often messages pass SPF and/or DKIM but fail DMARC because of identity misalignment.

How to configure DMARC for a domain?

DMARC is configured through the use of DNS TXT records. A domain owner adds a special DNS TXT record on the “_dmarc” subdomain of the domain for which they’d like to configure DMARC. This DNS TXT record defines the policy for the domain.

The DMARC standard defines a lookup rule for DNS records, which explains how the relevant DMARC policy DNS record is determined. The rule is as follows:

• extract the email domain from the human-readable “From” address;
• look up a DMARC record on the “_dmarc” subdomain of the email domain;
• if no record is found, and the email domain is not an organizational domain, then look up the “_dmarc” subdomain of the corresponding organizational domain. If a record is found on this subdomain, use that record to determine the DMARC policy.
• if no record is found, then the process terminates and DMARC is not enforced for the message.

A key takeaway from this process is that it is generally sufficient to define a single DMARC record on the organizational domain. Even if an email service provider or domain owner is using a subdomain to send email, they don’t need to create separate DMARC records for each subdomain.

You can quickly check if your domain is protected with DMARC and SPF using the GlockApps real-time domain checker.

What does a DMARC DNS record look like?

In most DMARC DNS records, there are only four attributes:

v — “DMARC1” for the current DMARC revision. This attribute must appear the first.

p — specifies the enforcement level requested by the sender. Allowed values are “none”, “quarantine”, and “reject”. This attribute is required and must be the second attribute in the record.

none: receivers are instructed to not change how they deliver email based on email authentication failures. The “none” policy is typically used when a domain owner is in the initial process of authenticating their email services; moving beyond this level is key to enable DMARC to stop fraud.

quarantine: receivers are asked to mark messages failing authentication as spam.

reject: receivers are requested to block messages failing authentication entirely, and not deliver them to their intended recipients.

In all cases, the policy is enforced by the system receiving the email, and the receiving system may choose to handle the email differently than prescribed by the DMARC policy. For example, Microsoft Office 365 treats “quarantine” and “reject” identically.

rua — a comma-separated list of URLs for aggregate report delivery. These are typically “mailto” URLs. This attribute is optional.

ruf — a comma-separated list of URLs for forensic/failure report delivery. These are typically “mailto” URLs. By default, forensic reports are sent only in case of DMARC violations. You can use the “fo” option to regulate it. At present, a relatively small number of receivers send forensic reports. This attribute is optional.

So a sample DMARC record for example.com might be:

v=DMARC1; p=quarantine; rua=mailto:dmarc_agg@example.com; ruf=mailto:dmarc-reports@example.com

Below are some other optional attributes of a DMARC record and recommendations for their usage:

sp (sp=quarantine) – policy for subdomains that do not publish their own policy. If a subdomain has its own DMARC policy, the “sp” is not applied. If there is no “sp” field in a DMARC record for subdomains that do not have their own policy, then the policy in the “p” field is applied.

pct (pct=20) – percentage of emails the policy is applied to. For example, the “reject pct = 20” policy means that the “reject” policy will be applied to a received message with the probability of 20% and the “quarantine” policy – with the probability of 80%.

fo (fo=1) – regulates sending of forensic reports. “fo=0” (default behavior) sends the reports only when both SPF and DKIM authentications failed. “fo=1” sends reports when any of the authentications fails even if an alternative method passes. “fo=s” sends forensic reports when there are problems with the SPF authentication, and “fo=d” sends reports when there are problems with DKIM.

adkim (adkim=r) – verification of the correspondence of the DKIM domain. By default, the r (relaxed) mode is used which means that only the organizational domain must match. The strict (s) mode requires the full match of the domain in the sender address with the domain of the DKIM-signature. It makes sense to use the strict mode if a part of your subdomains is delegated to untrusted parties.

aspf (aspf=r) – verification of the “Envelope-From” domain, which is checked for SPF and From. When “aspf=s” is set, these domains must match in order the message passes the SPF authentication.

ri (ri=86400) – desired interval (in seconds) of receiving aggregated reports. By default, reports are sent once a day, but some receivers (not all, because the support of this option by the server is not mandatory) support shorter intervals. At the stage of the implementation of the DMARC policy, you can try using a shorter interval, “ri=3600” for example.

What do DMARC aggregate reports provide?

DMARC aggregate reports provide information about which emails are authenticating against SPF, DKIM, and DMARC, and which are not.

While aggregate reports do not provide much information about the email messages themselves, they can provide valuable insight into the health of your email program and help you identify potential authentication issues and/or malicious activity.

So, the DMARC aggregate report includes:

1. ISP information:

Mailbox provider name (tag: org_name)
Mailbox provider’s sending email address and additional contact information
Report ID number
Beginning and ending date range in seconds

2. A line-by-line description of your DMARC record:

Header domain/friendly from domain
Alignment settings for both DKIM and SPF (tag: adkim and aspf)
Domain policy (tag: p)
Subdomain policy, if applicable (tag: sp)
Percentage of messages to which the DMARC policy is to be applied (tag: pct)

3. Summary of authentication results:

IP identified in the legitimate and/or fraudulent email (tag: source_ip)
Count of IP addresses identified (tag: count)
Disposition of the message, to show if policy was applied (tag: disposition)
DKIM authentication results–lists the domain and result (e.g. none, pass, or fail)
SPF authentication results–lists the domain and result (e.g. neutral, pass, or fail)

What is NOT included in the DMARC aggregate report:

Trends across ISPs. Identifying trends on IP addresses reporting across different ISPs is a great way to troubleshoot authentication issues and help ensure your legitimate email is getting delivered. However, aggregate reports do not contain trends.

Sender Score (reputation data). If an authentication failure is due to an IP address that does not belong to you (e.g. belongs to a third-party sending email on your behalf), you will have to do additional research on the reputation of that IP address to determine whether or not it is a legitimate sender. Return Path’s Sender Score tool can help.

Message samples. Aggregate reports do not contain message-level data. If you identify a questionable IP address within an aggregate report and need to find message-level data to troubleshoot it, you have to search both the aggregate and forensic report and make those connections manually.

Alerting capabilities. Once you move your domain to reject, you want to ensure your legitimate mail is not negatively affected by the new policy. Since aggregate reports do not contain trend data, there is no way to tell if your legitimate messages are getting blocked in bulk due to the “reject” policy.

What do DMARC forensic reports provide?

In addition to providing information about the email authentication, forensic reports include additional message-level data such as the subject line, “To” and “From” email addresses, the IP addresses of the sender and any URLs (URIs) included in the message.

Below is an overview of what is included in these DMARC forensic reports:

IP Information–the IP address that reportedly sent the message.

Time the message was originally received by the ISP (by the second).

Authentication results:
SPF
DKIM
DMARC Mechanism Check Result (Alignment Results)
ISP Information: the ISP that is sending the report.

From Domain information:
From address
Mail From address
DKIM from address (if DKIM is signed)
Subject Line
URLs (if any are contained)
Message ID
Delivery Result: whether the message rejected/quarantine/no policy applied based on the policy outlined in the DMARC record.

And here is what is NOT included in the DMARC forensic report:

Trends across ISPs. Just like with aggregate reports, you must identify trends such as subject line similarities and URLs across all the reporting ISPs yourself.

Sender score (reputation data). Again, you will be provided with the sending IP but the reputation of that IP will not be determined in the forensic report. You’ll have to investigate it yourself.

Automatic URL transfer. While the forensic reports will include malicious URLs pretending to be from your brand, they will not ship directly to your takedown provider.

Alerting capabilities. If you receive a forensic report for a domain that is not being used to send legitimate traffic, you’ll want to know about it right away so that you can protect that domain.

Similarly, if you are having authentication issues that are causing legitimate mail from your domain to not be delivered, you’ll want to be aware of that before it affects your mail on a wider scale.

DMARC Monitoring Made Easy

GlockApps allows you to dive into your email authentication and determine issues before they affect your email deliverability and sender reputation.

GlockApps DMARC Analyzer provides you with the ability to generate a DMARC record and collect your DMARC data in your account at GlockApps. Our service will decipher DMARC reports and present the DMARC data in the most convenient way for you.

GlockApps gives you plenty of information about your email sending sources, DMARC compliant and non-compliant emails, SPF and DKIM failures. You’ll get complete visibility into who is sending on behalf of your domain, how your emails are authenticated, and where the issues affecting your deliverability lay.

You can click on the number of the Sources to see all your sending sources. The sources with the highest number of emails will be your legitimate sources where all the messages must be DMARC-compliant. If you notice any issues with the SPF and/or DKIM evaluation for your legitimnate senders, you’ll want to address them.

Your goal is to achieve 90-100% DMARC compliance for your legitimate messages and switch to the “p=reject” DMARC policy to get the highest level of protection for your brand.

Achieving DMARC enforcement, you’ll benefit from:

1. Full control of all email senders. You’ll see all authorized and unauthorized uses of your domain.

2. Protection against impersonation. You’ll be able to detect any domain forgery attempts and block them.

3. Increased deliverability. You’ll increase your deliverability by 10-30% as email receivers have more trust in authenticated emails.

4. Increased brand reputation and ROI. You’ll see an increase in your email open rates as your subscribers and customers will more likely to open your email when they know that it really comes from you.

Sign up and get 10,000 free DMARC messages every month

Read also:

DMARC Monitoring and Reporting: Step-by-Step Guide
How You Can Leverage the DMARC Monitor to Fix Deliverability Issues
What is BIMI: Ultimate Guide to BIMI in 2023

In this chapter, we’re going to dive into some theory about Reverse DNS (rDNS) in order you can understand what rDNS is about and why this email authentication method is also important for good email deliverability.

Domain Name System (DNS) translates a domain name to the actual IP address on the Internet at which the computer for that domain resides, making it easy for the computers to find each other.

For example, when you send an email to domain1.com from your computer, your computer queries the DNS for domain1.com and it finds out that the server which you think of as “domain1.com” is known on the Internet at the IP address 11.22.333.444.

Your computer needs to actually connect and transmit the email to that IP address.

Reverse DNS or rDNS allows the opposite thing to happen. When your computer connects to the recipient’s computer to deliver an email message, rDNS allows the recipient’s computer to look at your computer’s IP address and see what domain name it claims to be.

So, rDNS takes a computer’s IP address and translates it to the computer’s domain name.

If you are a legitimate sender, then when the other computer does a reverse DNS lookup and asks the DNS system about the domain of your computer located at 55.666.77.888, the answer needs to be “that computer is more commonly known as yourdomain.com.”

Then the recipient’s computer knows that you are really who you say you are and delivers your email to the intended recipient.

But if the DNS system says that your computer is more commonly known as sendspam.com, then the recipient’s computer is going to reject the email from you.

All is clear here and you probably already know it.

But what will happen if the DNS system says that it doesn’t know what that computer is more commonly known as because there are no rDNS records set up?

Well, then a lot of computer systems and mailbox providers including the major ones will refuse to deliver your email because they don’t know if they can trust you.

At best, even if they don’t reject your email immediately, they will seriously lower the trust they give it, and just one more issue (such as a high level of complaints about emails coming from your IP address, or a high number of bounces due to poor list quality and hygiene, or spam trap hits) can tip the scales and your email gets rejected.

And if you decide to get whitelisted with ISPs to ensure the deliverability of your emails, a lot of ISPs now require working rDNS authentication records for your IP address.

If you don’t have rDNS set up for your IP addresses yet, it’s time to make the things configured. If you are using the SMTP server of your ISP, call or email to their support department. If you are using an email service provider to send the emails, you’ll want to contact them. If you have your own SMTP server, talk to your server admin or IT team.

To test whether your rDNS and other authentication records such as DKIM and SFP are properly set up, use our GlockApps spam testing tool. 

Plus, GlockApps will show your sender score, sending IP reputation, email spam score and explain why you got that score. It will point you to the issues related to the message HTML code, images, links, and content and provide the troubleshooting tips (suggestions) you can follow to fix deliverability issues and increase your Inbox rate.

You can quickly test your email using the live test below.

 

Additional Information

SPF– Sender Policy Framework for Authorizing Use of Domains in Email

DKIM– DomainKeys Identified Mail and DKIM DomainKeys Identified Mail

DMARC – Domain-based Message Authentication, Reporting & Conformance

MX – Mail Exchanger Record, see Domain Names – Implementation and Specification

RFC 6376 DomainKeys Identified Mail (DKIM) Signatures, Section 3.6.1 Textual Representation

RUA – Reporting URI for Aggregate reports, see DMARC.org, “DMARC Overview,”

RUF – Reporting URI for Forensic reports, see DMARC.org, “DMARC Overview,”

CNAME – Canonical Name record, see Domain Names – Implementation and Specification