SPF, DKIM and DMARC without the jargon
Three DNS records decide whether your business email arrives or lands in spam. What each one does, why they are no longer optional, and how to check yours.
The short answer
- What are SPF, DKIM and DMARC?
- Three DNS records that prove your email is genuinely from you. SPF lists which servers may send for your domain. DKIM signs each message so tampering is detectable. DMARC tells receiving servers what to do when a message fails those checks. Without them, Gmail and Outlook increasingly treat your mail as suspect.
- How do I check if my email is set up correctly?
- Send a message to a Gmail address you control, open it, and choose Show original. Three lines appear near the top — SPF, DKIM and DMARC. You want PASS on all three. Anything else explains a lot about where your email has been going.
If your business email sometimes lands in spam, the cause is almost never what you wrote. It is three DNS records, and most small businesses have one configured, one missing and one they have never heard of.
Why this exists
Email was designed without a way to prove who sent a message. Anyone can put your address in the From field — that is how phishing works, and it is a flaw in the original design rather than a bug anyone introduced.
These three records are the retrofit. Together they let a receiving server check whether mail claiming to be from you actually is.
SPF — which servers may send
Sender Policy Framework is a list. It says: mail for this domain comes from these servers, and nowhere else.
One record, listing your mail provider and anything else that legitimately sends on your behalf — an invoicing tool, a booking system, a newsletter platform.
The common failure is forgetting one. Add a newsletter tool and forget to include it, and every campaign is unauthenticated. There is also a hard limit of ten lookups; exceed it and the whole record silently stops working.
DKIM — a signature per message
DomainKeys Identified Mail adds a cryptographic signature to every outgoing message. The receiving server checks it against a public key in your DNS.
If it matches, the message genuinely came from your domain and nothing was altered in transit. If it does not, something is wrong.
The common failure is simply never turning it on. It is off by default with many providers, and nothing visibly breaks when it is missing — mail just gets treated with more suspicion, invisibly.
DMARC — what to do about failures
The first two detect problems. DMARC decides what happens next, and asks receiving servers to report back.
Three policies:
| Policy | Means |
|---|---|
p=none | Do nothing, but send me reports |
p=quarantine | Put failures in spam |
p=reject | Refuse them outright |
Start at none for a few weeks and read the reports. They will show you every service sending as your domain — including ones you had forgotten. Then tighten to quarantine, then reject.
Going straight to reject before you know what sends on your behalf will block your own invoices. This is the step people rush and regret.
Why it is no longer optional
Google and Microsoft both tightened requirements substantially. Bulk senders must authenticate, and the same scrutiny is increasingly applied to everyone.
Practically: mail from an unauthenticated domain is less likely to arrive than it was two years ago, and the trend only runs one way.
Checking yours, in one minute
- Send an email to a Gmail address you control
- Open it, click the three dots, choose Show original
- Look at the top three lines
You want PASS on all three. SPF: PASS, DKIM: PASS, DMARC: PASS.
If DKIM says NONE, it is not enabled. If DMARC says NONE, you have no policy. Both are common and both are fixable in an afternoon.
Doing it yourself
Entirely possible, and worth it:
- Find who sends email for you — mail provider, invoicing, booking, newsletter, CRM
- Build one SPF record covering all of them
- Turn on DKIM with your mail provider and publish the key they give you
- Publish DMARC at
p=none - Read reports for a month
- Tighten to
quarantine, thenreject
The parts people get wrong are having two SPF records (only one is allowed) and rushing to reject. Go slowly at step 5 and the rest is mechanical.
More on foundation