Why 71% of domains are stuck at DMARC p=none and how to stop being one of them
The statistic nobody talks about
According to a 2024 Valimail report, only 28.5% of domains with a published DMARC record have reached p=reject enforcement. That means more than 71% of domains that went through the effort of publishing a DMARC record are still in monitoring mode watching authentication failures happen without stopping any of them.
This is not a knowledge problem. The three DMARC policies are well documented. Everyone who has published a DMARC record knows that p=none is a starting point, not a destination.
It is an operational problem. Moving from p=none to p=reject requires sustained attention over weeks or months reading aggregate reports, identifying every sending source, confirming authentication, and making the policy change at the right moment. Most teams start the process and never finish it. Not because the last step is hard. Because nobody went back.
This article explains why domains get stuck at p=none, what it actually costs, and how to reach p=reject without making it a permanent manual project.
What p=none actually means
The p=none tag in a DMARC record sends one instruction to every receiving mail server in the world:
"When email claiming to be from this domain fails authentication, deliver it anyway. Send me a report about it, but do not take any action."
That instruction has a name: monitoring mode. And monitoring mode provides exactly zero protection against domain spoofing.
An attacker who wants to send phishing email that appears to come from your domain does not need to compromise your mail server. They need to write your domain in the From field. If your DMARC policy is p=none, the receiving server checks your DMARC record, sees that you have not asked for any enforcement action, and delivers the spoofed email normally.
Your clients receive it. Your partners receive it. Anyone the attacker targets receives it. With your domain in the From field and your signature block in the body.
p=none does not protect against this. It watches it happen and sends you a daily XML report.
The protection starts at p=quarantine, where failing mail goes to spam instead of the inbox. It reaches full effectiveness at p=reject, where failing mail is refused at the SMTP layer and never reaches the recipient at all.
Between p=none and p=reject is where most domains live permanently.
Why the progression matters for agencies specifically
For an agency managing email infrastructure across multiple clients, stuck DMARC policies are a portfolio-wide problem.
Every client domain sitting at p=none is a domain that can be spoofed. Every spoofed email that reaches a client's customer, partner, or supplier carries that client's domain and branding. The reputational damage lands on the client. The accountability lands on the agency.
The question an agency should be able to answer for every client domain is:
- What is the current DMARC policy?
- How long has it been at this policy?
- What does the aggregate report evidence show?
- Is it safe to progress?
- What is the proposed next policy?
For an agency managing 50 client domains manually, answering those five questions requires pulling up each domain's DNS records, logging into whatever tool receives the DMARC reports, reading and interpreting XML aggregate data, and making a judgment call about whether the evidence supports progression.
Then repeating that process for every domain. Regularly.
This is why 71% of domains stay at p=none. Not because the team doesn't want to move them forward. Because the process of moving them forward manually, across a large portfolio, never gets completed.
The real reasons domains get stuck
Nobody owns the decision
Moving a DMARC policy from p=none to p=quarantine is a change that could affect email delivery if any sending source is misconfigured. That makes it a decision someone has to own and approve. In most organizations and agencies, that decision sits in a grey area between IT, marketing, and whoever manages the email infrastructure. When nobody clearly owns it, it doesn't happen.
The aggregate reports are hard to act on
DMARC aggregate reports are XML files sent daily by Gmail, Yahoo, Microsoft, and other mail providers. They contain exactly the data needed to evaluate whether it is safe to progress pass rates per sending source, authentication results, volume by sender. But reading raw XML is not how most teams want to spend their time. Without a system that interprets the reports and presents a clear recommendation, the reports accumulate unread.
The 30-day stability requirement feels arbitrary
Most guidance recommends waiting 30 days at p=none before moving to p=quarantine enough time to see monthly senders in the aggregate data. But "30 days" is not actionable. When does the 30 days start? Has anything changed that resets the clock? Is the evidence actually sufficient or just superficially complete? Without a system tracking stability automatically, the 30-day window is a guideline that gets extended indefinitely.
Fear of breaking legitimate email
The risk of progressing too early is real. If a legitimate sending source a marketing platform, a transactional ESP, a third-party tool is not correctly authenticated, tightening the DMARC policy will affect its deliverability. That risk is manageable with the right evidence. But without a clear picture of every sending source and their authentication status, the risk feels unquantifiable. So teams wait. And keep waiting.
The pct= tag creates a false sense of progress
The pct= tag in DMARC controls what percentage of messages the policy applies to. pct=25 means 25% of failing messages are quarantined; 75% still deliver normally. Some teams move to p=quarantine; pct=25 and consider the job partially done. The partial enforcement provides partial protection. The remaining 75% of failing messages including spoofed phishing emails still reach recipients. The pct tag is a rollout tool, not a destination. But it often becomes one.
What it costs to stay at p=none
The cost of staying at p=none is not hypothetical. It is the ongoing exposure of every domain in the portfolio to exact-match domain spoofing.
An attacker does not need to compromise infrastructure to spoof a domain at p=none. They write the domain in the From field, craft a convincing email, and send it. The receiving server checks the DMARC record, sees p=none, and delivers it.
The email arrives looking exactly like it came from the agency or the client. With the correct domain. With a convincing signature block. Asking for a wire transfer, requesting login credentials, or inserting itself into an existing thread.
Beyond the direct security risk, there are compliance implications. PCI DSS v4.0 includes email authentication requirements. Google's bulk sender requirements pushed millions of domains to publish DMARC records in early 2024. Microsoft followed with its own enforcement requirements in 2025. The organizations that moved to p=reject when these mandates were announced are protected. The organizations that published p=none to satisfy the requirement and moved on are not.
Being able to say "we have a DMARC record" when the policy is p=none is an answer that does not hold up to scrutiny and one that will increasingly not satisfy compliance reviewers, cyber insurance underwriters, and enterprise clients who audit their suppliers' email security posture.
How the progression is supposed to work
The path from p=none to p=reject is not a single step. It is a staged progression that requires evidence at each stage.
Stage 1 p=none with reporting
Publish a DMARC record with p=none and a rua= address to receive aggregate reports. Let reports accumulate for 30 or more days to build a complete picture of every sending source including monthly senders, seasonal campaigns, and third-party tools that send infrequently.
Stage 2 Evaluate the aggregate evidence Read the aggregate reports to identify every source sending email from the domain. For each source, confirm that SPF and DKIM are correctly configured and that authentication is passing consistently. Any source with authentication failures needs to be fixed before the policy tightens.
Stage 3 Move to p=quarantine When all known sending sources show consistent authentication passes, move the DMARC policy to p=quarantine. Monitor aggregate reports to confirm no legitimate mail is being quarantined. Wait 30 or more days at p=quarantine before considering the next progression.
Stage 4 Move to p=reject When p=quarantine has been stable for 30 or more days with no legitimate mail affected, move to p=reject. Continue monitoring aggregate reports to catch any new sending sources that appear after the policy change.
Stage 5 Maintain and watch p=reject is not a set-and-forget configuration. New sending sources appear as tools change, campaigns launch, and infrastructure evolves. Aggregate reports need to be monitored continuously so any new source that fails authentication is caught before it becomes a delivery problem.
This is the right process. It is also a process that requires sustained attention over months, repeated across every domain in a portfolio. This is where most teams stop completing the progression.
How Infraova handles DMARC policy progression automatically
Infraova is built to complete this process operationally not as a manual project but as part of the continuous infrastructure operating loop.
DMARC reporting setup: When a domain has a DMARC record but no reporting address, Infraova proposes injecting its reporting address without touching any other part of the record. When a domain has no DMARC record at all, Infraova proposes a minimal safe record with p=none and the reporting address. Aggregate reports begin flowing immediately.
Policy stability tracking: Infraova tracks dmarc_policy_first_seen_at the timestamp when the current policy was first detected. When the policy changes, the timestamp resets. This gives Infraova an accurate stability window for each domain without requiring manual tracking.
Evidence-based progression proposals: After 30 or more days of stability at p=none, Infraova evaluates whether the aggregate report evidence supports progression to p=quarantine. If the evidence supports it, Infraova creates a proposal the current record, the proposed record with p=quarantine, the evidence supporting the change, and the risk level. The proposal waits for human approval.
After 30 or more days of stability at p=quarantine, Infraova evaluates whether progression to p=reject is supported and creates a proposal if so.
If the live DMARC record does not match the tracked policy because someone changed it outside of Infraova no proposal is created. Infraova always reads the live DNS record before proposing anything.
pct= enforcement: When a domain has p=quarantine or p=reject with a pct= value below 100, Infraova proposes setting pct=100 after 30 or more days of policy stability. Partial enforcement is a rollout tool. Once the policy has been stable long enough to confirm it is working correctly, full enforcement should apply.
Subdomain protection: When aggregate report evidence confirms that no legitimate email is coming from subdomains, Infraova proposes adding sp=reject to explicitly protect subdomains from spoofing. If subdomain activity is detected in the reports, no proposal is created the evidence must confirm it is safe.
Human approval at every step: None of these changes execute automatically. Every DMARC policy change from p=none to p=quarantine, from p=quarantine to p=reject, from partial pct to full enforcement, from no sp= to sp=reject requires explicit human approval before Infraova executes it.
The operator reviews the proposal, sees the current record alongside the proposed record, understands the evidence and risk level, and decides whether to approve. What the operator approves is exactly what Infraova executes.
After execution, Infraova reads the live DNS record to confirm the policy change took effect. The outcome is recorded in the operational history.
What this means for a portfolio of client domains
For an agency managing 50 client domains, DMARC policy progression under a manual model looks like this:
Someone periodically checks each domain's DMARC policy. For domains at p=none, someone reads the aggregate reports if they're being collected and if someone has time. If the reports look clean, someone makes the judgment call to progress and changes the record. Someone verifies the change. This happens inconsistently, when there's bandwidth, for domains that are remembered.
The result: some domains progress. Most don't. The portfolio has domains at various stages of DMARC enforcement with no systematic visibility into which domains are ready to progress, which need more evidence, and which have been at p=none for two years without anyone noticing.
Under Infraova, the process is systematic across every domain in the portfolio:
Every domain's DMARC policy is tracked. Reporting is established automatically where it's missing. Stability is tracked from the moment the policy was first detected. When a domain has been stable long enough and the evidence supports progression, Infraova creates a proposal. The team reviews the proposal in the Infraova dashboard and approves or rejects it. Infraova executes the approved change and verifies the result.
No domain gets forgotten. No domain stays at p=none because nobody went back to check the reports. The progression happens systematically, with evidence, through a controlled workflow.
The question worth asking about every client domain
For every client domain in a portfolio, there is a straightforward set of questions:
- Does the domain have a DMARC record?
- Is the DMARC reporting address configured and receiving reports?
- What is the current policy p=none, p=quarantine, or p=reject?
- How long has it been at the current policy?
- What does the aggregate report evidence show about authentication pass rates?
- Is there evidence of subdomain email activity that needs to be evaluated?
- Is it safe to progress to the next policy level?
- Has pct= been set to 100?
For an agency that can answer these questions accurately for every client domain, DMARC enforcement is an operational strength. For an agency that can't, it is an ongoing exposure.
Infraova is built to answer those questions continuously not as a periodic audit but as part of the infrastructure operating loop that runs for every domain, every day.
Where to start
If you manage client infrastructure and you are not sure where your domains stand on DMARC policy progression:
- Check which domains have no DMARC record at all
- Check which domains have DMARC but no reporting address
- Check which domains have been at p=none for more than 30 days
- Check which domains have been at p=quarantine long enough to consider p=reject
- Check which domains have pct= below 100 at an enforcing policy
That audit gives you the current state. What happens next the evidence evaluation, the proposal, the approval, the execution, the verification is what Infraova handles operationally.
The 71% of domains stuck at p=none are not stuck because the next step is impossible. They are stuck because nobody built a system to take the next step consistently, across every domain, based on evidence.
That is the system Infraova is.
Infraova is an email infrastructure operations platform for agencies, MSPs, deliverability consultants, and businesses managing email at scale. Infraova tracks DMARC policy stability, evaluates aggregate report evidence, and proposes progression when the data supports it for every domain in your portfolio, automatically. Start operating your infrastructure →