Deliverability
9 min read
What are SPF, DKIM and DMARC, and do I need all three?
Three records decide whether your mail is believed. The acronyms describe file formats, which is why every explanation is confusing — here is what each one is for.
Short answer
SPF lists which servers are allowed to send mail using your domain. DKIM adds a cryptographic signature that proves a message really came from your domain and was not altered on the way. DMARC tells receiving servers what to do when a message fails those checks, and asks them to send you reports. You need all three: SPF and DKIM are the evidence, and DMARC is the instruction that makes the evidence count.
SPF
Who may post as you
A public list of the servers allowed to send mail using your domain. The receiving server checks whether this message came from one of them.
Without it: Anyone anywhere can send mail claiming to be your domain, and nothing contradicts them.
DKIM
A seal that proves it is unaltered
Your sending server signs each message with a private key. The receiver checks the signature against the public key you publish in DNS.
Without it: A message can be forged or altered in transit and still look like it came from the right place.
DMARC
What to do when a seal is broken
Your standing instruction to every receiving server — ignore, quarantine, or reject — plus a request to send you reports about what they saw.
Without it: Each receiver decides for itself, so failures are inconsistent and invisible to you.
Why there are three of them
Email was designed without any way to prove who sent a message. Anyone can write any address in the From: line, exactly as anyone can write any return address on an envelope. Everything that followed is an attempt to add proof on top of a system that shipped without it — which is why it arrived in three separate pieces rather than one clean design.
SPF came first and answers one question: was this message sent by a server the domain owner approved? It works by listing approved servers publicly. Its weakness is that it checks the envelope rather than the visible From: address, and it breaks when a message is forwarded, because the forwarding server is not on the list.
DKIM answers a different question: has this message been altered, and does it carry a signature only the domain owner could produce? It survives forwarding, because the signature travels with the message. Its weakness is that a signature proves a message is intact, not that anyone should trust the sender.
DMARC ties them together and adds the two missing pieces: it requires that the domain proven by SPF or DKIM actually matches the From: address a human sees, and it publishes what receivers should do when nothing matches. It also asks receivers to send you reports, which is the only way to find out who is sending as your domain.
SPF and DKIM produce evidence. DMARC is what turns evidence into a decision — without it, each receiving server guesses, and you never find out what it guessed.
SPF: the list of approved senders
SPF is a single TXT record on your domain listing every service allowed to send as you. Each service you use — your mail provider, an invoicing tool, a newsletter platform — contributes one entry.
Record 1
TXT- Namealso called “Host / Hostname”
- @ (the bare domain)
- Type
- TXT
- Valuealso called “Content / Data”
- v=spf1 include:mail-service.example include:invoicing.example ~all
- TTL
- 3600
~all means “anything not listed above is suspicious” — the safe setting. -all means “reject it outright”, which is stricter and unforgiving of a service you forgot.
include: entries are the services you have authorised; ~all closes the list.The two mistakes that matter
The first is publishing two SPF records. The specification allows exactly one; when a receiver finds two, it is entitled to treat the check as permanently broken, and many do. Two services set up years apart is the usual cause. The fix is to merge them into a single record containing both include: entries.
The second is exceeding the lookup limit. Evaluating an SPF record is capped at ten DNS lookups, and each include: can consume several. A domain that has accumulated six or seven services can quietly cross the limit, at which point the check fails for everyone — with no error message anywhere, because the failure happens on someone else's server.
DKIM: the signature that survives the journey
DKIM is a pair of keys. The private half lives on the sending server and never leaves it; the public half is published in your DNS. Every outgoing message is signed with the private key, and any receiving server can check that signature against the public one.
What that proves is precise and worth stating exactly: the message was sent by something holding your private key, and the signed parts of it have not been altered since. It does not prove the content is true, and it does not prove the sender is trustworthy — it proves authenticity and integrity, which is what a seal on an envelope does.
Record 1
TXT or CNAME- Namealso called “Host”
- selector._domainkey
- Type
- TXT (or CNAME, depending on the provider)
- Value
- v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3…
The public key is long and must be pasted exactly. A truncated key does not produce a warning — it produces a signature that never validates, which looks identical to no DKIM at all.
_domainkey preceded by a selector, which lets a domain hold several keys at once — one per service, and one spare during a key rotation.DMARC: the instruction and the reports
DMARC does two jobs. It requires alignment — that the domain proven by SPF or DKIM matches the From: address a person actually sees, which closes the gap that let a message pass SPF while displaying somebody else's name. And it publishes your policy: what a receiving server should do when a message fails.
Start here
A message arrives claiming to be from your domain
Did SPF or DKIM pass, and does it match the visible From: address?
Delivered normally
The message is authenticated. It still passes through ordinary spam filtering — authentication proves who sent it, not that it is wanted.
This is the outcome you are engineering for
Your policy decides
p=none — deliver anyway but report it. p=quarantine — treat as suspicious, usually spam. p=reject — refuse it outright.
Reports arrive either way, which is the point of starting at none
p=none and read the reports before you tighten it — that is the whole method.Record 1
TXT- Namealso called “Host”
- _dmarc
- Type
- TXT
- Value
- v=DMARC1; p=none; rua=mailto:[email protected]
rua is where aggregate reports are sent. Without it the policy still applies, but you learn nothing — and learning is the entire reason to start at p=none.
p=none changes nothing about delivery. It only asks receivers to tell you what they are seeing, which is what you need before tightening anything.The order to do this in
Day 0
Publish SPF and DKIM
List every service that sends as you, and publish a DKIM key for each one that offers it. This is evidence-gathering; nothing is being enforced yet.
Day 0
Publish DMARC at p=none with a reporting address
Changes nothing about delivery. Starts the flow of reports that tells you who is sending as your domain.
Weeks 1–4
Read the reports
You will find senders you forgot about. Every one of them needs adding to SPF or given a DKIM key before you tighten anything.
Week 4+
Move to p=quarantine
Failures now go to spam rather than the inbox. Keep reading reports; this is where a missed sender becomes visible without being lost.
When quiet
Move to p=reject
Only once reports show nothing failing except actual forgeries. At this point impersonating your domain stops working.
If a service configures this for you, it should do all three, publish them for you, and keep checking they are still correct. Records drift — a provider rotates a key, somebody edits the zone, a service is added — and a record that was right last year is not evidence that it is right today.
What to remember
- SPF lists who may send as you. DKIM proves a message is genuine and unaltered. DMARC says what to do when neither holds.
- You need all three: SPF and DKIM are evidence, DMARC is the instruction that makes the evidence count.
- Exactly one SPF record per domain, ever. Two is a fault that breaks the check entirely.
- Several DKIM keys is normal and correct — one per sending service, each under its own selector.
- Start DMARC at
p=nonewith a reporting address, read reports for a few weeks, then tighten. Starting atp=rejectrejects your own mail.
Questions people ask next
Do I really need all three, or is SPF enough?
SPF alone is not enough. It checks the envelope rather than the address a person sees, so a message can pass SPF while displaying someone else's name, and it fails whenever mail is forwarded. DKIM covers the forwarding case and DMARC closes the mismatch. Together they answer the question each one alone cannot.
What does p=none actually do?
Nothing to delivery — that is its purpose. It asks receiving servers to apply no special treatment to failures but to send you aggregate reports about what they saw. It is an observation mode, and it is the only safe way to discover which of your own services would break under a stricter policy.
Why did my SPF record stop working when I added a service?
Most likely the ten-lookup limit. Each include: can consume several DNS lookups, and once the total exceeds ten the check fails outright for every message — with no error visible to you, because the failure happens on the receiving server. Reducing the number of includes, or flattening them, is the fix.
Can I have two SPF records if I have two providers?
No. One record, with an include: for each provider. Two separate SPF records is a fault that many receivers treat as a permanent failure, which is worse than having no SPF at all.
What is a DKIM selector?
A label in the record's name that lets one domain publish several DKIM keys at once. Each sending service uses its own selector, so they never collide, and rotating a key means publishing a new selector before retiring the old one.
Where do DMARC reports go and can I read them?
To whatever address you put in the rua field. They arrive as compressed XML attachments — machine-readable rather than pleasant, so most people use a service that turns them into a summary. The reports are the only view you have of who is sending as your domain.
Will fixing these three get my mail out of spam?
It removes the most common technical reason for landing there, and no amount of good content compensates for failing authentication. It is necessary rather than sufficient: reputation, content and recipient behaviour still decide the rest.
Trusted references
Read next
Last reviewed 2026-08-16 · Brand My Inbox current