Email has a design flaw that is almost too silly to believe: the From address is just text. Anyone's server can send a message claiming to be from your domain, and without extra checks, nothing stops it arriving. SPF, DKIM and DMARC are the three DNS records that fix this, and between them they decide whether your legitimate mail lands in the inbox or the spam folder.
The records themselves look like line noise: v=spf1 include:... ~all, p=MIGfMA0..., p=quarantine; rua=mailto:.... This guide decodes all of it in plain English, tag by tag.
The big picture: three records, three jobs
- SPF answers: "which servers are allowed to send email for this domain?"
- DKIM answers: "was this exact message really sent by the domain, and has it been altered on the way?"
- DMARC answers: "when a message fails those checks, what should the receiver do with it, and who gets told?"
All three live as ordinary TXT records in your DNS (if TXT records are new to you, start with our plain-English guide to DNS records). A receiving mail server looks them up in the seconds after your message arrives and uses them to decide: inbox, spam, or rejected.
SPF: the approved-senders list
An SPF record is a single TXT record on the bare domain listing every server allowed to send mail as you. A typical one:
v=spf1 include:_spf.google.com ip4:203.0.113.10 ~allRead left to right: "this is SPF version 1; Google's servers may send for me; so may the server at 203.0.113.10; treat everything else with suspicion." The pieces:
| Part | Plain English |
|---|---|
v=spf1 | "This is an SPF record." Always first, always exactly this. |
ip4: / ip6: | A specific server address (or range) that may send. |
include: | "Also trust everything in this other domain's SPF record." This is how you authorise Google Workspace, Microsoft 365, Mailchimp and the rest. |
a / mx | "The servers in my A or MX records may send too." |
redirect= | "Ignore this record, use that domain's SPF instead." Rare; used to centralise SPF across many domains. |
-all | Hard fail: "anything not listed is not mine, reject it." |
~all | Soft fail: "anything not listed is probably not mine, be suspicious." The sensible setting while you are still finding all your senders. |
?all / +all | "No opinion" and "everyone may send as me". The second is an open door; never use it. |
Two rules cause most SPF breakage. First, a domain may have only one SPF record; a second one does not add senders, it makes SPF fail outright. Second, SPF allows at most 10 DNS lookups per check, and every include: spends some. Stack enough SaaS tools and the record silently breaks with a "permerror". This is exactly the sort of thing worth checking with our free email deliverability checker.
DKIM: the tamper-proof signature
SPF checks where a message came from. DKIM proves the message itself is genuine. Your mail server signs each outgoing message with a private key; receivers fetch the matching public key from your DNS and verify the signature. If the message was forged, or altered in transit, the signature fails.
The public key lives at a special address: selector._domainkey.yourdomain.com. The selector is just a label (Google uses google, Microsoft uses selector1 and selector2) so a domain can hold several keys at once, which is what lets providers rotate keys without breakage. A typical DKIM record:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...| Tag | Plain English |
|---|---|
v=DKIM1 | "This is a DKIM key record." |
k=rsa | The key type. RSA is the norm; ed25519 exists but support is patchy. |
p= | The public key itself, the long block of gibberish. An empty p= means "this key has been revoked". |
t=y | Testing mode: "verify, but don't punish failures". Fine during setup, should not stay forever. |
s=email | Restricts the key to email use. Rarely seen, harmless. |
You will also meet DKIM in message headers: the DKIM-Signature header on every signed email includes d= (the signing domain) and s= (which selector to look up). Those two tags are how a receiver knows where to fetch your public key.
DMARC: the policy and the reports
SPF and DKIM on their own have a gap: neither is required to match the From address the human actually sees. A scammer can pass both checks using their own domain while displaying yours. DMARC closes the gap with alignment: to pass DMARC, the domain that passed SPF or DKIM must match the visible From domain.
The record lives at _dmarc.yourdomain.com. A typical one:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100| Tag | Plain English |
|---|---|
v=DMARC1 | "This is a DMARC record." |
p= | The policy for failures. none = "just tell me", quarantine = "send it to spam", reject = "refuse it outright". |
sp= | A separate policy for subdomains. Without it, subdomains inherit p=. Attackers love forgotten subdomains, so sp=reject is worth considering. |
pct= | Apply the policy to this percentage of failing mail. pct=25 lets you phase in quarantine gently. |
rua= | Where daily aggregate reports go: XML summaries from receivers showing who is sending as your domain and whether they pass. This is DMARC's superpower, visibility. |
ruf= | Where per-message forensic reports go. Many providers no longer send them; do not rely on it. |
adkim= / aspf= | How strict alignment is. r (relaxed, the default) lets subdomains match; s (strict) demands an exact domain match. |
fo= | When to send forensic reports (e.g. fo=1: on any failure). Only matters if ruf= is set. |
The p=none trap: a DMARC record with p=none monitors but protects nothing; spoofed mail is still delivered. It is the right place to start, but it is a starting point. The standard rollout is: publish p=none with rua=, read the reports for a few weeks, fix the legitimate senders that fail, then move to quarantine and finally reject. Domains that stay on p=none for years are the rule, not the exception, and they are exactly what phishers look for.
What happens when your email arrives somewhere
- Your message hits the receiving server, claiming to be from
yourdomain.com. - SPF: the receiver checks whether the sending server's IP is in your SPF record.
- DKIM: it fetches your public key using the
d=ands=tags in the signature header and verifies the signature. - DMARC: it checks that at least one of the passes aligns with the visible From domain, and applies your policy if not.
- The verdict feeds the spam filter, and a line about you goes into the day's aggregate report.
The mistakes that quietly break email
- Two SPF records. Someone adds a new one instead of editing the existing one. SPF now fails for everybody.
- Blowing the 10-lookup limit. Each new tool adds an
include:until the record breaks, silently. - A third-party sender nobody aligned. The CRM sends "as you" but fails DMARC, and its mail dies the day you move to
p=reject. - Deleted or mangled TXT records. A DNS tidy-up removes what looked like clutter; deliverability decays over the following weeks. This is the failure mode we covered in why uptime monitoring isn't enough: nothing is "down", mail just stops arriving.
- Reports nobody reads.
rua=pointing at an inbox nobody opens is monitoring theatre.
Because all three records are just DNS entries, they share DNS's failure mode: changes are silent and the symptoms appear somewhere else, days later, as missing enquiries. Checking them once is easy with the free checker; watching them continuously across every domain you are responsible for is what email health monitoring is for, and it is layer five of the nine checks in our complete guide to monitoring client websites.
