p=none Is Like Locking the Door and Leaving the Key in It
Somewhere past the first hundred MSP customer domains I'd gone through building grimDMARC, I stopped being surprised and started being annoyed. Not at the customers. At the pattern. Domain after domain, the record was there, technically valid, and doing nothing.
The record I see more than any other isn't "no DMARC." It's p=none. Parses fine, generates reports on schedule, and stops nothing at all. Out of a couple hundred domains I've been through by now, p=none sitting untouched for a year or more is the single most common state — ahead of broken syntax, ahead of no record whatsoever.
The comparison I keep reaching for on calls: fitting a proper deadbolt, locking it every night, and leaving the key sitting in the lock on the outside. Looks secure from the street. The one job the lock actually has isn't happening.
I'll get into why the setting exists — it's there for a real reason, not a design mistake. But it's the state where domains sit, quietly, for years, more than any other I run into. A lot of how grimDMARC ended up built traces back to figuring out why.
Who this is for:
- IT and security people who set up DMARC at some point, saw reports start flowing, and never went back to it
- MSPs auditing a new customer's domain and finding a record that looks fine at first glance
- Anyone who's been told "we have DMARC" and wants to know what that sentence is actually worth
The one-sentence version
p=none tells mailbox providers "watch what happens and tell me, but don't block or quarantine anything you're unsure of" — so a forged email using your exact domain goes through exactly as if DMARC didn't exist.
The tag itself
DMARC works by publishing a short text record in your domain's DNS. Buried in it is one tag, p=, and it tells every mailbox provider checking your domain what to do with an email claiming to be from you that fails the underlying checks.
There are three values. For a while I thought of them as three levels of the same protection, which is the wrong way to think about it. They're three different instructions:
p=none— "Don't change delivery. Just tell me what happened."p=quarantine— "If it fails, send it to spam instead of the inbox."p=reject— "If it fails, refuse it outright."
Only the last two change what happens to the email. p=none turns on the reporting pipe, full stop. Early testers of our DMARC Analyzer would paste in a domain, see "DMARC: Yes," and assume that meant protected. It means someone published a record. Nothing more.
Why p=none exists in the first place
Early on I treated p=none almost like a flaw in the standard. Why would a security policy ever enforce nothing? Then I onboarded a real MSP customer and got my answer within about a week.
Nobody knows, on day one, everywhere their domain sends mail from. There's the obvious stuff — the mailbox provider, whatever marketing tool is currently in favor. Then there's the long tail, and the long tail is where it gets messy. Digging into a domain that's been running more than a couple of years, I'll usually find at least one of these still quietly sending: an old CRM nobody uses anymore but still fires renewal reminders, a newsletter tool someone signed up for during a rebrand that never got cancelled, an accounting system finance set up three bookkeepers ago. All legitimate senders. All invisible until enforcement goes on and they start failing.
p=none is how you find that stuff without breaking it. Genuinely useful — I'd never tell anyone to skip it. What I'd tell them to skip is treating it as the finish line.
What actually happens
Someone publishes p=none — usually because a cyber-insurance questionnaire or a customer's security team asked "do you have DMARC?" Box checked. Reports start landing in an inbox that, in my experience, gets opened once, maybe twice, then never again.
The project just stops. Nobody decides to stop it. It drifts.
A year later, still p=none. Two years later, same thing. I've seen this on domains belonging to companies you'd assume had this handled. It's what happens to any project without a clear owner — it reaches "good enough to check the box" and nothing pulls it further.
What makes it genuinely dangerous, rather than just a loose end, is that it looks finished. There's a record. There's a policy tag. Something is happening. Every visible signal says handled, and the one thing that matters — whether a forged email gets stopped — was never switched on. I assumed the hard part of DMARC would be DNS syntax. It's not. The hard part is that p=none doesn't feel unfinished.
From the other side
With p=none published, someone can send an email with a From: of billing@yourcompany.com — not a lookalike, your actual domain — to your customers, your vendors, your own staff. It fails DMARC's checks, because it plainly isn't coming from your authorized infrastructure. DMARC notes the failure, bundles it into a report, and delivers the email anyway. That's the literal instruction p=none gives.
The recipient sees nothing off. Same domain in the From: field, same trust built up over years of real correspondence. The only trace is a line in an XML file that, on most domains I look at, nobody has opened that month. This is the actual mechanism behind a lot of invoice fraud. Not clever lookalike domains — the real one, sent through infrastructure with nothing standing in the way.
"But we get reports — doesn't that mean it's working?"
Fair question, and it's the one I get most. The reports are real. They contain genuinely useful data.
A camera that records but isn't wired to an alarm still shows you what happened. It doesn't stop it from happening. That's p=none — good for building confidence before you flip enforcement on, but watching and stopping are different jobs.
Getting past it
This isn't a one-flag-flip situation. I've watched what happens when someone gets impatient and jumps straight to p=reject — finance stops receiving invoices because nobody remembered the old accounting platform needed an SPF entry, and now there's an angry customer and a support ticket instead of a security win.
Roughly what I walk people through:
- Leave
p=nonerunning long enough to see a real picture — a few weeks minimum, long enough to catch a monthly billing run or a quarterly mailing that doesn't send every day. - Read the reports and identify every legitimate sender. This is the part that takes actual effort, and it's the part almost everyone skips.
- Move to
p=quarantineat a low percentage first, so failing mail lands in spam for a slice of traffic while you confirm nothing legitimate gets caught. - Increase enforcement gradually, watching reports the whole time.
- Reach
p=reject— forged mail using the domain gets refused, not filed away and forgotten.
None of this needs deep expertise. What actually stalls it, almost every time, is step 2. Sitting with dense, machine-generated XML and cross-referencing sending IPs against a mental list of "who do we actually use" is tedious in a way that has nothing to do with difficulty. It's exactly the kind of task that gets deprioritized the second the compliance box is checked, and honestly I get why.
This is roughly what that cross-referencing actually looks like once it's laid out — a handful of real senders that need authorizing, and one that plainly doesn't belong:
Why grimDMARC ended up shaped the way it is
I kept seeing the same pattern across MSP customers: DMARC gets set up once, as a project, and then nobody owns the part that comes after. Reports pile up. Nobody reads them. The record sits at p=none indefinitely.
I underestimated how much manual reading this actually required. A decent dashboard summarizing pass/fail counts, I figured, would be enough. It wasn't. An MSP managing even a modest customer base is looking at reports from dozens of sending sources per domain, every single day, and a summary table doesn't tell you which of those is the CRM everyone forgot about versus someone spoofing you from a data center on another continent. Hosted DMARC grew out of trying to close that specific gap — flag the senders that actually look wrong, and track the domain's movement toward enforcement as a real process with an end point, instead of a monitoring phase that quietly never ends.
The other thing that became obvious fast: DMARC enforcement is only as trustworthy as the SPF and DKIM underneath it. I've watched an SPF record creep past the 10-DNS-lookup limit because someone kept adding include: entries for every new marketing tool and never removed the old ones, and that record starts silently failing lookups for everyone — legitimate senders included — at exactly the wrong moment. Hosted SPF exists so a customer doesn't find that out mid-rollout. And Hosted BIMI is what comes after, once a domain is genuinely enforcing — the logo showing up in Gmail and Apple Mail, which mailbox providers only hand out once they trust the door is actually locked, not just fitted with a lock.
Checking a domain
It's public DNS. Checking your own takes a few seconds — the DMARC Analyzer shows the exact published policy, none, quarantine or reject, plus alignment mode and any deprecated tags still lingering in the record. The Domain Scanner gives the broader picture across DMARC, SPF and transport security if you're not sure where to start, and the DMARC Builder & Validator is there if nothing's published yet.
If it comes back p=none, that's not a failure on its own — for a brand-new record it's exactly where you're supposed to be. The question worth asking is whether there's an actual plan to move past it, or whether it's been sitting there since whoever set it up moved on to something else.
Frequently asked questions
Is p=none better than having no DMARC record at all?
Yes, clearly — it gives visibility into who's sending mail as your domain, forged or not, which no record at all doesn't. The mistake isn't publishing p=none. It's stopping there.
How long is it reasonable to stay at p=none?
Long enough to see a full picture — usually a few weeks to a couple of months, enough to catch periodic sends like quarterly mailings. Sitting there for a year or more with no active plan is where the real risk lives.
Will moving to p=quarantine or p=reject break our own legitimate email?
It can, if a legitimate sender wasn't properly authorized in SPF or DKIM before enforcement went on. That's why the reports need reading first, and why enforcement usually ramps up gradually instead of flipping overnight.
We're at p=quarantine, not p=none — are we fully protected?
p=quarantine is real enforcement, a big step up from p=none — failing mail goes to spam instead of the inbox. p=reject goes further and refuses it outright. A well-tuned p=quarantine is a legitimate steady state for a lot of organizations; p=reject is more complete but not mandatory to be meaningfully protected.
Can we skip straight to p=reject, no staging?
Technically the DNS allows it. I wouldn't, without first identifying every legitimate sender — that's how real invoices and newsletters start silently disappearing.
Who actually reads the aggregate reports DMARC generates? On most domains without dedicated tooling: nobody, in my experience. The files are XML, arrive daily from every sending source, and become unreadable at any real volume within a few weeks.
What to do next
Run your own domain through the DMARC Analyzer if you're not sure what's currently published — takes seconds, no account. If it comes back p=none and you'd rather not read XML reports by hand every week, Hosted DMARC manages the rollout to full enforcement as a tracked process. Worth checking the SPF Analyzer too, since a shaky SPF record underneath is what usually derails enforcement — Hosted SPF keeps it correct as senders change. And if you're already enforcing, Hosted BIMI is the part that's actually visible to customers.
About this article
I'm part of the team building grimDMARC, a managed DMARC, SPF and BIMI platform for MSPs and their customers. Questions about your own domain's policy, or think I'm wrong about something above — reach me at hello@grimdmarc.com.
Last updated: August 2026 · Reading time: 12 minutes