DMARC at p=none Is a Setup State, Not a Deployment

A Story That Plays Out Every Week

A security lead at a mid-sized company gets the memo. Google and Yahoo are tightening their bulk sender requirements. The PCI auditor has DMARC on the questionnaire. The CISO wants a status update by Friday.

So the team does what looks like the right thing. They publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:reports@example.com. The DNS change propagates. The dashboard at the DMARC reporting tool lights up. They check the box on the audit form: “DMARC: implemented.” Then they move on to the next ticket.

Six months later, an executive forwards a phishing email to IT. The message looks exactly like it came from the company’s billing address. The attacker is sending from a server in another country, and recipients have no way to tell the difference. The team’s DMARC record is still there. It is still at p=none. And it is doing exactly what p=none is designed to do, which is almost nothing at all.

This is the gap between having DMARC and being protected by DMARC. It is a gap that the EasyDMARC 2026 DMARC Adoption Report found in more than half of the domains that publish a DMARC record at all. p=none is a setup state. Treating it like a deployment is the most common mistake in email authentication.

What p=none Actually Does

DMARC has three policy values: p=none, p=quarantine, and p=reject. The policy tag tells receiving mail servers what to do when a message claiming to be from your domain fails authentication.

At p=none, the answer is: nothing. The receiver should still evaluate SPF and DKIM. It should still check for DMARC alignment. And then, regardless of the result, it should deliver the message normally. The only operational change p=none introduces is the optional aggregate reporting feed, the RUA stream, which gives you visibility into which IPs are sending mail that claims to be from your domain.

That visibility is genuinely useful. It is the reason p=none exists. Before you tell receivers to start blocking mail, you need to know what they will be blocking. RUA reports surface forgotten marketing tools, an old support platform that nobody documented, the CFO’s accounting service, the conference registration system that was set up three years ago. p=none is the discovery phase.

But discovery is not protection. While you are at p=none:

• A scammer can register a lookalike domain, or simply forge your real domain in the From header, and send phishing messages to your customers, your suppliers, and your employees.
• Receiving servers will note the authentication failure in their reports, but they will still deliver the messages.
• Your DMARC record gives you a paper trail of the spoofing attempts, but it does not stop a single one.

This is not a flaw in the protocol. p=none is designed exactly this way so that organizations can deploy DMARC safely, observe what happens, and then turn on enforcement once they are confident they will not block their own legitimate mail. The flaw is in stopping at p=none and calling it done.

Why So Many Organizations Get Stuck

Stalling at p=none is rarely a strategic choice. It usually happens because moving to enforcement surfaces problems that were always there but were never visible. We see four patterns repeatedly when we audit customer DMARC deployments:

Third-party senders that nobody knew about. A typical mid-sized company sends mail through ten to thirty third-party services. Sales tools, support desks, billing platforms, HR notification systems, calendar invitations, internal newsletters, recruiting tools. Half of them were configured by a department that no longer exists. RUA reports list every IP, but the team has to figure out which IPs map to which services, and whether each service should be authorized.

SPF lookup-limit issues. SPF records are capped at ten DNS lookups, total, including nested includes. Once you exceed that limit, every receiver treats your SPF as a permerror, and DMARC alignment for SPF silently breaks. Organizations that add SaaS tools without auditing the SPF chain often discover the limit only when they try to enforce DMARC. Our AutoSPF service handles this with automatic flattening so the record stays under the limit no matter how many services you add.

Missing DKIM signatures. Some sending services support DKIM but require manual configuration that nobody completed. Others do not support DKIM at all on certain plans. Without a DKIM signature aligned with the From domain, the only path to DMARC alignment is SPF alignment, which limits your options for forwarding, mailing lists, and any service that rewrites envelope addresses.

No clear owner. Email authentication touches DNS, IT operations, marketing, sales, support, and finance. Without a single owner who can make decisions about which senders are authorized, organizations end up in permanent triage. They cannot move from p=none because every move surfaces a complaint from a department that was not consulted.

The good news is that all four of these problems are visible in DMARC RUA data. The bad news is that fixing them requires actually doing the work, not just publishing a record.

The Path From p=none to p=reject

The migration is well-trodden. The Fortune 500 has done it: more than 80 percent of those companies are at quarantine or reject, and 62.7 percent are at the strictest p=reject policy. The path looks roughly like this:

Weeks 1 to 4: Discover. Publish p=none with a rua= tag pointing at a reporting service. Let the data accumulate for at least two billing cycles, since some senders only fire monthly. Tools like DMARC Report parse the aggregate XML and turn it into a list of senders, IPs, volumes, and pass and fail rates. Identify every legitimate source.

Weeks 4 to 8: Authenticate. For each legitimate sender, confirm SPF includes are present and DKIM is configured with an aligned signing domain. Fix lookup-limit issues. Decommission senders nobody can identify. Use a subdomain policy for mail that does not need to look like it comes from the apex domain (a common pattern is bounces.example.com for transactional mail).

Weeks 8 to 12: Tighten gradually. Move to p=quarantine with a low percentage tag, for example pct=25, so that only a quarter of failing mail is sent to spam initially. Watch the reports. If nothing legitimate breaks, raise to pct=50, then pct=100, then move to p=reject. The percentage tag exists exactly for this purpose, and skipping it is a common reason organizations roll back.

Ongoing: Maintain. New SaaS tools get added all the time. Marketing onboards a new platform. Support switches helpdesk providers. Each addition can break authentication if SPF and DKIM are not configured at the same time. RUA monitoring is not a one-time activity. The companies that stay at enforcement are the ones that treat DMARC reports as a standing operational signal, not a project deliverable.

DuoCircle’s Authenticate group wraps these capabilities (DMARC reporting, SPF management, DKIM tooling) so that the operational side of the migration does not fall on a single overworked admin. Experts, not sales reps, since 2014.

What “Done” Actually Looks Like

A finished DMARC deployment is not a TXT record. It is an operational practice. You know you are there when:

• Your policy is p=quarantine or p=reject and your aggregate reports show low single-digit percentage failure rates against legitimate volumes.
• Your SPF record is under the ten-lookup limit and stays there even as you add senders.
• Every legitimate sending service signs with DKIM using a key aligned with the From domain.
• Someone reads the DMARC reports on a regular cadence and acts on anomalies.
• New senders are onboarded with authentication configured before they go live, not after.

If any of those statements are not true, you are still in setup. That is not a failure. It is just a different problem than the one the auditor checked off in the spreadsheet.

p=none is where you start. It is not where you stop. The domains that get spoofed are not the ones with no DMARC record at all. Increasingly, they are the ones with a DMARC record that was published, monitored for a week, and then forgotten.

If you publish a record this week, put a calendar reminder ninety days out asking yourself one question: what is the policy on it now? If the answer is still p=none, the record is not protecting anyone. It is documenting what could have been protected.