How to Check Your SPF and DMARC Records (and Fix What's Wrong)

Anyone can put your domain in the "From" line of an email. Nothing about SMTP stops them — the protocol was designed in an era that assumed good faith. What stops them is a pair of DNS records: SPF and DMARC. Most domains have something published, which is why "we're covered" is such a common assumption. But a record that exists and a record that protects you are different things, and the gap between them is usually invisible until someone spoofs your domain or your invoices start landing in spam.

Here's how to check what your domain actually publishes, and what to do about what you find.

The quickest check

Run your domain through our free SPF & DMARC checker. It reads both records straight from DNS and tells you, in plain English, whether SPF is valid, whether DMARC is actually enforced or only watching, and which of the common misconfigurations apply to you. No signup, nothing sent to your mail server.

If you'd rather do it by hand, the records are ordinary DNS TXT lookups: SPF sits on the domain itself, and DMARC sits on the _dmarc subdomain (_dmarc.example.com).

What SPF is, and the three ways it goes wrong

SPF (Sender Policy Framework) is a list of the servers allowed to send mail for your domain. A receiving server looks up the record and checks whether the message came from one of them. A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

That says: mail from Google Workspace and SendGrid is legitimate, and anything else should fail. Three things break it in practice.

1. The ending matters more than the list

The final mechanism tells receivers what to do with servers that aren't on your list, and it's the single most consequential character in the record:

Ending	Meaning	Verdict
-all	Fail anything not listed	Strict — recommended
~all	Soft fail — accept but mark suspicious	Acceptable while testing
?all	Neutral — no opinion	Provides no protection
+all	Authorize everyone	Actively harmful
(missing)	Receivers are left guessing	Weak

A record ending in +all authorizes the entire internet to send as your domain — it's worse than having no SPF at all, because it looks deliberate. It usually arrives via copy-paste from a bad tutorial.

2. More than one SPF record

You may publish exactly one SPF record. Two is not "extra coverage" — it's invalid, and compliant receivers fail SPF outright when they find a second one. This happens constantly: someone adds a vendor's suggested record without noticing one already exists. The fix is to merge the include: terms into a single record.

3. The ten-lookup limit

SPF caps the number of DNS lookups a record may trigger at ten, counting everything pulled in by nested include: chains. Go over and receivers return a permanent error — SPF fails even though your list is perfectly accurate. Because each include: can pull in more includes, a record with five vendors can quietly blow the limit. Our checker counts the lookup-causing terms in your record and warns you when you're close, though it doesn't follow nested includes, so treat the count as a floor rather than the final number.

What DMARC adds — and the trap almost everyone is in

SPF alone has a gap: it validates the invisible envelope sender, not the "From" address a human actually reads. DMARC closes that by requiring the visible domain to align with an authenticated one, and — crucially — by telling receivers what to do when a message fails.

A DMARC record lives at _dmarc.example.com and looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100

The p= tag is the whole ballgame:

• p=none — monitoring only. Receivers report failures back to you but still deliver the mail.
• p=quarantine — failing mail goes to spam.
• p=reject — failing mail is refused outright.

Only the last two are enforcement. And here's the trap: p=none is where the overwhelming majority of domains sit, often for years. It's the correct place to start, but on its own it stops exactly zero spoofed messages. A domain sitting at p=none has a DMARC record, passes a superficial "do you have DMARC?" check, and is still fully spoofable. If you take one thing from this article, make it this one.

Two more tags worth checking:

• rua= — the address that receives aggregate reports. Without it you're flying blind: no visibility into who is sending as your domain, which means no safe way to tighten the policy later. If you're at p=none with no rua=, you have the costs of DMARC and none of the benefits.
• pct= — the percentage of failing mail the policy applies to. pct=50 at p=reject means half of the spoofed mail still gets through. Full protection needs pct=100.

Getting to enforcement without breaking your own mail

The reason so many domains are stuck at p=none is a legitimate fear: turn on p=reject carelessly and you can start bouncing your own invoices, password resets, and newsletters. The way through is boring and reliable:

1. Publish p=none with a rua= address. Nothing changes for your mail flow; you just start collecting reports.
2. Read the reports for a few weeks. They show every source sending as your domain. Expect surprises — a CRM, a ticketing system, an old marketing platform nobody remembered.
3. Authorize the legitimate ones by adding them to SPF (minding the ten-lookup limit) and setting up DKIM signing where the vendor supports it.
4. Move to p=quarantine, ideally with a partial pct= at first. Watch for fallout.
5. Move to p=reject at pct=100. Now you're actually protected.
6. Don't forget sp=, the subdomain policy. Without it, subdomains inherit your policy — but spoofers love unused subdomains, so it's worth being explicit. If you've never inventoried what subdomains you have, our subdomain finder will show you what's out there.

Why DKIM isn't in the checker

You'll notice our tool reports SPF and DMARC but not DKIM, the third record in the set. That's not an oversight — it's a limitation of DNS itself. DKIM public keys are published at a selector you or your provider choose (selector1._domainkey.example.com), and there's no way to enumerate selectors from DNS. A generic checker can only guess common names and report false negatives. DMARC is what ties the SPF and DKIM results together anyway, so a clean DMARC report is the signal that matters — and your mail provider's dashboard is the right place to confirm DKIM signing is on.

These records drift

Email authentication isn't a task you complete. You add a vendor and someone appends a second SPF record. You migrate providers and the old include: lingers, quietly eating one of your ten lookups. Someone "fixes" a deliverability complaint by loosening -all to ~all and never tightens it back. None of this announces itself — mail keeps flowing until the day it doesn't.

It's the same failure mode as an expiring certificate or a domain registration: a piece of DNS that was correct when you set it up, silently stops being correct, and you find out from a customer. That's the problem DomainChest exists to solve — it watches your domains' registration and certificate expiry, notices when DNS and certificates change underneath you, and emails you before the outage instead of after. You can read more on the SSL & certificate monitoring page.

Start by checking your SPF and DMARC — then check the certificate and DNS on the same domain while you're there.