The 4 most frequent email authentication mistakes
Email authentication consists of a trio of standards that ensure emails actually come from who they say they come from. The three standards — SPF, DKIM, and DMARC — work together to ensure that email can be trusted.
As we speak with customers, we have found that most have at least attempted to configure SPF. Fewer have configured DKIM or DMARC. Unfortunately, in many cases, even when they’ve attempted it, the configuration is not done right. (Use our handy email authentication checker to see if it’s set up correctly for your domain.)
This post covers the four most common errors we see customers making when configuring these three.
Doing authentication right is more urgent than ever. In 2015, the email world received a wakeup call from the big email receivers (Google, Microsoft, and Yahoo!) that in 2016 they will start marking emails that do not pass email authentication as suspicious. This will be a one-way ticket to the spam folder.
1) SPF: The dreaded 10-lookup limit
When the SPF standard was developed, the authors specified that a receiving mail server should not perform any more than ten DNS lookups as part of evaluating an SPF record. At the time, this was not a problem because most senders operated their own email services.
Most email service providers publish an SPF record in DNS for use by their customers. However, these customer-centric SPF records frequently include other domains, or have additional directives that require domain lookups, so that their total contribution to the lookup limit may be much larger than one. Customers are then instructed 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 run into the SPF domain lookup limit. It is not uncommon, even when using two to three services, for sender domains to exceed the SPF lookup limit.
Worse, it’s not always 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.
Read more about SPF’s 10-lookup limit.
2) Fat-finger errors
Typos can trash configurations for all three authentication standards.
SPF: It is not uncommon for organizations to have syntax errors in their SPF records. Some common mistakes:
- Spacing (all mechanisms in an SPF record must be separated by spaces)
- Using ‘=’ where you should have used ‘:’
- Using IP addresses where domains are required or the reverse
Any of these errors will cause the entire SPF record to be invalid.
DKIM: The most common errors we see with configuring DKIM are usually related to copy and paste. Since a DKIM entry requires adding a public encryption key to DNS, it is not uncommon for the DNS management console to accidentally truncate a key or inject extra characters/carriage returns. An invalid key will cause message authentication to fail
DMARC: DMARC records are normally fairly simple, but it is important to ensure that all the most important settings are included and in the right order. Some common mistakes here:
- Missing aggregate reporting email (rua=): The rua specifies the email address(es) to send DMARC aggregate reports to. If you don’t specify this, you will not get any reports so you will not have any visibility into what is happening.
- Setting subdomain policy (sp=) to none: This will disable DMARC protection on any subdomains and leaves your subdomains open to spoofing/phishing.
- Policy setting (p=) not in the right place: The policy must be specified immediately after the version (v=).
- Putting the DMARC TXT record on the wrong domain: In order to configure DMARC for a domain, you must create a subdomain for the DMARC configuration, such as _dmarc.example.com. If you do not specify the DMARC TXT record under the _dmarc subdomain, DMARC authentication will not work.
3) Getting to monitor mode….and staying there
DMARC uses both SPF and DKIM to validate emails. In order for an email to pass DMARC, one of the two must pass. It is not necessary that both SPF and DKIM pass.
DMARC consists of three different policy actions that apply if an email fails authentication:
- p=none: Monitor mode; take no action
- p=quarantine: Mark the email as suspicious. This usually means the email will end up marked as spam.
- p=reject: Any emails that fail validation will not be delivered.
When an organization first sets up DMARC, it will normally start with a policy of None. That means that even if an email fails DMARC authentication, the email will still be processed and delivered. This is the recommended way to start with DMARC and should always be the first step.
The problem arises when the organization stops at None. Even if DMARC (and SPF and DKIM) are properly configured, an email that fails validation will still be delivered. Organizations should plan to move from None to at least Quarantine and later to Reject after the configuration has been validated. Leaving the policy at None provides no protection against malicious emails that purport to come from the organization’s domain.
4) Not reading DMARC reports
DMARC causes email receivers like Google, Microsoft, and Yahoo! to send DMARC reports to the sender, usually once per day. These reports can be used by the sender (or by ValiMail or other service providers) to see trends and spot suspicious senders.
The DMARC reports contain a lot of valuable information. Reading and acting on DMARC reports, however, can take a lot of effort to do properly:
- Reports are in XML format, which can be difficult for humans to read.
- Reports can be very long (hundreds of thousands of lines).
- DMARC reports only list IP addresses of the sender of the emails, which means you need to resolve these to hostnames to better understand who is attempting to send on your behalf. Additionally, many third party senders are cloud-based and may use many different IP addresses, which can make identifying the senders in the report even more difficult.
If you don’t read the reports, you don’t know who is sending (or attempting to send) emails on your behalf. There may be cases where legitimate emails are failing DMARC because they were set up by another group in the company and were not properly configured for SPF or DKIM. You will likely also see emails being sent as you from malicious senders.
Although configuring email authentication can be challenging, there is help available. ValiMail can automate and maintain all of your email authentication. Contact us for a free demo.