Deliverability 101: The true story of email authentication.

We can’t really finish a conversation about DNS, subdomains, and IP addresses without naturally progressing into email authentication. Why? Authentication is made up of all of these topics and a little more. It’s a nice building block in the tower of responsible email marketing.

In the early, Wild-West days of email marketing in the early 2000s, there were no rules. Senders operated email like it was a postal service, but way cheaper. They’d buy lists, send under multiple unrelated domains, send batch-and-blast email and so on. Then the spoofing, phishing, and scams showed up.

This is when internet service providers (ISPs) said, “Enough’s enough,” because this bad behavior was impacting their networks and making consumers unhappy. This was the birth of many of the best practices we now see in place today, including email authentication.

A new dawn was upon us…

Over the next few years, several groups including the International Engineering Task Force’s Anti-Spam Research Group, Yahoo, and Cisco developed the basis on which all email authentication standards rest. Those base policies spun off new, improved policies, and today we have five different authentication technologies to better safeguard your email on its journey to the inbox. More than 20 years after the inception of email, it’s clear: Email is not so simple anymore.

Let’s dig into these policies so you can better understand how they all work, and why they’re so important to implement.

Sender Policy Framework (SPF)
SPF is a DNS txt record letting a receiving mail server validate that the sending mail server’s IP is approved to deliver mail on behalf of that domain. It validates on the sender header, which can be your domain or your ESP’s domain. What can an SPF record contain? You can set them up to contain a single IP address or multiple ranges of IPs, another network’s SPF records may be included as approved sources or individual records like an A or MX record. SPF also allows you to apply a series or enforcement actions (“+” for pass, “-” for fail, “~” for “soft” fail, and “?” for neutral). Most mailers should use either “~” or “-” in their records.

Here’s an example:

+all (or pass) will tell a receiving domain that even if the record fails, they should pass the SPF test. This is the least secure setting.
-all (or fail) will tell a receiving domain to fail the test, should the mail originate from an IP outside of the approved networks listed in the record.

The “include” function is commonly used in SPF records to add a domain. This runs as a separate lookup on the same SPF record to validate the IP information listed above. Any more than 10 lookups per SPF record and you’ll likely encounter issues. Test your SPF records with our free SPF Analyzer tool: Simply enter your mailing domain and view the results.

DomainKeys Identified Mail (DKIM)
DKIM’s set-up is a little more involved than SPF, because it requires an encryption program, like OpenDKIM, to build the encrypted tokens for sent email and to validate them on the recipients’ servers. You’ll also need a whole bunch of keys: A pair of encryption keys, a public key put into your DNS, and a private key residing on your mail servers. The encryption program will validate the source content and the selected headers (which are determined during configuration) have not been modified during transmission between the source and destination mail systems. These typically include items like the from address, messageID, and the body of the email, among other indicators.

Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC is part of the authentication process but it’s really a sender-published policy for email messages that fail authentication. DMARC works alongside SPF and DKIM to request an action is taken by the receiving network, should both authentication solutions fail. There’s a tiered approach to DMARC actions, starting at doing nothing (p=none), to requesting the message be placed in the junk folder (p=quarantine), or finally, to fail the message and not even accept it (p=reject).

Another feature that really gives it value for brands and domain owners is the feedback received from mailbox providers validating with DMARC. A daily feedback file is sent to a specified email address to provide information on how many messages passed or failed authentication, the source IPs of these messages, and the domain alignment on the messages. What’s domain alignment? It’s whether or not the sender domain and the SPF/DKIM records use the same domains. All this daily data allows a brand to monitor for misuse of their domains and to identify spoofing or phishing events targeting their users.

Authenticated Received Chain (ARC)
ARC is a little different from the other authentication tools, as it’s not something a sender has to configure. It’s completely focused on the recipient server adding a series of data points showing they did the validation work on the original message they received before passing along the mail to another system or domain. This helps to resolve a number of issues identified when DMARC was originally designed, when some mail systems modified email messages to forward or re-send a message to a discussion list or alternate mailbox defined by the original recipient.

Brand Indicators for Message Identification (BIMI)
BIMI is designed to help provide a visual indicator of a legitimate and well-authenticated email communication from a brand. If a brand is using SPF, DKIM, and DMARC, they can include a BIMI DNS record that will display the logo of the company in the recipient’s inbox. It’s another brand touchpoint and helps further establish real and not real (read: dangerous) email from trusted senders.

As you can see, “Email is Hard.” Getting all these pieces correctly set-up and working together can take some time, effort, and expertise. It’s easy to break something along the way or introduce a typo that will give an unintended result for authentication. Luckily, you have us to help you get your email right.

For more information about deliverability, take a look at the 250ok Deliverability Guide, and check back here regularly for more deep looks at the topics covered within it.