Email authentication
SPF, DKIM and DMARC Explained Simply
These three records decide whether the world trusts email from your domain. Get them right and your mail reaches the inbox while impersonators are shut out. This guide explains each one in plain English and shows how to set them up safely.
SPF, DKIM and DMARC are the three pillars of email authentication. Together they let receiving mail servers answer a simple question: is this message genuinely from the domain it claims to be from? Without them, anyone can send mail that appears to come from you, and mailbox providers have every reason to treat your real mail with suspicion.
They sound technical, but the ideas behind them are straightforward. This guide walks through what each record does, how they reinforce each other, how to set them up in the right order, and the common mistakes that break legitimate mail.
In short
The three records at a glance
Each does a different job. You need all three, working together, for full protection.
-
SPF says who can send
A DNS record listing the servers allowed to send mail for your domain. Receivers check the sending server against this list.
-
DKIM proves it is genuine
A cryptographic signature added to each message so receivers can verify it really came from you and was not altered in transit.
-
DMARC ties it together
A policy that tells receivers what to do when SPF or DKIM fail, requires alignment with your visible From address, and sends you reports.
-
Alignment is the secret
DMARC only passes if the authenticated domain matches your From address. This is what actually stops spoofing — and what trips most setups up.
SPF: who is allowed to send as you
SPF, or Sender Policy Framework, is a published list of the mail servers permitted to send email on behalf of your domain. You add it to your DNS as a TXT record. When a receiving server gets a message claiming to be from your domain, it looks up your SPF record and checks whether the sending server is on the approved list.
A simple SPF record might allow your mail platform and nothing else. If you also send through a CRM, an invoicing tool and a marketing platform, each of those needs to be included so their mail is not rejected.
The 10-lookup limit
SPF has a hard limit of ten DNS lookups. Every "include" for a third-party sender can consume one or more lookups, and it is surprisingly easy to exceed ten — at which point SPF fails entirely and all your mail loses that protection. Keeping the record lean, and flattening or consolidating includes where needed, is a common real-world task.
A single domain should have exactly one SPF record. Two SPF records is an error that causes SPF to fail — a frequent and easily missed mistake.
DKIM: a tamper-proof signature
DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to the headers of every message you send. Your mail server signs each message with a private key, and you publish the matching public key in DNS under a named "selector". Receivers use the public key to verify two things: that the message genuinely came from your domain, and that it was not altered on the way.
Because DKIM survives forwarding far better than SPF does, it is the more robust of the two authentication checks. Most modern platforms enable DKIM with a couple of DNS records; self-hosted servers need the signing configured and the key rotated periodically.
Selectors and key rotation
The selector lets you publish more than one DKIM key, which makes rotating keys painless — you publish a new one, switch signing to it, then retire the old one. Rotating keys periodically is good hygiene, and a key that is too short (under 2048 bits) is worth upgrading.
DMARC: the policy that ties it together
DMARC, or Domain-based Message Authentication, Reporting and Conformance, is the record that turns SPF and DKIM into real protection. It does three things: it requires that the authenticated domain aligns with the From address your recipients actually see, it tells receivers what to do when checks fail, and it sends you reports on everyone sending as your domain.
The three policies
A DMARC policy is set with p=. There are three values: p=none monitors and reports without affecting delivery; p=quarantine sends failing mail to spam; and p=reject blocks it outright. The safe path is to start at none, learn from the reports, then tighten to quarantine and finally reject once you are confident all your legitimate mail passes.
Crucially, DMARC is what stops impersonation. SPF and DKIM on their own can pass for a domain a spoofer controls; DMARC alignment requires the pass to be for your domain, the one in the visible From line. That is the mechanism that makes spoofing your exact domain genuinely hard.
How the three work together
Picture a message arriving at a recipient. The receiver runs SPF to check the sending server is allowed, runs DKIM to verify the signature, then applies your DMARC policy. DMARC passes if either SPF or DKIM passes and aligns with your From domain. If neither aligns, DMARC fails and the receiver does what your policy says — monitor, quarantine or reject.
- SPF authorises the sending server but breaks on forwarding.
- DKIM proves the message is genuine and survives forwarding.
- DMARC demands alignment with your visible domain and tells receivers how to act.
This is why you need all three. Each covers a gap the others leave, and only together do they both protect your deliverability and shut out impersonators.
Setting them up, in the right order
The order matters. Rushing to an enforcing DMARC policy before your legitimate mail reliably passes is the classic way to block your own invoices.
- Inventory every legitimate sender — your mail platform and every third-party tool that sends as your domain.
- Publish a single, correct SPF record that includes all of them and stays under ten lookups.
- Enable DKIM signing on every sending source and publish the public keys.
- Publish a DMARC record at p=none with a reporting address so you start collecting data.
- Read the DMARC reports, find any sender that fails alignment, and fix it.
- Move DMARC to quarantine, then to reject, once everything legitimate passes cleanly.
DMARC aggregate reports arrive as XML and are hard to read by eye. A report parser — or a specialist — turns them into a clear picture of who is sending as your domain and what is failing.
Avoid these
Common authentication mistakes
These errors break legitimate mail or leave the door open to spoofing.
-
Publishing two SPF records
A domain must have exactly one SPF TXT record. Two of them causes SPF to fail entirely, often after someone adds a second tool without merging.
-
Exceeding the SPF 10-lookup limit
Each third-party include consumes lookups. Cross ten and SPF fails for everyone. Keep the record lean and consolidate where needed.
-
Jumping straight to DMARC reject
Enforcing before fixing alignment blocks your own legitimate mail. Always start at p=none, read the reports, then tighten.
-
Forgetting third-party senders
CRM, invoicing and marketing tools that send as your domain must be authenticated and aligned, or DMARC will fail for that mail.
-
Setting DMARC to none and walking away
p=none monitors but protects nothing. Leaving it there indefinitely means your domain can still be spoofed. None is a stepping stone, not a destination.
When to call a specialist
When to get expert help
Authentication is straightforward in principle and fiddly in practice. Here is when expert hands pay off.
-
You want spoofing stopped safely
Moving DMARC to enforcement without blocking real mail takes careful reading of reports and alignment fixes across every sender.
-
Your SPF record is over the lookup limit
Flattening and consolidating SPF includes while keeping every legitimate sender authorised is exacting work that is easy to get wrong.
-
You manage many sending tools
Aligning SPF, DKIM and DMARC across CRM, invoicing, marketing and helpdesk platforms is where most setups fail.
-
You cannot read your DMARC reports
Aggregate XML reports are dense. A specialist turns them into a clear answer about who is sending as you and what is failing.
A note on honesty
Need it handled?
Related Mailoza services
We implement authentication correctly across every sender and move you to enforcement without breaking real mail.
Keep reading
Related guides
A few more plain-English guides that connect to this one.
-
Email Deliverability Guide
Why mail goes to spam and how authentication fits into the bigger deliverability picture.
-
Microsoft 365 Email Security
A practical checklist for hardening a Microsoft 365 tenant, including DNS and anti-spoofing.
-
Email Monitoring Guide
What to watch — including authentication and DMARC reports — so protection stays in place.
Questions
Frequently asked questions
Do I really need all three of SPF, DKIM and DMARC?
Yes. Each covers a gap the others leave: SPF authorises servers but breaks on forwarding, DKIM proves authenticity and survives forwarding, and DMARC demands alignment with your visible domain and tells receivers how to act. Only together do they protect deliverability and stop impersonation.
What is DMARC alignment and why does it matter?
Alignment means the domain that passed SPF or DKIM matches the domain in your visible From address. This is the mechanism that actually stops spoofing — a message can pass SPF or DKIM for a domain the spoofer controls, but it cannot align with yours. It is also what trips up most setups.
Is it safe to set DMARC to reject straight away?
Usually not. Going straight to reject before confirming every legitimate sender aligns can block your own mail. The safe path is p=none first to gather reports, fix anything that fails, then move to quarantine and finally reject.
Why does my SPF keep failing?
The two most common causes are having two SPF records (which is invalid) and exceeding the ten-DNS-lookup limit because too many third-party includes have been added. Both are fixable by consolidating the record.
Do my CRM and marketing tools need authenticating too?
Yes. Any tool that sends email as your domain must be included in SPF, set up to sign with DKIM, and aligned for DMARC. Unaligned third-party senders are one of the most common reasons authentication fails.
How do I read DMARC reports?
Aggregate reports arrive as XML, which is hard to read by eye. A DMARC report parser or a specialist turns them into a clear view of who is sending as your domain and which sources are failing, so you know exactly what to fix before tightening the policy.