Why DMARC Gets Stuck at p=none

Publishing a DMARC record is easy. Becoming confident enough to enforce it is the real project.

A 2026 analysis by CipherCue found that 68.4% of the 67,336 company domains in its dataset either had no DMARC record or used the monitoring-only p=none policy. Among domains that did publish DMARC, 42.5% remained at p=none.

Those numbers describe CipherCue’s tracked cohort, not the whole internet. They still expose an important pattern: many DMARC deployments do not fail at the first DNS record. They stall between visibility and enforcement.

p=none is a discovery phase, not a defense

DMARC connects the domain visible in the From address to an aligned SPF or DKIM result. A monitoring record asks participating receivers for aggregate reports without requesting different treatment for failures:

v=DMARC1; p=none; rua=mailto:[email protected]

This is useful. It reveals services sending as the domain, authentication gaps, and possible spoofing. But it expresses no preference to quarantine or reject a message that fails DMARC.

That distinction is easy to lose. A DNS dashboard may show a green “DMARC found” result even though the policy is not enforcing. Compliance questionnaires may ask whether DMARC exists rather than whether it protects the organizational domain and its subdomains. A copied setup example can remain in production for years.

The current DMARC specification, RFC 9989, formally calls p=none Monitoring Mode. It recommends starting there so aggregate data can uncover senders missed during the SPF and DKIM inventory. The mistake is not using p=none; it is using it without an owner, exit criteria, or review date.

Why enforcement becomes an inventory problem

The policy change itself may be one DNS edit. The work before it is a source-by-source investigation.

Most organizations send mail through more systems than anyone remembers:

• a primary workspace or mail server;
• a marketing and newsletter platform;
• support, CRM, recruiting, billing, and monitoring tools;
• an application’s transactional email provider;
• a website form, shop, or legacy server;
• subsidiaries and agencies operating outside the central mail team.

Aggregate reports identify source IPs, message counts, SPF and DKIM results, and alignment. They do not reliably hand you a current business owner and a safe remediation decision. A source that fails could be an attacker, a retired platform, or the checkout system that sends every customer receipt.

The rua= ecosystem adds another layer. Reports arrive as machine-oriented XML, often compressed and emailed from many receivers. They may be split across multiple report destinations or retained in a mailbox nobody reviews. RFC 9990 standardizes aggregate reporting, but receivers are not required to send reports, so the resulting picture is valuable rather than complete.

This explains why “turn on reject” is poor advice without context. Administrators are protecting delivery as well as the domain. When ownership is unclear, leaving the policy untouched can feel safer than discovering a forgotten sender by blocking its mail.

What the practitioner objections get right

The Hacker News discussion around the CipherCue analysis raised several useful objections.

First, the denominator matters. A domain without obvious mail service is not necessarily an active company mail domain. That does not make it safe to ignore: a domain that must never send mail can publish a deny-all SPF policy and an enforcing DMARC policy. If it must not receive mail either, a Null MX record states that explicitly.

Second, DMARC does not answer “is this message trustworthy?” It addresses unauthorized use of the exact From domain. A scammer can register a lookalike domain, abuse a legitimate account, or send perfectly authenticated spam from a domain they control. RFC 9989 explicitly excludes display-name attacks, lookalike domains, and content analysis. DMARC is an identity signal, not a complete anti-spam or anti-phishing system.

Third, legitimate indirect mail can fail. Forwarders and mailing lists may change the path covered by SPF or alter a DKIM-signed message. Modern list software has mitigations, but enforcement still deserves testing wherever forwarding, aliases, or mailing lists matter.

Finally, small teams have a capacity problem. They may understand the risk and still lack time to attribute sources, chase vendors, and parse reports. That is not an argument against DMARC. It is an argument for turning raw reporting into a short, owned queue of decisions.

A practical path from monitoring to enforcement

Treat enforcement as a controlled migration.

1. Name an owner and a deadline

Assign one person or team to the domain. Record when monitoring began and set a review date. p=none without a scheduled decision becomes permanent by default.

2. Centralize the report stream

Send rua= data to one maintained reporting system or intentionally reconcile every destination. Verify that third-party report destinations have the required external-report authorization record. Monitor whether reports continue to arrive; an abandoned mailbox or expired vendor account creates false confidence.

3. Build the sender inventory from evidence

Group report rows into recognizable services, then label each source:

• authorized and aligned;
• authorized but failing alignment;
• unknown and under investigation;
• unauthorized or retired.

Use message headers, vendor configuration, contracts, and service owners to confirm identities. An IP-owner lookup is a clue, not authorization.

4. Fix alignment, not just authentication

DMARC passes when aligned SPF or aligned DKIM passes. A vendor can show “SPF pass” for its own bounce domain while still failing DMARC for your visible From domain. Prefer aligned DKIM for third-party senders where possible; SPF can break when mail is forwarded.

5. Test the awkward paths

Check newsletters, support replies, forwarded mail, mailing lists, automated alerts, invoices, password resets, and low-volume seasonal systems. Cover subdomains explicitly. A strong apex policy with an intentionally weaker subdomain policy is not full-domain enforcement.

6. Move deliberately and observe

Move to p=quarantine, continue reviewing aggregate results, and then move to p=reject when legitimate streams consistently align:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

v=DMARC1; p=reject; rua=mailto:[email protected]

Older rollout guides often recommend gradually increasing pct. RFC 9989 removed that tag because receivers applied intermediate percentages inconsistently. It now defines the binary t=y testing flag for deployments that need the former pct=0 behavior. Existing receiver behavior can lag a new standard, so verify the approach against the systems that handle your mail instead of assuming a partial percentage is a precise safety valve.

7. Keep watching after reject

Enforcement is not the end of the lifecycle. Providers change infrastructure, teams add tools, DKIM selectors rotate, and DNS records drift. Alert on policy downgrades, disappearing reporting, new unaligned sources, falling pass rates, and subdomain-policy changes.

Define “ready” before changing DNS

A domain is ready to leave monitoring mode when:

• every material legitimate sender has a named owner;
• each legitimate stream passes DMARC through aligned SPF or DKIM;
• forwarding and mailing-list paths have been tested;
• unknown high-volume sources are resolved;
• subdomain and non-sending-domain policy is intentional;
• aggregate reporting is centralized and still arriving;
• rollback ownership and post-change monitoring are clear.

The enforcement gap is not evidence that DMARC is pointless. It shows that a security control built on distributed DNS, third-party senders, and receiver feedback needs operational ownership. The useful outcome is not a record that exists. It is a domain whose legitimate mail is known, whose unauthorized use has a published handling policy, and whose posture is watched for the next change.

Run the checker below to see whether a domain is missing DMARC, still in monitoring mode, or enforcing a policy—and keep monitoring so an intentional p=reject does not silently drift backward.