Two painful things happen to domains with weak email setup. First, your legitimate emails — receipts, password resets, newsletters — quietly land in spam. Second, scammers send phishing emails pretending to be you, and your customers (and your reputation) pay for it.
The fix is three DNS records with intimidating names: SPF, DKIM and DMARC. They're email's authentication system, and once you understand the job each one does, setting them up is straightforward. Let's demystify them.
The problem they solve
Email was designed in a more trusting era: by default, anyone can send a message claiming to be from any address. There's nothing in plain email to stop someone sending as [email protected].
SPF, DKIM and DMARC are the layers bolted on to fix that — a way for receiving servers (Gmail, Outlook…) to check that an email really came from who it claims, and to decide what to do if it didn't.
A bouncer analogy
Think of a receiving mail server as a bouncer at a club checking IDs:
| Record | The bouncer's check |
|---|---|
| SPF | "Is this sender on the guest list of servers allowed to send for this domain?" |
| DKIM | "Does this message carry an unbroken, genuine signature from the domain?" |
| DMARC | "If the checks fail, what does the domain want me to do — and who do I report it to?" |
All three live in your DNS as TXT records.
SPF — the guest list
SPF (Sender Policy Framework) is a list of the servers and services authorised to send email for your domain. When mail arrives, the receiver checks whether it came from one of them.
- It's a single TXT record listing your senders (your mail provider, marketing tool, etc.).
- Common mistake: forgetting a sender. If you send through a new tool but don't add it to SPF, that mail fails the check.
DKIM — the tamper-proof signature
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. The receiver uses a public key (published in your DNS) to verify two things: the mail genuinely came from your domain, and it wasn't altered in transit.
Where SPF checks which server sent it, DKIM proves the message itself is authentic and untampered. They complement each other.
DMARC — the policy and the reports
DMARC ties it together. It does two powerful things:
- Sets a policy for mail that fails SPF and DKIM:
none(just monitor),quarantine(send to spam), orreject(refuse entirely). This is what actually stops spoofing. - Sends you reports on who's sending mail as your domain — including impersonators — so you can see what's really going on.
Start at
p=none. Deploy DMARC in monitoring mode first and read the reports for a few weeks. Once you're sure all your legitimate mail passes, tighten toquarantine, thenreject. Jumping straight torejectcan silently block your own email.
How they work together
No single record is enough; the strength is in the combination:
SPF → was it sent from an allowed server?
DKIM → is the message genuinely signed and unaltered?
DMARC → if either fails, what to do — and tell me about it
SPF and DKIM do the checking; DMARC sets the consequences and gives you visibility.
Setting them up (in order)
| Step | Do |
|---|---|
| 1 | Publish an SPF record listing every service that sends your mail |
| 2 | Enable DKIM signing in your mail provider and add its key to DNS |
| 3 | Add a DMARC record at p=none and review the reports |
| 4 | Once clean, move DMARC to quarantine, then reject |
The bottom line
| Record | Job | In one line |
|---|---|---|
| SPF | Authorise senders | "These servers may send for me." |
| DKIM | Sign messages | "This mail is genuinely mine and unaltered." |
| DMARC | Set policy + report | "Here's what to do on failure — and tell me who's faking me." |
Get all three right and two good things happen: your real email reaches the inbox, and impersonators get blocked. Get them wrong and you fight an invisible deliverability problem for months.
Check your domain's setup right now with the free SPF, DKIM and DMARC checkers — or monitor it continuously with email policy monitoring.