What SPF and DMARC actually do
Email has no built-in proof of who sent it. Anyone can put your domain in the From line. SPF and DMARC are the two public DNS records that push back on that: SPF lists which servers are allowed to send mail for your domain, and DMARC tells receiving servers what to do when a message fails those checks. Neither is optional if you care whether invoices, password resets or support replies arriving in your name are really yours.
The catch is that both records can be present and still protect nothing. That is what this checker is for — it reads them the way a receiving mail server would and tells you which of those two situations you are in.
SPF verdicts
| Verdict | When | What it means |
|---|---|---|
| Missing | no record | Anyone can send email using your domain. |
| Broken | more than one record | The standard allows exactly one. With two or more, SPF fails altogether — though each record looks correct on its own. |
| Enforcing | ends with -all | Mail from servers you haven’t listed is rejected. |
| Soft fail | ends with ~all | Mail from unlisted servers is accepted, but marked. |
| Permissive | ?all, +all or no mechanism | The record doesn’t actually restrict anyone. |
DMARC verdicts
| Verdict | When | What it means |
|---|---|---|
| Missing | no record | Receivers aren’t told what to do with forged mail. |
| Monitoring only | p=none | Reports are collected, but forged mail is still delivered. |
| Enforcing | p=quarantine | Forged mail is sent to spam. |
| Enforcing | p=reject | Forged mail is rejected outright. |
| Policy unclear | no readable p= | A record exists, but the policy can’t be read from it. |
The two problems worth checking for
Two SPF records. This is the one nobody catches by reading their DNS. Both records are syntactically fine, both look like something you'd write on purpose, and the result is that SPF does not apply to your domain at all. It happens almost every time a company moves mail providers and adds the new record without deleting the old one.
p=none. The default anyone lands on when they set DMARC up "to start collecting data" — and then never revisit. It is the most widespread DMARC policy in existence. The domain shows up as DMARC-enabled in every audit, and forged mail sent in its name is delivered exactly as before.
What this checker does not do
- DKIM. Not checked, on purpose. The record name contains a selector picked by your mail provider — google, selector1, k1 and hundreds of others — so it cannot be found by guessing. Reporting "DKIM missing" on a domain that has it would be worse than staying quiet.
- DMARC reports. It reads your policy, not the rua aggregate reports mailed to you. Parsing those is a different product.
- The SPF lookup limit. An SPF record that needs more than ten DNS lookups also fails, and that isn’t counted here.
- MTA-STS, TLS-RPT and BIMI. Out of scope — this is about who may send as you, not about transport security or logos.
- Fixing anything. No generated record to paste, no automatic changes. It reads public DNS and reports.
From a one-off check to knowing when it changes
A check tells you where you stand today. The thing that actually bites is a change you didn’t make — a migration that drops your SPF, or a DMARC record quietly rewritten. DNS monitoring in Domain Monitor Hub reads both records during its daily DNS check, shows these same verdicts on the domain page, and any change to SPF or DMARC reaches you as a DNS change alert. Check a domain here; let the app keep watch.