Why most DMARC projects stall at p=none, and how to get unstuck
DMARC projects rarely fail loudly. They stall quietly at p=none because nobody parses the reports or owns the next step. Here is why, and how to fix it.
Most DMARC projects do not fail. They stall. The record goes up, reporting gets switched on, and then months pass with the policy still at p=none, protecting nobody. The domain sees the spoofing and does nothing about it. Getting unstuck is less about technical skill and more about ownership, a deadline, and making the reports readable.
The shape of the stall
p=none is the correct first step. It turns on reporting without touching delivery, so you can safely audit who sends as your domain before you enforce. We cover that groundwork in start with p=none.
The trouble is that p=none is also a comfortable place to stop. Nothing is broken. Reports are arriving, so it feels like progress. There is no error, no bounce, no angry customer. And because p=none does nothing about failing mail, a spoofer can still forge your domain freely while the project sits, apparently underway, actually frozen. The stall is quiet, which is exactly why it goes unnoticed for so long.
Why it happens
A handful of reasons, and most projects hit several at once.
The reports are raw XML
Aggregate reports arrive as XML files, one per receiver per day. They are built for machines, not people. Someone opens one, sees a wall of tags, and quietly decides to deal with it later. Later never comes. The data that is supposed to drive the next decision is sitting in an inbox in a format nobody wants to read, so the decision never gets made. We go into why the raw form is so painful in how to read a DMARC report.
Nobody owns the next step
DMARC often gets set up as a task, not a project. An IT person publishes the record, ticks the box, and moves on. There is no named owner responsible for getting to enforcement, so when the reports need interpreting and senders need fixing, it is nobody’s job. Work that belongs to no one does not happen.
Fear of blocking real mail
This one is rational. Moving off p=none means there is now a way to block your own mail if a legitimate sender is not properly authenticated. Without a clear read of the reports, that fear has nothing to push against, so the safe choice is always to wait one more month. The fear is legitimate; the answer is not to stall indefinitely but to get the visibility that makes tightening safe.
There is no finish line
If nobody has said “we will be at p=reject by this date”, there is no pressure to move. p=none becomes the permanent state by default, because default is where things go when no one has set a target.
How to get unstuck
The fixes mirror the causes, and none of them require deep expertise.
Assign an owner
Give one person responsibility for reaching enforcement, not just for publishing the record. That person does not have to do every fix themselves, but they own the outcome: they track which senders still fail, they chase the fixes, and they decide when it is safe to tighten. A project with an owner moves; a project without one drifts.
Set a target date for reject
Put a date on the calendar for reaching p=reject. A realistic target for a small business is a couple of months out, which is enough time to collect reports and fix senders without rushing. The date does not need to be perfect. Its job is to create the mild pressure that turns “someday” into “by then”, and to make the stall visible if you miss it.
Make the reports readable
This is the practical unblocker. The single biggest reason projects freeze is that the reports are unreadable in raw form, so the decision they should inform never gets made. Use tooling that parses the XML, groups results by sending source across all your receivers, and tells you in plain language which senders pass and which fail. Once “is it safe to tighten?” has a clear answer instead of a folder of XML, the fear drains out of the project and it starts moving again. That is the core argument for using a DMARC service: not that you could not read the reports yourself, but that in practice, unread reports are where projects die.
Fix senders one at a time
The work between p=none and p=reject is authenticating your legitimate senders, and it is far less daunting taken one sender at a time. Make a list from the reports: every legitimate source that is failing SPF or DKIM, or passing but not aligned. Then work down it. Fix the payroll system this week, the marketing platform next week. Each fix is small and self-contained. What feels like a mountain is really a short list of individual jobs, and crossing them off is how you know you are ready to enforce.
The point of moving
It is worth remembering why any of this matters. A domain parked on p=none gets all the reporting overhead and none of the protection. The spoofed invoice still reaches your customer. The phishing email still goes out under your name. Enforcement, meaning p=quarantine and then p=reject, is the only part of DMARC that actually stops impersonation. Everything before it is preparation.
So the goal is not to have DMARC “set up”. The goal is to reach p=reject safely, and then stay there. If your project has been sitting at p=none for a while, the fix is rarely technical. It is to name an owner, put a date on the wall, make the reports legible, and clear your failing senders one by one. The full route with each checkpoint is laid out in the path to p=reject. The projects that finish are simply the ones where somebody decided it would.