SPF, DKIM, and DMARC Explained: How to Stop Email Spoofing on Your Domain
SPF says who can send, DKIM proves nothing was tampered with, and DMARC ties them together and tells receivers what to do. Here's how the three work — and how to check yours are set up right.
Editorial disclosure: Pyalm publishes and maintains the products and free tools discussed on this site. Regulatory statements are linked to primary sources where applicable. No independent professional review is claimed unless a reviewer is explicitly named.
Anyone can put your domain in the "From" field of an email. Without the right DNS records, receiving mail servers have no way to tell your real mail from a spoof — which is why email authentication exists. Three records do the work: SPF, DKIM, and DMARC. They're easy to confuse, so here's what each actually does.
SPF — who is allowed to send
Sender Policy Framework is a DNS TXT record listing the servers permitted to send mail for your domain:
v=spf1 include:_spf.google.com include:sendgrid.net -allWhen a server receives mail claiming to be from you, it checks whether the sending IP is in that list. The ending matters: -all (hard fail) says "reject anything not listed," while ~all (soft fail) says "accept but mark suspicious." SPF's main limit is that it validates the envelope sender, not the "From" header a human sees — which is where DMARC comes in.
DKIM — proof it wasn't tampered with
DomainKeys Identified Mail adds a cryptographic signature to your outgoing messages. Your mail server signs each message with a private key; the matching public key lives in a DNS TXT record at a selector (e.g. selector1._domainkey.example.com). The receiver verifies the signature, proving two things: the message really came through your infrastructure, and its signed content wasn't altered in transit. Because it's keyed to a selector, you can run multiple selectors for different providers and rotate keys without downtime.
DMARC — the policy that ties it together
SPF and DKIM authenticate. DMARC decides what to do about failures — and closes the "From" header gap. A DMARC record specifies a policy and where to send reports:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=sDMARC requires alignment: the domain that passed SPF or DKIM must match the visible "From" domain. Then p= tells receivers how to treat mail that fails: none (monitor only), quarantine (send to spam), or reject (block outright). The rua address receives aggregate reports so you can see who's sending as you before you tighten the policy.
The order to roll it out
- Publish SPF listing every legitimate sender — don't forget your CRM, invoicing, and support tools.
- Enable DKIM with your provider and publish the selector's public key.
- Start DMARC at
p=nonewith aruaaddress, read the reports, fix any legitimate source that's failing alignment. - Move to
quarantine, thenrejectonce the reports are clean.
DNSSEC — the layer underneath
All three records live in DNS, and DNS answers can themselves be forged. DNSSEC cryptographically signs your DNS zone so resolvers can detect tampering — worth enabling so the records above can be trusted in the first place.
Check what you actually have
The gap between "we set up SPF once" and "our email authentication is correct today" is where spoofing lives — a missing DMARC policy, a soft ~all nobody tightened, an expired DKIM selector. Checking SPF, DKIM across every selector, DMARC and DNSSEC together — rather than one at a time — is what surfaces the gap. Our sister company Defense Net Solutions handles this kind of review.
Related reading
Assess your domain with Defense Net Solutions | Introducing Pyalm Guard | Subdomain takeover explained | HTTP security headers guide