We Found DMARC p=none on Our Own Domain — Here's How We Fixed It

We build a domain security scanner. So it's a little embarrassing to admit that when we ran our own check against our own domain, domsechq.com came back at 73% — with a genuine, real issue sitting right there in the DMARC result.

What we found

The scan showed this DMARC record:

v=DMARC1; p=none; rua=mailto:...; ruf=mailto:...; rf=afrf; pct=100

p=none is DMARC's weakest setting. It means: if someone sends email that pretends to be from your domain — spoofing it to run a phishing scam, for example — your mail policy does nothing to stop it. The spoofed mail goes through exactly as if it were genuine. All p=none does is ask receiving mail servers to report back on what they saw, after the fact. It looks like protection. It isn't, really.

It's also a common trap: a lot of email tools set up DMARC at p=none automatically when you configure a sending domain, because it's the safe default that can't break your mail flow. Nobody goes back and tightens it afterward. That's exactly what had happened here.

The fix

DMARC policy has three levels: none (monitor only), quarantine (suspicious mail goes to spam), and reject (suspicious mail is refused outright). Once we confirmed our legitimate mail flow (SPF and DKIM both already passing) wouldn't be affected, we moved straight to:

v=DMARC1; p=reject; pct=100; rua=mailto:...

That one DNS change took our score from 73% to 77%.

The second issue — a false alarm, sort of

DKIM was also flagged as a warning. Our own tool couldn't find a DKIM record under any of the common selector names it checks by default. That's a real limitation worth being upfront about: DKIM selectors are provider-specific, and a generic scanner can only guess so many. Our mail runs through Mimecast, which — like several providers — uses a dated selector (something like mimecast20260831) rather than a predictable common one.

Once we told the tool the actual selector to check, DKIM passed immediately, and the score moved to 82%. Nothing was actually broken — the tool just didn't know where to look until we told it.

The takeaway

Two lessons, and they're the reason this tool exists in the first place:

• A DMARC record existing is not the same as a DMARC record doing anything. p=none satisfies "do you have DMARC?" on a checklist without providing real protection against spoofing.
• If you're on a provider with custom DKIM selectors (Mimecast, and others), a generic checker — including a free one, including ours — may report DKIM as missing when it's actually fine. Always confirm with your actual selector before assuming the worst.

If a company that builds domain security tooling can run at 73% on its own domain without realizing it, it's worth two minutes to check yours.