sveltemail

← All guides

SPF, DKIM and DMARC explained

What the three email authentication records do, how they fit together, and how to read the ones on your own domain.

The protocol that moves email between servers does not check who a message is from. A sending server states a sender address and the receiving server has no built-in reason to doubt it. SPF, DKIM and DMARC are three DNS records that close that gap. Each one answers a different question, and they only do their job when all three are in place.

Two sender addresses

Everything below depends on one fact: an email has two “from” addresses. The envelope sender is given by the sending server during delivery and is where bounces go. It ends up in the Return-Path header. The header From is inside the message and is the one your mail app shows. They can be different, and often are. The guide to reading email headers shows both on a real message.

SPF: which servers may send

SPF is a TXT record on your domain that lists the servers allowed to send mail for it.

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all"

Read it left to right:

  • v=spf1 marks the record as SPF.
  • ip4:192.0.2.0/24 allows any address in that range. If the notation is unfamiliar, see subnetting and CIDR.
  • include:_spf.example.net also allows whatever that other domain's SPF record allows. This is how you authorize a mail provider or newsletter service.
  • -all says everything else fails. ~all is the softer version: everything else is suspicious but not a definite fail.

When a message arrives, the receiving server takes the domain from the envelope sender, looks up its SPF record, and checks whether the connecting IP address is on the list.

SPF has two limits. It checks the envelope sender, not the From address people see, so on its own it does not stop someone forging your name. And it breaks when mail is forwarded, because the forwarding server is not on your list.

DKIM: a signature on the message

With DKIM, the sending server signs each message with a private key and adds the signature as a header. The matching public key is published in DNS so any receiver can verify it.

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

The name has three parts: a selector (s2026), the fixed label _domainkey, and the domain. The selector lets one domain have several keys, one per sending service or one per year. The signature header on each message says which domain and selector to use:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s2026;
    h=from:to:subject:date:message-id; bh=...; b=...

A valid signature proves two things: the message was signed by someone holding the private key for the domain in d=, and the signed headers and body have not changed since. Unlike SPF, DKIM survives plain forwarding, because the signature travels with the message. It breaks when something edits the message on the way, as mailing lists do when they add a footer or a subject tag.

DMARC: tying both to the From address

Neither check above looks at the address the reader sees. A forger can pass SPF using their own envelope domain and sign with their own DKIM key, while putting your address in From. DMARC is the record that closes this.

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

DMARC adds one rule, called alignment. A message passes DMARC if at least one of these is true:

  • SPF passes, and the envelope sender's domain matches the From domain.
  • DKIM passes, and the signing domain in d= matches the From domain.

By default “matches” is relaxed: a subdomain counts, so a bounce address at mail.example.com aligns with a From at example.com. Adding aspf=s or adkim=s requires an exact match.

The other tags say what to do about failures:

  • p= is the policy. none asks receivers to change nothing, quarantine asks them to treat failing mail as spam, and reject asks them to refuse it.
  • rua= is where receivers send aggregate reports: periodic summaries of which servers sent mail using your domain and how it scored.
  • sp= optionally sets a different policy for subdomains. Without it, subdomains inherit p.

A rollout order that does not lose mail

The risk in setting this up is not forgers. It is blocking your own legitimate mail from a system you forgot about. Go in this order.

  1. List everything that sends as your domain. Your mail provider, newsletter service, billing system, help desk, website contact form, office printers.
  2. Publish SPF covering those senders, ending in ~all for now.
  3. Turn on DKIM at each sender, signing with your domain, not the provider's default.
  4. Publish DMARC with p=none and a rua address. Nothing changes for delivery, but reports start arriving.
  5. Read the reports. Look for legitimate sources that fail or pass without alignment, and fix them. Sources you do not recognize are either forgotten systems or forgers.
  6. Move to p=quarantine once the legitimate sources all pass. Keep watching the reports.
  7. Move to p=reject when quarantine has been quiet for a while, and tighten SPF to -all.

Common mistakes

  • Two SPF records. A domain may have only one TXT record starting with v=spf1. Adding a second for a new service makes SPF fail with an error. Merge the mechanisms into one record.
  • Too many lookups. SPF allows at most ten DNS lookups while it is evaluated, and every include counts, including the ones nested inside it. Past ten, the result is an error.
  • Ending SPF in +all. That authorizes every server on the internet.
  • Passing without aligning. A newsletter service that uses its own bounce domain and its own DKIM key passes SPF and DKIM and still fails DMARC. Set up a custom sending domain with the service.
  • Stopping at p=none. Monitoring mode protects nothing. It is a step, not a destination.
  • Ignoring domains that send no mail. A parked domain can be forged too. Give it v=spf1 -all and a DMARC record with p=reject.

Reading the records on your own domain

The email security checker looks up the SPF record on a domain and the DMARC record at its _dmarc name. It shows each record as published, the qualifier your SPF record ends with, your DMARC policy and the address reports go to, and it rates each one from missing to protected. The DNS lookup shows all of a domain's TXT records together, which is the quickest way to spot a duplicate SPF record, alongside the MX records that say where its mail is delivered.

Checking DKIM

DKIM can't be checked from the domain name alone, because the selector could be anything. Send yourself a message from the domain, view its source, and paste the headers into the email header analyzer. The Authentication-Results line shows whether SPF, DKIM and DMARC passed at the receiving end, which is the only place the answer counts.