Stop Email Spoofing: SPF, DKIM & DMARC Explained

In short: SPF lists which servers may send mail for your domain, DKIM cryptographically signs your messages, and DMARC ties the two together and tells receivers what to do with mail that fails — plus sends you reports. Together they stop spoofing and improve deliverability.

The problem: anyone can forge "From"

The From: address on an email is as easy to fake as the return address on a paper envelope. Without authentication, a scammer can send phishing that appears to come from you@yourcompany.com — damaging your brand and landing your legitimate mail in spam. SPF, DKIM and DMARC are the three DNS records that fix this, and all live as TXT records at your DNS provider.

SPF — who is allowed to send

Sender Policy Framework publishes the list of servers permitted to send mail for your domain. A receiver checks whether the sending server is on that list. A typical record for a domain using Google Workspace:

v=spf1 include:_spf.google.com ~all

Add an include: for every service that sends on your behalf (your mail host, newsletter tool, CRM, etc.). End with ~all (soft-fail) while testing, then -all (hard-fail) once you are confident.

SPF allows at most 10 DNS lookups. Too many include: entries breaks it silently — consolidate senders or use an SPF-flattening service if you hit the limit.

DKIM — a signature on every message

DomainKeys Identified Mail adds a cryptographic signature to the headers of each message you send. Your mail provider holds a private key; the matching public key is published in your DNS as a TXT record at a selector, e.g. selector._domainkey.yourdomain.com. The receiver fetches the public key and verifies the signature, proving the message really came from you and was not altered in transit. Most providers (Google, Microsoft 365, etc.) generate the key and give you the record to paste — you just enable it and publish.

DMARC — the policy that ties it together

DMARC tells receivers what to do when a message fails SPF and DKIM, and asks them to send you reports. It is published at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

The p= policy is the key part:

p=none — monitor only; collect reports, change nothing. Start here.
p=quarantine — failing mail goes to spam/junk.
p=reject — failing mail is refused outright. The end goal.

The rua= address receives daily aggregate reports so you can see who is sending as your domain before you tighten the policy.

Alignment — the detail that catches people out

DMARC passes only when SPF or DKIM not only passes but is aligned — the domain it authenticated matches the domain in the visible From: address. A common surprise is mail sent through a third-party tool that passes SPF for its domain, not yours; DKIM signing with your own domain is the reliable way to stay aligned.

A safe rollout

Publish SPF listing all your senders (end with ~all).
Enable DKIM at each sending service and publish the public keys.
Publish DMARC at p=none with a rua address.
Read the reports for a few weeks; fix any legitimate sender that fails.
Move to p=quarantine, then — once clean — to p=reject.

Common mistakes

SPF with more than 10 DNS lookups (silently fails).
Two SPF records on one domain — there must be exactly one.
DMARC left at p=none forever, so spoofing is still delivered.
Forgetting a sender (newsletter, invoicing tool) when moving to -all/reject.

Check your domain & read raw headers

CyberScore's Website scan reports your SPF, DKIM and DMARC status, and the Email headers tab lets you paste a raw message to see exactly how SPF/DKIM/DMARC evaluated and which server really sent it — handy for diagnosing a suspicious email.

Check your email security →