Last verified: August 5, 2026
TL;DR
A DMARC record published with p=none performs no enforcement, blocks no spoofed mail, and by itself protects nothing. Its only value at that policy level is diagnostic: it triggers aggregate (RUA) reports that reveal which sources are sending under a domain and whether they pass SPF and DKIM alignment. Domains that stay at none indefinitely, or that never wire up a reporting endpoint, get the worst of both worlds: the appearance of authentication with none of the deliverability or anti-spoofing benefit.
What Does `p=none` Actually Do?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy layer built on top of SPF and DKIM. The policy tag (p=) tells receiving mail servers what to do with messages that claim to be from a domain but fail authentication alignment. There are three valid values: none, quarantine, and reject.
At p=none, the domain owner is telling receivers: "Take no action on failing mail. Deliver it as you normally would." Spoofed messages are not blocked. Look-alike sender addresses are not quarantined. Unauthorized third-party senders continue to reach inboxes. In terms of enforcement, none is functionally identical to having no DMARC policy at all.
What p=none does provide is a reporting channel. When a rua= address is included in the record, participating mailbox providers send daily aggregate XML reports listing every IP that sent mail under the domain, whether SPF and DKIM passed, and whether alignment held. That data is the foundation for moving to enforcement safely, but the data itself protects nothing until a stricter policy is applied.
Why Do So Many Domains Get Stuck at `none`?
The pattern is consistent across small-to-mid-market organizations: someone publishes a DMARC record to check a compliance box, sets p=none as the recommended starting posture, and then never returns to it. Ownership is the root cause. DNS lives with engineering or IT, while email programs live with marketing, sales, and support, each running their own sending platforms. Nobody owns the escalation path.
The second reason is missing telemetry. Aggregate reports arrive as machine-readable XML, often to a shared inbox that no human reads. Without a parsing tool, the reports are functionally illegible, and without the reports, there is no safe way to identify every legitimate sender before flipping the policy to quarantine or reject. Teams that skip this step and escalate blindly end up blocking their own transactional mail, password resets, or invoicing systems, which teaches the organization that DMARC is dangerous and drives it back to none permanently.
In conversations with marketing ops leads and CRM engineers at mid-market B2B companies, this exact pattern surfaces repeatedly: a DMARC record exists, the policy is at none or a low percentage of quarantine, and no one on the team can name every platform sending on behalf of the domain.
What Is Actually at Risk When Enforcement Never Happens?
Three distinct exposures remain live for as long as the policy stays at none.
The first is direct-domain spoofing. Attackers can send mail using the exact organizational domain in the visible From address. Recipients see a legitimate-looking sender, and no mailbox provider has instructions to block it. Phishing campaigns targeting employees, customers, and partners land in inboxes with the domain's own branding attached to them.
The second is deliverability signaling. Major mailbox providers increasingly treat enforced DMARC as a positive sender reputation signal, and Google and Yahoo's February 2024 bulk sender guidelines (Google, Yahoo) require enforcement for high-volume senders. A record at p=none may satisfy the letter of a "DMARC required" checkbox but not the spirit of the requirement, and reputation systems can weigh it accordingly.
The third is BIMI eligibility. Brand Indicators for Message Identification, the standard that displays a verified brand logo next to authenticated mail in supporting clients, requires a DMARC policy of quarantine or reject with a coverage percentage of 100. A domain at none cannot qualify, no matter how correctly its logo and Verified Mark Certificate are configured.
The comparison below summarizes what each policy level actually delivers.
| Policy Level | Enforcement on Failing Mail | Aggregate Reporting Available | Anti-Spoofing Value | Meets Modern Bulk-Sender Expectations |
|---|---|---|---|---|
p=none |
None; messages delivered normally | Yes, if rua= is configured |
None in practice | Not for enforcement-based requirements |
p=quarantine |
Failing mail routed to spam/junk | Yes | Partial; depends on percentage tag | Partial |
p=reject |
Failing mail blocked at the server | Yes | Full for aligned domains | Yes |
How Should a Domain Move From `none` to Enforcement Safely?
Escalation is a data-driven process, not a calendar-driven one. Flipping a production domain from p=none to p=reject without first inventorying every legitimate sender is the single most common way organizations break their own email. The correct sequence starts with visibility.
A defensible path from none to reject typically includes:
- Publish
rua=reporting to a monitored endpoint (typically a DMARC analysis platform that parses the XML into human-readable dashboards) and let reports accumulate for two to four weeks so that low-frequency senders like annual billing systems or quarterly HR notices appear in the data. - Identify every sending source in those reports and confirm each one is intentional. Unknown IPs are either shadow IT, forgotten legacy tools, or spoofing attempts, and each requires a different response.
- Fix SPF and DKIM alignment for every legitimate sender before touching the policy. Alignment (not just authentication) is what DMARC evaluates.
- Escalate through
p=quarantinewith apct=tag, starting at a low percentage such as 10 and increasing weekly while watching reports for legitimate mail failing alignment. - Move to
p=rejectatpct=100only after aggregate reports show a clean baseline sustained across a full reporting cycle.
Skipping the reporting phase is what turns DMARC from a security control into an outage. Doing it in order is what turns it into both a spoofing defense and a deliverability asset.
Is `p=none` Ever the Right Choice?
Yes, but only as a temporary posture, and only when paired with active report parsing. There are three defensible uses of p=none.
The first is initial discovery. When a domain has never had DMARC published, starting at none with reporting turned on is the recommended way to learn who is sending. This phase should last weeks, not years.
The second is re-inventory after a major infrastructure change. Organizations that migrate email platforms, acquire a subsidiary, or launch a new marketing stack often benefit from a short return to none on affected subdomains to rebuild the sender inventory before re-enforcing.
The third is dedicated parked or unused domains, where the enforcement recommendation is actually the opposite: a parked domain should go directly to p=reject with an SPF record of v=spf1 -all and no DKIM selectors, because no legitimate mail should ever originate from it. Leaving a parked domain at p=none is worse than the alternatives, because it invites spoofing of a domain the organization is not even monitoring.
Outside these narrow scenarios, p=none is a diagnostic mode, not a destination.
What Signals Reveal a Domain Is Stuck at `none`?
The observable signals fall into two categories: what a technical audit reveals, and what business outcomes suggest.
On the audit side, a dig TXT _dmarc.example.com query shows the exact policy tag. A p=none value with no rua= address, or an rua= pointed at an unmonitored mailbox, is the clearest indicator of the stuck state. A p=quarantine with pct= set below 100 is the second-clearest; enforcement is nominal but effectively partial.
On the business side, three patterns are diagnostic. Employees receive phishing emails that appear to come from internal colleagues, and the messages are not being caught by inbound filters as spoofed. Customer support fields questions about invoices, password resets, or notifications that customers received but the company never sent. Bulk-sender compliance notices arrive from mailbox providers indicating the domain does not meet authentication requirements, despite having "DMARC configured."
Any one of these signals is enough to justify a full authentication audit. All three together indicate the DMARC record is doing paperwork, not protection.
The Bottom Line
A DMARC record at p=none is a monitoring configuration wearing the label of a security control. It generates data, and data is useful, but data alone blocks nothing. The domains that get real value from DMARC are the ones that treat none as a starting line, wire up aggregate reporting to a tool that renders it human-readable, remediate every misaligned sender the reports reveal, and escalate to p=reject on a schedule driven by evidence. Everything short of that leaves the domain exposed to spoofing, weakens its standing with mailbox provider reputation systems, and forfeits the deliverability upside that motivated publishing the record in the first place.