Best Practices

How Email Authentication Works

How Email Authentication Works

Best Practices

Email authentication is a daunting subject. There’s an alphabet soup of acronyms and initialisms. There are often casual references to technologies that usually only IT professionals are familiar with. But the core concepts are not complicated, and most everyone will be able to quickly understand them.

Email authentication has become increasingly necessary as spammers and phishers continue to use email to distribute unwanted or harmful messages. Most email servers now use a number of protocols to verify messages before they reach the intended recipient. Messages that are not properly authenticated are likely to have deliverability problems and end up undelivered or in the spam folder.

Let’s talk about the three most important email authentication protocols in plain language, using real-world analogies.

SPF – Sender Policy Framework

The first and oldest is called Sender Policy Framework (SPF). SPF allows a sender to verify their authenticity. If you receive a letter in your mailbox printed on official letterhead, you can be reasonably sure that it’s authentic. Another way to think of an email that passes SPF is a certified letter from the post office. There is a tracking number provided, and you can verify who the sender is by calling the post office.

SPF is also analogous to confirming a return address. If you received a letter where the business name didn’t match any businesses listed at the letter’s return address, you would be rightly skeptical of that letter. This kind of check is usually unnecessary for physical mail, but it is necessary for email because it’s trivially easy to send a message claiming to be from someone else.

During SPF, a receiving email server can ask the domain that the email claims to be from for a list of IP addresses that are allowed to send email on that domain’s behalf. If the domain doesn’t list the originating server as a valid sender, then the email is most likely not genuine and the SPF check will fail.

DKIM – DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is a newer and more robust way to authenticate messages. DKIM is like a wax seal on a letter. Before reliable postal infrastructure, letters were authenticated with a sealing wax embossed with a signet ring belonging to the sender. The hardened wax bonded with the parchment and made it nearly impossible to tamper with the letter without leaving evidence.

The symbol pressed into the wax served as a kind of signature, as only one person would have had access to the signet ring. By inspecting the envelope, the recipient could verify both the authenticity of the sender and that the contents were unaltered.

email authenticationLet’s imagine another way to ensure the authenticity of the sender and the integrity of the message contents during transit. Think of a box with a locking drawer and a locking lid. The drawer can only be locked with the sender’s key. We’ll call this key the sender’s private key.

The lid can be locked and unlocked by a key that is freely available. Anybody can request a copy of the key. In fact, the sender has provided all of the post offices along the delivery route with a copy of this key. We’ll call this the public key.

Under the lid is a pane of glass. By unlocking the lid anyone can inspect the package through the glass, but cannot tamper with it without breaking the glass and leaving evidence. Upon inspection, an interested party can confirm the official letterhead, see that the glass is intact, and verify that the drawer is locked with the key that only the sender has. Each post office along the way opens the lid to make sure that the package is still intact.

DKIM works in a similar way to this box. The sender has a cryptographic private key that is used to encode the message headers. The public key is made available on a decentralized public internet registry called the DNS or Domain Name System. Any of the servers involved in passing the message along to the final destination can retrieve the public key and decrypt the headers to verify that the message is valid. And just like the locked box, the public key cannot be used to encrypt the headers (and lock the contents of the drawer); only the private key can do that.

We can also think of this like another class of postal mail available at the post office. If SPF-authenticated email is certified mail, then DKIM-authenticated messages are registered mail, kept under lock and key at all times along the delivery route to prevent tampering.

DMARC – Domain Message Authentication Reporting and Conformance

Imagine that someone sends you one of these fancy double lockboxes. The courier bringing the package performs one final check before delivering it. She looks up the delivery conformance policy for the sender of the package. Their policy says that the package should have originated from a trusted address (SPF).

The package should also have been in a locked box from a trusted source holding a private key and should be verifiably unaltered in transit (DKIM). The policy further stipulates that if the SPF and DKIM conditions are not met, the courier should quarantine the package and inform the sender of the violation.

This policy is analogous to a Domain Message Authentication Reporting and Conformance (DMARC) policy. DMARC is the latest authentication tool, built on both SPF and DKIM. It’s a way for senders to inform recipients which authentication methods to check for and what to do if a message claiming to be from them does not pass the required checks. Instructions might include marking the message as quarantined and therefore likely to be suspicious or rejecting the message completely.

You might wonder why senders would ever want to allow messages that don’t pass DMARC to be delivered. DMARC also provides a feedback loop so senders can monitor whether emails that appear to be originating from their domains are conforming with the policy or not. For some providers like Microsoft and Gmail, many systems have been sending messages with domains like hotmail.com and gmail.com in the From address for a long time.

An abrupt change to a strict DMARC policy would negatively impact many senders, so they continue to allow messages that fail DMARC to be delivered. However, that will be changing soon.

secure email authentication

Review

To review, there are three widely used authentication protocols:

  1. Sender Policy Framework (SPF) performs a check similar to verifying a return address to authenticate a sender’s identity.
  2. DomainKeys Identified Mail (DKIM) authenticates a sender’s identity as well, but goes further by ensuring the contents of the message are unaltered by using a locked box or a wax seal.
  3. Domain Message Authentication Reporting & Conformance (DMARC) is the courier that makes sure messages meet SPF and DKIM requirements before they are delivered.

What Email Authentication Means For Senders

With DMARC, domain owners finally have full control over the “from” address over that appears in a recipient’s’ email client. Large mailbox providers like Yahoo! and AOL have already implemented strict policies. Emails that appear to originate from these domains but that fail authentication checks will get dropped. Gmail and Microsoft plan to implement similar changes very soon.

What this means is that you should never send from domains that are not configured to allow your server via DKIM and SPF. If you send emails on behalf of clients, you’ll want to ensure your clients have the correct DNS entries in place to enable this.

For recipients, the increased popularity of these technologies means a reduction in phishing and spam emails that get delivered. And that’s always a good thing.

Additional Resources

A DKIM FAQ from SendGrid’s Email Compliance Team

Sender Policy Framework (SPF): A Layer of Protection in Email Infrastructure

What is DMARC?


Brandon West
More Posts by Brandon
As Director of Developer Relations for SendGrid, Brandon's focus is on empowering developers to build things, gathering feedback for new features and improvements, and fostering a cooperative developer community for anything that needs email integration.
Follow Brandon