SPF, DKIM and DMARC explained

Why email needs three layers

Email was designed when everyone on the network was trusted. Nothing in the basic protocol stops someone from sending a message whose From address says [email protected]. SPF, DKIM and DMARC were added later, as three separate pieces that together let a receiving server check whether a message really came from where it claims. All three are published in DNS as TXT records, so you can read them with a TXT lookup.

Each answers a different question. SPF asks: was this message sent by a server the domain approves? DKIM asks: was the message signed by the domain, and has it been altered since? DMARC asks: does either answer match the address the reader actually sees, and what should happen if not?

SPF: who may send

A Sender Policy Framework record lists the IP addresses and services allowed to send mail for a domain. When a server receives a message, it looks at the envelope sender (the hidden Return-Path address used between servers, not the From header) and checks whether the connecting IP is allowed by that domain's SPF record.

example.com.  IN TXT  "v=spf1 ip4:203.0.113.0/28 include:_spf.google.com include:sendgrid.net ~all"

• ip4: and ip6: allow addresses directly. include: pulls in another domain's list, which is how Google Workspace, Microsoft 365 and email-sending services are authorised.
• The ending (~all softfail, -all fail) says what to do with everything else.
• The 10-lookup limit. Evaluating the record may cause at most 10 DNS lookups (each include, a, mx, redirect, exists and ptr, including nested ones). More than that is a permanent error.
• A domain must publish only one SPF record.
• SPF breaks when mail is forwarded, because the forwarder's IP is not in your record.

Build one with the SPF record generator and verify it with the SPF checker.

DKIM: proof the message is genuine and unchanged

DomainKeys Identified Mail adds a digital signature to each outgoing message. Your mail provider signs selected headers and the body with a private key. The matching public key is published in DNS under a selector, at selector._domainkey.yourdomain. Receivers fetch the key and check the signature, which proves two things: the message was signed by someone who controls that domain's DNS, and it was not altered in transit.

# In the message
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUo...

# In DNS
selector1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

• d= is the signing domain and s= is the selector. Together they say where to find the key.
• Use 2048-bit RSA keys. 1024-bit keys are considered weak. Ed25519 (RFC 8463) is supported by some receivers, but not all.
• Because the signature covers the message, DKIM usually survives forwarding that does not change the content, which is where SPF fails.
• Rotate keys periodically by publishing a new selector, switching signing to it and retiring the old one later.
• Enabling DKIM is done at your mail provider, which gives you the DNS record (often a CNAME or TXT) to publish.

DMARC: tie it to the From address and set a policy

SPF and DKIM on their own can pass for a domain that is not the one the reader sees. A scammer can send from their own domain, pass SPF and DKIM there, and still write From: [email protected]. DMARC closes that gap with alignment: a message passes DMARC only if SPF or DKIM passes and the domain it authenticated matches the domain in the visible From address.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"

• p= is the policy: none (monitor), quarantine (spam folder) or reject (refuse).
• rua= is where receivers send daily aggregate reports, which show every source sending mail as your domain and whether it passed.
• adkim and aspf set alignment to relaxed (r, subdomains of the same organisation match) or strict (s, exact match).
• sp= and np= cover subdomains and non-existent subdomains.
• The newest specification, DMARCbis (RFC 9989), adds np, psd and t, and drops pct, rf and ri. Large providers still honour the older tags.

Create a record with the DMARC generator and inspect any domain's policy with the DMARC checker.

How they work together

A receiving server runs all three checks and records the verdict, usually in an Authentication-Results header you can read in the message source:

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=bounce.example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass header.from=example.com

The order to set them up

1. List every senderYour mail provider, marketing platform, invoicing tool, ticketing system, website forms, CRM and any servers of your own.
2. Publish SPFOne record, ~all to begin with, within 10 lookups.
3. Enable DKIM everywhereAt each provider, use your own domain for signing so it aligns.
4. Publish DMARC with p=none and a reporting addressRead the reports for two to four weeks. Fix each legitimate source that fails.
5. EnforceMove to p=quarantine, then p=reject once the reports are clean. Consider sp=reject and np=reject for subdomains.
6. Optional extrasMTA-STS and TLS reporting protect delivery in transit, and BIMI shows your logo in some mailboxes once DMARC is at enforcement.

Why you cannot skip this any more

In 2024 Google and Yahoo began requiring senders of large volumes (Gmail's threshold is 5,000 messages a day to its users) to authenticate with SPF and DKIM, publish a DMARC record, align the From domain, offer one-click unsubscribe and keep spam complaint rates low. Microsoft introduced comparable requirements for high-volume senders to Outlook.com in 2025. Even small senders benefit: authenticated mail is far less likely to be spam-foldered, and a domain with enforced DMARC is much harder to impersonate.

Common mistakes

• Two SPF records, or more than 10 lookups.
• DKIM enabled at one provider but not at the others, so those messages fail DMARC.
• Jumping to p=reject before reading any reports.
• Reports going to a mailbox nobody reads.
• Putting the DMARC record at the wrong name instead of _dmarc.
• Forgetting that every subdomain that sends mail needs its own authentication, or inherits the parent's DMARC.
• Expecting SPF alone to protect the From address.

Debug any of these with the TXT lookup, the SPF checker and the DMARC checker.