DMARC p=none: the silent killer nobody checks

There is a DNS record that takes thirty seconds to check, that a meaningful fraction of B2B SaaS companies get wrong, and that quietly damages every cold email they send. It’s their DMARC policy, and it’s set to p=none.

Here is the check. Open a terminal and run:

dig +short TXT _dmarc.theirdomain.com

If the response contains p=none, you have found the problem. If it contains p=quarantine or p=reject, they’re fine. If there’s no response at all, they haven’t set DMARC up, which is its own problem.

p=none means monitoring-only. The DMARC record exists, so whoever set it up can truthfully say “we have DMARC.” But the policy is set to take no action. Mail that fails authentication is not rejected. It isn’t even quarantined. The record is observing the problem and doing nothing about it. Anyone can send mail that spoofs the domain, and the domain’s own legitimate outbound can suffer, because mailbox providers see a domain that has declared, in its own DNS, that it isn’t enforcing its own authentication.

This is the silent part. A p=none domain doesn’t fail loudly. It degrades quietly. Deliverability erodes in ways that don’t show up in any single metric, because the cause is a DNS record nobody looks at after it’s created.

The reason it’s so common is that p=none is the starter setting. Teams set DMARC to none to collect reports and see what’s failing, with the honest intention of escalating later. Then later never comes. The person who set it up moves on. The reports go unread. The “temporary” monitoring policy becomes permanent, and nobody knows it’s a problem until someone runs the dig command and finds it.

The fix is a path, not a switch. You don’t go straight to p=reject on a domain you’ve never monitored, because legitimate mail you didn’t account for will start bouncing. The progression is: none to watch, then quarantine once you’ve confirmed what’s failing, then reject once you’re confident everything legitimate is passing. Most teams are stuck at step one, forever, because step two requires someone to actually read the reports.

DMARC is also not a standalone control. It’s one layer in a defense-in-depth setup, and it only works alongside SPF and DKIM. SPF says which servers are allowed to send for the domain. DKIM signs the mail cryptographically. DMARC ties them together and tells receivers what to do when they disagree. A domain with DMARC but a broken SPF, or DMARC with no DKIM signing, has a policy it can’t enforce. I’ve seen the full range: SPF ending in ?all, which is no protection at all; SPF chains that exceed the DNS lookup limit and silently break; DMARC policies weaker than they look because the subdomain policy undercuts the main one. One record looks fine until you follow the chain.

This is infrastructure, not a marketing checkbox. It’s the same discipline as any production system: monitor, enforce, verify the enforcement, and don’t trust a config just because someone set it once. The thirty-second dig command works on your own domain and on anyone else’s, because DNS is public. Run it on your domain today. Run it on your competitors’. The number of p=none results will surprise you, and every one of them is a company quietly taxing its own outbound.

I check this on every domain I look at. It’s often the first real finding, and it’s always free to find.

It’s free to check and usually free to find. I check every domain I look at. Worth a 30-minute look at your stack? → Book a call.