A primer on email authentication.

Domain names are necessarily intertwined with email. The domain name connected with an email address is a signal for email services about the sender’s reputation, assisting the mailbox provider (MBP) and ISP when it determines what’s legitimate and what’s junk.

There are a few authentication mechanisms that domain owners can put in place to reduce the chances of phishers and spammers from spoofing their domains. In this post I’ll run through these at a high level; in later posts I’ll go more in-depth and explain how to set these up.

There are three main authentication mechanisms that domain owners can put in place.

Sender Policy Framework (SPF)

Think of SPF as a way to whitelist certain IP addresses that are validated to send email on behalf of your domain. You can tell email providers that only mail from a certain IP address or range of IPs is valid. Email from other IP addresses might be spoofed.

SPF is a way to reduce the chances that phishing and other emails that appear to be from your domain (but really aren’t) make it to the inbox. If you have a domain that you don’t use for email but people continually spoof it, you can add an SPF record that states that no mail should be sent from the domain.

Implementing SPF at its most basic level is quite easy. It requires adding a TXT record to the DNS.

DomainKeys Identified Mail (DKIM)

DKIM is more complicated than SPF and allows the sender to digitally sign certain components of the email.

With DKIM, the domain owner publishes a key in the public DNS. The outgoing email server signs the message. The recipient mail server uses the public key to check the signature and make sure it is valid. If so, then it shows that the signed fields have not been altered in route and passes DKIM.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

DMARC is a way for email senders to tell mailbox providers what action to take if an email fails authentication under SPF or DKIM and provides a reporting channel from mailbox providers back to senders.

A sender can tell the email recipient server what to do if a message fails authentication: let it pass through, quarantine it in the junk folder or reject the message.

Implementing DMARC is a journey, with companies typically publishing a DMARC policy with a ‘none’ policy setting to take inventory of mailstreams coming off their domain and gather reporting back from the participating mailbox providers. Once organizations have a clear understanding of legitimate vs. illegitimate mail coming off their domain, they can take action with their DMARC policy setting by selecting either a ‘quarantine’ or ‘reject’ policy.

Even if a company uses DMARC but tells the recipient server to take no action against mail that fails SPF or DKIM (policy=none), it will still benefit by using DMARC. That’s because email services will begin providing reports to the sender about the email it processes. This data includes IP addresses, rDNS, sending domain and other information helping senders track down either incomplete SPF or DKIM records or sources trying to spoof the company’s domain.

Like SPF and DKIM, DMARC involves a DNS record.