SPF, DKIM and DMARC in plain words

Why your emails land in spam and the three records that fix it.

Mailbox providers decide in a fraction of a second whether your email is trustworthy. Three DNS records answer their questions: who may send for this domain, is the message untouched, and what to do when something does not match.

Since 2024, Gmail, Yahoo and Outlook require them from anyone sending in volume: SPF and DKIM for every message, a DMARC record, and a visible From address that matches. Smaller senders are judged on the same signals. Without these records, a perfectly legitimate invoice looks exactly like phishing.

What a receiver does with one message

Picture an invoice sent from [email protected] through your accounting software. Before it reaches the inbox, the receiving server runs three checks in a row:

1. 1SPF. It looks at the server that connected and asks the domain of the bounce address whether that server is allowed to send. The accounting software's servers must be listed.
2. 2DKIM. It reads the signature in the message header, fetches the public key named by the selector and checks that the body and the main headers were not changed.
3. 3DMARC. It looks at the From address people will see, harborgoods.com, and checks that at least one of the two previous checks passed for that same domain. Then it applies your policy to the result.

Only then do reputation, content and engagement come into play. A message that fails all three rarely gets that far.

SPF: who may send

SPF is a TXT record at the root of the domain, starting with v=spf1. It lists the servers allowed to send email for your domain: your mail provider, your newsletter tool, your CRM, your helpdesk.

harborgoods.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Each include: pulls in the list of servers published by a provider. The ending tells receivers what to do with everyone else: ~all means "probably not us, treat with suspicion", -all means "definitely not us, reject". Start with ~all while you check that every sender is listed, then move to -all.

Three rules keep SPF working:

• Exactly one record. A domain must have a single SPF record. Two records, often left by a new provider's setup wizard, make both invalid.
• Ten lookups at most. Every include, a, mx and redirect costs a DNS lookup, including the ones nested inside the providers' records. Past ten, SPF fails for every message. Remove the tools you no longer use before adding new ones.
• SPF checks the hidden sender. It validates the bounce address, not the From address people see. That is why SPF alone does not stop spoofing, and why DMARC exists.

DKIM: is the message untouched

DKIM signs each email with a private key held by the sending service. The public key is published in DNS under a selector, a name chosen by the provider, for example google._domainkey or s1._domainkey.

google._domainkey.harborgoods.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

The receiving server reads the selector from the message header, fetches the key and checks the signature. A message changed in transit, or forged by someone who does not hold the key, fails.

Every tool that sends on your behalf needs its own DKIM key, published under its own selector: your mailboxes, your newsletter tool and your billing system each sign separately. Use 2048-bit keys when the provider offers them, and rotate them when someone with access leaves or a provider is replaced. Removing an old selector too early breaks the signature of messages still in flight, so leave it for a few days after the switch.

DMARC: what to do on failure

DMARC is a TXT record at _dmarc starting with v=DMARC1. It ties SPF and DKIM to the From address people actually see, tells receivers what to do when both fail, and where to send reports.

_dmarc.harborgoods.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

The important tags:

A message passes DMARC when SPF or DKIM passes and the domain it validated is aligned with the From address. A newsletter sent through a provider that signs with its own domain passes DKIM but fails DMARC, until you publish the provider's DKIM key on your domain.

Reading a DMARC report

Aggregate reports arrive once a day from each large receiver, as a zipped XML file. Each row says: this IP address sent this many messages as your domain, SPF gave this result, DKIM gave that one, and this is what we did. A report analyser groups the rows by sending service so you can answer three questions quickly:

• Which services send as you that you did not know about? Often a forgotten form plugin, a helpdesk or a scanner that emails PDFs.
• Which known services fail alignment? Usually a provider whose DKIM key was never published on your domain.
• Which sources are simply forged? Those are the messages DMARC will block once you enforce it.

Rolling out DMARC without losing email

Going straight to p=reject is the fastest way to block your own invoices. Roll it out in stages:

1. 1Publish p=none with a rua address and read the reports for two to four weeks. A free or paid report analyser turns the XML into a list of sending sources.
2. 2For every legitimate source that fails, add it to SPF or publish its DKIM key. Unknown sources sending as you are exactly what DMARC will stop.
3. 3Move to p=quarantine, optionally with pct=25 then pct=100, and keep reading reports.
4. 4Once reports stay clean, move to p=reject.

Check your records yourself

Any terminal can show what receivers see:

dig +short TXT harborgoods.com | grep spf1
dig +short TXT google._domainkey.harborgoods.com
dig +short TXT _dmarc.harborgoods.com
dig +short MX harborgoods.com

Then send a message to a Gmail address, open it and choose "Show original": the header summary shows SPF: PASS, DKIM: PASS and DMARC: PASS when everything is aligned.

Forwarding, mailing lists and subdomains

Forwarding breaks SPF: when a message is forwarded, the forwarding server connects to the final receiver with its own address, which your SPF does not list. DKIM survives forwarding as long as the message is not modified, which is why every sender should sign with DKIM and not rely on SPF alone. Mailing lists that add a footer or a subject prefix break DKIM too; modern list software rewrites the From address to avoid DMARC failures.

For marketing and bulk email, consider a dedicated subdomain such as news.harborgoods.com with its own SPF, DKIM key and DMARC record. Complaints about a campaign then weigh on the subdomain's reputation, not on the domain your invoices and password resets come from.

Protect the domains that never send

Parked domains and old brand names are favourite targets for spoofing because nobody watches them. Tell the world they send nothing:

parked-brand.com.         TXT  "v=spf1 -all"
_dmarc.parked-brand.com.  TXT  "v=DMARC1; p=reject"
parked-brand.com.         MX   0 .

The last line is a null MX: it states that the domain accepts no email at all, so senders get an immediate bounce instead of retrying for days.

When you change email provider

A migration is when most of these records break. Before the switch, add the new provider to SPF next to the old one and publish its DKIM key under its own selector, so both can send during the move. Lower the TTL of the MX records a day ahead so the change spreads quickly. On the day, update MX, send test messages to a few large providers and check the headers. A week later, once nothing arrives on the old side anymore, remove the old provider from SPF and delete its DKIM selector. Keep DMARC unchanged throughout: its reports are the best way to see that no legitimate message slipped through.

Common mistakes

• Two SPF records after switching mail providers.
• An SPF record over ten lookups after years of added tools.
• A DKIM key published with a typo or split across two strings incorrectly by the DNS host.
• DMARC reports sent to an address nobody reads.
• A DMARC record on the main domain only, while a subdomain used for marketing has none and no sp policy covers it.
• DNS records left behind for a mail or marketing service nobody uses anymore: a forgotten record can let a stranger take over the subdomain (see orphaned subdomains).