SPF, DKIM and DMARC: getting your email into the inbox

In short

When your email arrives, the receiving server asks three questions. Is the server that sent it allowed to send for your domain? That's SPF. Is the email signed by your domain and unchanged on the way? That's DKIM. And what should happen if those checks don't match the sender? That's DMARC.

Gmail and Yahoo now require email to be authenticated with SPF or DKIM, and high-volume senders also need DMARC. Without the records, email lands in spam more often or is rejected. Microsoft is tightening up the same way.

SPF: who may send for your domain

SPF is a TXT record on your domain listing the servers allowed to send email for it. The receiver looks it up and checks whether the sending server is on the list.

company.dk.  TXT  "v=spf1 mx include:spf.newsletter.example ~all"

mx

Your own mail servers may send.

include:

A provider's servers may send too, such as your newsletter tool. The provider tells you what to add.

~all

Everything else is suspicious. With -all it's rejected. Never use +all, which lets anyone send as you.

There can only be one SPF record per domain, and it may trigger at most 10 DNS lookups. Every include counts, and so do the lookups the provider's own record makes.

DKIM: a signature on every email

DKIM signs every email with a private key kept on the mail server. The public key sits in DNS under a name called a selector, so the receiver can check that the email comes from you and wasn't changed on the way.

mail._domainkey.company.dk.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

Every service that sends for you needs its own DKIM key: the mail server, the newsletter, the bookkeeping system that sends invoices. Use 2048-bit keys. DKIM also survives forwarding, where SPF usually breaks.

DMARC: the rule that ties it together

DMARC requires the domain in the From address to match the domain that passed SPF or DKIM. That's called alignment, and it's what stops others sending email that looks like yours. The record also says what the receiver should do with email that fails, and where to send reports.

_dmarc.company.dk.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none

Do nothing, just send reports. This is where you start.

p=quarantine

Email that fails goes to spam.

p=reject

Email that fails is rejected. That's the goal.

rua=

The address that receives daily reports on who sends in your domain's name.

How to roll it out

The danger with DMARC is moving too fast, so your own email gets rejected. Take it in this order.

1. Find everyone who sends for your domainEmail, newsletter, bookkeeping system, web shop, contact forms and booking. Those are the ones that get forgotten.
2. Combine them in one SPF recordAnd stay under the 10 lookups.
3. Turn on DKIM with each of themThe providers give you the records to add to DNS.
4. Start DMARC at p=noneWith a rua address, so you get reports.
5. Read the reports for a couple of weeksFix the senders that fail until they all pass.
6. Tighten upMove to p=quarantine, then to p=reject.

If you have domains that never send email, lock them down with v=spf1 -all and a DMARC record with p=reject. Then they can't be used for fake email.

Common mistakes

Two SPF records

Then both are invalid. Combine them into one.

More than 10 lookups

SPF fails for every email. Remove providers you no longer use.

Forgotten senders

The newsletter or bookkeeping system sends from your domain without SPF and DKIM. The DMARC reports show it.

Jumping to p=reject

Then real email gets rejected. Give the reports time first.

SPF only, no DKIM

Forwarded email fails, because SPF doesn't survive forwarding. DKIM does.

Questions