15 June 2026 · The DMARC Engine Team · 11 min read
There is a comfortable moment, a few weeks after you publish your first DMARC record, when the dashboard fills with green ticks and the reports start arriving. SPF passes. DKIM passes. Alignment looks healthy. The domain feels protected. It is a good feeling, and it is mostly an illusion.
If that record carries p=none, you have built a security camera, not a lock. The camera watches everyone who walks up to your front door, including the people impersonating you, and it records exactly what they do. Then it lets them in. p=none tells the world's mailbox providers, "I am watching, but do nothing differently based on what you see." Spoofed mail that fails authentication is delivered exactly as it would have been if you had no DMARC record at all.
This article explains why so many domains get stuck at p=none, the specific traps that keep them there while looking finished, how to read your own record and reports to know whether you are genuinely protected, and the safe route to enforcement that does not break your legitimate email.
What p=none actually instructs receivers to do
A DMARC record is a TXT record published at _dmarc.yourdomain.com. A minimal one looks like this:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.comThe p tag is the policy. It is the single most important field in the entire record, because it is the only part that changes how receiving servers treat mail that fails authentication. There are three valid values:
p=none: take no action. Deliver failing mail normally. Just send the domain owner reports.p=quarantine: treat failing mail with suspicion. In practice this usually means the spam or junk folder.p=reject: refuse failing mail outright. The receiving server bounces it or silently drops it, and it never reaches the recipient.
Only quarantine and reject are enforcement policies. They are the two values that actually stop an impersonator. p=none is, by design, a monitoring-only state. It exists so you can collect data about who sends mail using your domain before you flip the switch that starts blocking things. That is its entire purpose: a temporary observation deck, not a destination.
The trouble is that p=none produces all the visible signals of a working setup. Reports flow in. Your authentication results look correct. Nothing breaks, because by definition nothing can break when the receiver is instructed to change nothing. A domain can sit at p=none for years while its owner believes the job is done. Meanwhile, anyone in the world can still send mail that appears to come from that domain, and every mailbox provider will deliver it to the inbox.
Why so many domains never leave p=none
Getting stuck is the norm, not the exception. Surveys of large domain populations consistently find that a large share of domains with any DMARC record at all are still on p=none. The reasons are predictable and human.
Fear of blocking real mail. This is the big one, and it is rational. Moving to quarantine or reject means that if any of your legitimate senders are not properly authenticated, their mail starts landing in spam or bouncing. Marketing platforms, invoicing systems, helpdesk tools, the CRM, the payroll provider, a regional office's own mail server: each of these is a potential casualty if you have not first made sure it authenticates correctly. Faced with the risk of a finance team's invoices vanishing, many administrators publish p=none, breathe out, and never touch it again.
The checklist mentality. A vendor security questionnaire or a cyber-insurance form asks, "Do you have DMARC?" A p=none record lets you answer yes. The box is ticked. The pressure that prompted the work evaporates, and nobody comes back to finish it. The record exists, so the task feels complete, even though the record protects nothing.
No clear owner. DMARC lives at the intersection of DNS, email infrastructure and security. In many organisations none of those teams owns it outright. The initial record gets published during a project or an audit, then the project ends and the record becomes orphaned. There is no one whose job is to watch the reports and push the policy forward.
The reports are unreadable. DMARC aggregate reports arrive as gzipped XML files, several a day, from dozens of providers. Opening them by hand is miserable, and the natural response is to stop opening them. Without a clear picture of who is sending on your behalf, you never feel confident enough to enforce. If you have never made sense of one, our guide on reading your first DMARC report walks through the fields.
None of these are signs of incompetence. They are the ordinary friction of a change that carries real downside risk and offers no visible upside while you remain at p=none. The domain looks the same in the inbox whether the policy is none or reject. The difference only shows up when an attacker tries to abuse it, and you usually do not get to watch that happen.
The traps that make p=none look like protection
Beyond simply leaving the policy at none, there are configurations that look like enforcement but quietly deliver the same non-protection. These are worth knowing by name, because they catch people who genuinely believed they had finished.
The pct=0 trap
The pct tag tells receivers what percentage of failing mail to apply the policy to. It was designed as a gradual rollout control: set pct=25 and a quarter of failing messages get quarantined while the rest are merely reported, so you can ramp up slowly and watch for collateral damage.
The trap is a record like this:
v=DMARC1; p=reject; pct=0; rua=mailto:reports@yourdomain.comAt a glance this says p=reject. It looks like full enforcement. But pct=0 means the policy applies to zero per cent of failing mail. Every failing message falls through to the implicit fallback, which is treated as p=none. So this record, despite saying reject in bold letters, blocks nothing whatsoever. It is p=none wearing a p=reject costume.
Sometimes pct=0 is left over from a cautious rollout that was started and abandoned. Sometimes it is copied from bad advice online. Either way, if you see pct=0 anywhere in your record, you are not enforcing, no matter what the p value says. A correctly enforcing record either omits pct entirely (the default is 100) or sets pct=100.
The quarantine-but-not-reject half-measure
p=quarantine is real enforcement, and it is a legitimate, sensible stopping point on the way to reject. It sends spoofed mail to the spam folder, which is far better than the inbox. But it is not the destination, and treating it as one leaves a meaningful gap.
The problem with quarantine as a permanent state is that spam folders are not sealed vaults. Recipients check them. Some mailbox providers apply their own logic and can still surface a quarantined message in certain views. A convincing invoice-fraud email sitting in the junk folder of a busy accounts clerk is a successful phishing email if that clerk goes looking for a delayed invoice and finds it. Quarantine reduces risk substantially; it does not close the door. Only p=reject makes the receiving server refuse the message so it never lands in any folder at all.
The subdomain blind spot
DMARC has a separate tag, sp, that sets the policy for subdomains. If you publish p=reject on your organisational domain but do not set sp, subdomains inherit the main policy, which is usually what you want. But people sometimes publish p=reject; sp=none, believing they are protected, while leaving every subdomain wide open to spoofing. Attackers know this and will happily forge mail.yourdomain.com or news.yourdomain.com if those are unenforced. If your setup uses subdomains for any sending, our note on the subdomain DMARC record covers how sp interacts with the main policy.
Reporting addresses that go nowhere
A subtler failure: a record with p=none and a rua address that nobody reads, or that bounces. The record technically exists and technically requests reports, but the data goes into a void. This is the worst of both worlds. You have the monitoring posture of p=none with none of the actual monitoring, so you will never gather the evidence you need to move forward. If your reports stopped arriving or never started, the causes are covered in why your DMARC reports are empty.
How to read whether you are actually protected
Here is a short, honest checklist you can run against your own domain right now. You can pull your live record with any DNS lookup, or use our free DMARC checker to fetch and parse it for you.
- Find the
ptag. If it readsp=none, you are in monitoring mode and not protected against spoofing, full stop. Everything else is secondary. - Check for
pct. Ifpct=0, you are not enforcing regardless of thepvalue. Ifpctis anything below 100, you are only partially enforcing. A fully enforcing record has nopcttag orpct=100. - Read the
pvalue as enforcement only when it isquarantineorreject. Those are the only two values that change a receiver's behaviour.p=rejectis full protection.p=quarantineis strong but incomplete protection. - Check
sp. Ifsp=nonewhilepis an enforcement policy, your subdomains are unprotected even though your main domain is not. - Confirm reports are arriving and being read. If you have a
ruaaddress but no one has looked at a report in months, you have monitoring on paper only.
The blunt summary: the only records that protect you from impersonation are p=quarantine and p=reject, with pct at 100 (or absent) and sp not set to none. If your record does not match that description, treat the domain as unprotected, whatever the dashboard's colour scheme suggests. For a full field-by-field walk-through of every tag, see understanding your DMARC record.
The safe path off p=none
The reason p=none exists is that you genuinely should not jump straight to p=reject on a domain you have not measured. The fear of breaking legitimate mail is well founded. The answer is not to stay at none forever; it is to use the monitoring period deliberately, then move through enforcement in controlled steps.
Step one: use the monitoring window to build an inventory
While at p=none, your job is to read the aggregate reports and answer one question: who sends mail using my domain? You are building a complete list of legitimate sources, including the ones you forgot about. Most organisations are surprised. A typical inventory turns up the obvious mail platform plus an invoicing tool, a newsletter service, a recruitment system, a support desk, an internal application server and a third party that someone authorised years ago. Each one needs to authenticate properly before you enforce.
Step two: fix SPF and DKIM for every legitimate source
For each sender on your inventory, make sure it produces aligned authentication. That means the source should pass SPF with a domain that aligns with your From address, or sign with DKIM using a key under your domain, ideally both. This is where most of the real work lives, and it is the work that makes enforcement safe. Our SPF checker and DKIM checker help you verify each source. Watch in particular for SPF records that exceed the ten DNS-lookup limit, which silently breaks SPF, and for services that send from your domain but cannot be aligned, covered in what to do when a service will not align at reject.
Step three: move to quarantine, optionally with pct ramping
Once your inventory is authenticating cleanly and the reports show no important source failing, raise the policy to p=quarantine. If you want extra caution, use pct honestly as a ramp: p=quarantine; pct=25, watch for a week, then 50, then 100. The point of pct is to start it low and increase it, not to set it to zero and forget it. Keep reading the reports throughout. You are looking for any legitimate source that suddenly starts failing.
Step four: move to reject
When you have run at p=quarantine; pct=100 for a stretch with no legitimate mail being caught, raise the policy to p=reject. This is the destination. At p=reject with pct=100 and sp either unset or also at reject, your domain is genuinely protected: spoofed mail that fails authentication is refused at the door rather than filed in a folder. The full version of this journey, with timings and pitfalls, is in how to reach p=reject without breaking email, and the question that stops most people, will enforcing DMARC break my email, gets a direct answer there too.
Keep watching after you enforce
Enforcement is not a one-time event. New sending services get added, vendors rotate DKIM keys, SPF records drift. A change that was safe last quarter can start failing today, and at p=reject a failing legitimate source means lost mail. Continuous monitoring with alerts on changes is what keeps an enforced domain healthy, which is exactly what our monitoring is built for. The major mailbox providers now expect this too, as covered in why Gmail, Yahoo and Microsoft require DMARC.
The practical takeaway
p=none is a starting line painted to look like a finish line. It collects evidence and blocks nothing, and the configurations that mimic enforcement, chiefly pct=0 and a permanent stay at quarantine, leave the same gap while feeling complete. Read your own record with one rule in mind: only p=quarantine or p=reject, at pct=100, with subdomains covered, actually protects you. Everything else is monitoring.
The good news is that the path off p=none is well understood and safe when taken in order: inventory your senders, authenticate every one of them, ramp through quarantine, then reach reject, and keep watching. If you want to see exactly where your domain stands today, run it through the free DMARC checker. If you would rather have the whole journey from p=none to p=reject done for you, without an email outage, that is precisely what our done-for-you service handles.