← All articles

SPF, DKIM, and DMARC Explained: The Complete Guide to Email Authentication

September 16, 2026 · 9 min read

If your domain sends any email at all — even just a handful of transactional emails from a web form — SPF, DKIM, and DMARC aren't optional extras. Without them, anyone can send an email that appears to come from your domain, and increasingly, without them, your legitimate mail simply won't be delivered at all. Gmail and Yahoo both made this an explicit requirement in 2024.

Here's how the three pieces fit together.

SPF: "which servers are allowed to send as me?"

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorised to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourdomain.com, it checks the connecting server's IP address against your SPF record.

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Reading that record left to right: mail is allowed to originate from IP 203.0.113.10, or from any server listed in Google's own SPF record (useful if you send through Google Workspace), and the -all at the end means reject anything else — a strict, correctly-configured policy.

Common mistakes: ending in +all (which permits literally anyone, defeating the point entirely), or having two separate SPF TXT records instead of merging them into one — DNS only allows a domain to have a single valid SPF record, and having two breaks both.

DKIM: "prove this message wasn't tampered with"

DKIM (DomainKeys Identified Mail) works differently — instead of checking where a message came from, it checks whether the message itself is intact. Your outgoing mail server cryptographically signs each message with a private key, and publishes the matching public key in DNS as a TXT record at a "selector" address, like google._domainkey.yourdomain.com.

The receiving server fetches that public key and verifies the signature. If even a single character of the signed content changed in transit, the signature fails to validate — which is a much stronger guarantee than SPF alone provides.

Because the selector name is chosen by whichever service sends your mail (Google uses google, many providers use default, selector1/selector2, or a custom name), you generally need to know the exact selector to look up a DKIM record — DNSDecode's DKIM lookup tool lets you check any selector directly, or a full domain scan will probe the common ones automatically.

DMARC: "what should you do if the first two fail?"

SPF and DKIM on their own don't actually stop spoofing — they just give receiving servers information. DMARC is the policy layer that says what to do with that information, and it's the piece most domains skip.

v=DMARC1; p=reject; rua=mailto:[email protected]

The p= tag is the important one, and it has three levels:

The rua tag is your aggregate reporting address — without it, you're flying blind on how your policy is actually performing before you tighten it.

A sensible rollout order

Don't jump straight to p=reject — if your SPF or DKIM setup has a gap (a forgotten sending service, for instance), you'll silently lose real mail. The standard, safe progression is:

  1. Set up SPF and DKIM correctly first, and verify both are passing for every legitimate service that sends mail on your behalf (your website's contact form, your CRM, your support desk — all of them, not just your primary mailbox).
  2. Publish DMARC at p=none with a rua reporting address, and actually read the reports for a couple of weeks.
  3. Once reports show no legitimate mail failing, move to p=quarantine.
  4. Once that's been stable for a while, move to p=reject — full protection.

You can check exactly where a domain currently stands — and get a ready-to-publish record for the next step — using DNSDecode's email security scan, which analyses SPF, DKIM and DMARC together and links straight to the SPF and DMARC generators pre-filled with sensible defaults.

Want to see this analysed on a real domain?

Run a free DNS scan →