Common errors in implementing email authentication that are causing your legitimate emails to not be delivered

DKIM, DMARC and SPF are important email authentication protocols that protect domains from being used for phishing and spamming attempts. However, misconfiguration of these protocols can lead to major problems, such as legitimate emails not being delivered from your domain.  

To introduce the topic, let's start with some definitions. There are three authentication methods currently in use: 

• Sender Policy Framework (SPF) is an email authentication method that uses DNS records to indicate which email servers are authorized to send emails on behalf of a particular domain.
• DomainKeys Identified Mail (DKIM) is an email authentication technique that relies on a digital signature, by which the public key can be consulted through a DNS lookup, to ensure an email has been sent by an authorized sender and that the content of the email has not been altered in the process.
• Domain-based Message Authentication, Reporting & Conformance (DMARC) is a method that allows domain owners to publish a policy in a DNS record that specifies which mechanisms (e.g., SPF, DKIM) are used to authenticate email messages sent from their domain, and what to do with messages that fail the authentication.

In an era where phishing is the gateway to a large percentage of cyberattacks, using one or more of these methods has become an industry standard. However, many mistakes are still being made. 

Here are the most common problems with implementing email authentication, in descending order of occurrence.

Not implementing DKIM, DMARC or SPF on domains that are not used for email 

A surprisingly large number of companies do not implement email authentication on domains that are not used for email, such as a domain containing a product brand name that is only used to promote a company's product. They likely reason that if "we don't use it for email, we don't need to implement email authentication."  

Unfortunately, this is not the case.  These are the domains that hackers look for to use in phishing attacks. They know that if email authentication is not implemented, anyone can spoof the domain to send emails. And if the domain is used for marketing purposes, recipients may be familiar with it and less likely to be suspicious of a phishing attack.

The DMARC policy is set to “none,” making DMARC useless

DMARC tells the receiving server what to do with messages that fail the authentication. This is what a DMARC TXT record looks like:

v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]; ruf=mailto:[email protected]

The “p” attribute specifies the DMARC policy, and what to do with a message that fails DKIM or SPF validation. The possible values are "none," "quarantine," or "reject." 

In the records we analyze, we often see “p=none,” which makes DMARC useless since every message from the domain property cannot be verified and is still delivered to the recipient. This amounts to having no DMARC policy at all. At the very least, you should set up a "quarantine" policy. The receiving server will place messages that fail authentication in the spam folder. When you are sure that everything is working as expected, you can switch to "reject." In this case, unauthenticated messages will be discarded by the receiving mail server.

Multiple SPF records for the same domain

Many companies allow multiple mail servers to send email, such as a corporate mail server (Google business email or Microsoft 365), a marketing platform for sending newsletters or transactional email, such as Mailchimp, Sendinblue or Sendgrid and a marketing automation platform, like Marketo, Hubspot or Omnisend.

Companies often add an SPF record for every authorized mail server. However, the SPF standard requires maintaining only a single TXT record, possibly containing multiple IP addresses or ranges for multiple authorized servers. Part of the confusion originates from the fact that for DKIM, it’s the other way around; for every authorized sender, a different record is required.

Syntax errors in DKIM and SPF records

The correct syntax of the name of the DKIM TXT record is essential for the DKIM process to work. The name of a DKIM record in which the public key of the signature is stored in the DNS is structured as follows: 

Selectorkey._domainkey.exampledomain., whereby both the selectorkey and the exampledomain value are variable. 

We often find that the trailing dot is forgotten, or that the “._” between the selectorkey value and the word domainkey are interchanged, or that one of the two symbols is not present.

The syntax of an SPF record is not simple either. In particular, the use of the symbols “+,” “~” and “- “ are a source of errors.  Here are 4 examples of SPF record values that look very similar but have completely different results.

V=SPF1 A ~ALL    : IP addresses specified in the A record of the domain can send email

V=SPF1 +ALL (or V=SPF1 ?ALL)     : All IP addresses on the internet can send mail (though ‘valid’, this is obviously not recommended)

V=SPF1 ~ALL      :  The domain sends no mail at all (except if a domain or IP address is added to the SPF record using the include: parameter), leaving it up to the DMARC policy to decide what to do with the email.

V=SPF1 -ALL     : The domain sends no mail at all (except if a domain or IP address is added to the SPF record using the include: parameter). Even if there’s no DMARC policy, the mail should be discarded.

Too many lookups in the SPF record

As companies use not only email servers for employees to send and receive email, but also multiple SaaS solutions to support sales and marketing activities, the number of platforms that need to send a company’s email has increased over the years. However, there can only be one SPF record per domain. This record must contain all mail servers that are authorized to send email. The RFC specifying the SPF mechanism (RFC7208) determines that the number of DNS lookups in an SPF record cannot be greater than 10 to defend against denial-of-service attacks. If lookups exceed 10, the receiving mail server will consider the sending domain to be malicious, and email from that domain will be rejected.

Test, test, test…and test again

The only way to ensure that email authentication works is to test your configuration after each change. There are several tools available on the Internet, some free, that can be used to check the validity of SPF, DKIM and DMARC records. Most external attack surface management (ASM) platforms also monitor email authentication.