A few weeks ago we went looking at checksumtech.com's own SPF and DMARC records — not because anything was broken, just a routine check. Turns out our SPF was set to soft-fail (~all) instead of hard-fail, and DMARC had been sitting in monitor-only mode (p=none) for over a month, quietly collecting reports nobody had read.
Neither one was broken, exactly. Mail was still going out, still landing in inboxes. But "not broken" and "actually protecting your domain from being spoofed" are two different things — and the gap between them is exactly where phishing-as-you emails live.
The problem with checking your own setup
If you've ever tried to actually verify your own email authentication, the issue usually isn't that it's hard — it's that every tool that checks it hands you a wall of raw DNS text and assumes you already know what ~all versus -all means, or why a DMARC policy sitting at p=none for two months is basically decorative.
We'd already done this diagnostic work once, by hand, when we first set up Microsoft 365 and Amazon SES for our own mail. So we built a free tool that does it in plain English instead: DeliveryRadar. Point it at any domain and it tells you, in seconds, whether SPF, DKIM, and DMARC are actually configured — and if not, exactly what's wrong and what to change.
What the scan found on our own domain
We ran DeliveryRadar against checksumtech.com itself. Here's what came back:
SPF — a valid record was present, but it ended in ~all (soft-fail) rather than -all (hard-fail). Soft-fail tells receiving mail servers to flag spoofed mail as "suspicious" instead of rejecting it outright.
DMARC — a valid record existed, but with p=none. Monitor-only mode collects reports about failing mail but enforces nothing — a clearly spoofed email, failing every check, would still land in an inbox.
DKIM — Amazon SES was signed correctly all along (easy to miss if you're hand-checking, since it uses a randomly generated selector rather than a human-readable one). Microsoft 365's side, though, had never actually been turned on — our own Outlook-sent mail had no DKIM signature at all.
We fixed all three in about twenty minutes: tightened SPF to hard-fail, moved DMARC to a cautious p=quarantine enforcement ramp, and published the CNAME records to turn on M365 DKIM signing. We verified the fix the same way we found the problem — by re-running the scan against ourselves.
Why this matters beyond "security hygiene"
A weak or absent DMARC/SPF setup doesn't just open the door to spoofing — it quietly hurts deliverability. Gmail and Outlook increasingly treat unauthenticated or weakly-authenticated domains as lower-trust, which means legitimate marketing emails, invoices, and outreach are more likely to land in spam. If you've ever wondered why open rates dropped for no obvious reason, this is one of the first things worth checking.
"Not broken" and "actually protecting your domain from being spoofed" are two different things — and the gap between them is exactly where phishing-as-you emails live.
Try it on your own domain
The scanner is free and needs no signup — run it against your own domain in a few seconds at checksumtech.com/Tools/EmailCheck. If you want it checked automatically, alerted the moment a record breaks or someone quietly changes a setting, that's the monitoring tier we're building next — early access is open from the scanner page.
Check your own domain
Free, no-signup scan of your SPF, DKIM, and DMARC setup — plain-English results and a specific fix for each issue.
Scan My Domain