DMARC p=none: what it means, the risks, and how to move to quarantine and reject

You scan a client domain and see v=DMARC1; p=none. The record is there, so the box looks checked. But a p=none policy asks receivers to do nothing different with mail that fails DMARC. This guide covers what that means, why it matters, and a rollout to p=quarantine and p=reject you can run across your client base without breaking their invoicing mailbox.

What p=none actually tells receivers

DMARC is a DNS TXT record at _dmarc.<domain>. It tells receivers what the domain owner would like done with mail that uses the domain in the visible From: header but doesn't pass SPF or DKIM in alignment with that domain.

The p tag can be none, quarantine, or reject:

• p=none: the domain owner "offers no expression of preference" (RFC 9989). Google says plainly that under none, "messages are delivered normally." Microsoft calls it the value "for testing and tuning."
• p=quarantine: the owner considers failing mail suspicious. In practice it usually lands in spam or junk.
• p=reject: the owner considers failing mail a clear sign the domain isn't being used legitimately.

RFC 9989 has a name for p=none plus aggregate reporting: Monitoring Mode. A policy other than none is Enforcement. That's the difference to explain to a client. Monitoring tells you who is sending as you. Enforcement asks receivers to act on it.

The risk of staying at p=none

At p=none, receivers that honor DMARC won't junk or reject mail just because it fails DMARC for your client's exact domain. Their other filtering still runs, so spoofed mail may still get caught. But the domain owner hasn't asked for it to be.

The second risk is silent drift. Many p=none records were published years ago to clear a checklist and nobody has read a report since. Meanwhile the client added a CRM, a payroll tool, and a ticketing system that send as their domain. The longer that goes on, the harder it is to reach enforcement.

Note that p=none isn't nothing. Google's sender guidelines require bulk senders (more than 5,000 messages a day to Gmail accounts) to publish DMARC, and their DMARC enforcement policy "can be set to none." So p=none can satisfy that requirement, but it doesn't protect against spoofing.

The tags that matter: rua, ruf, and pct

rua (aggregate reports). rua=mailto:dmarc@example.com asks receivers to send daily XML summaries of the mail they saw using the domain: source IPs, counts, and SPF/DKIM/DMARC results. Under RFC 9989, if rua is absent, receivers MUST NOT generate aggregate reports, so p=none without rua gives you neither enforcement nor visibility. Send reports to a dedicated mailbox or a DMARC reporting service, not a person's inbox (Google and Microsoft both advise this). If the rua address is on a different domain, that domain must publish an authorization record at <client-domain>._report._dmarc.<report-domain> (RFC 9990 §4). Otherwise, compliant receivers won't send the reports.

ruf (failure reports). ruf= asks for per-message failure reports, and the fo tag controls when they're generated. Treat ruf as optional. These reports can contain message content, which is why RFC 9989 calls ruf addresses more attractive targets than rua addresses. Support is also limited: Google says Gmail doesn't support ruf, and Microsoft says Microsoft 365 doesn't send failure reports. Microsoft's advice is to start with rua only.

pct (and why it changed in 2026). The original DMARC spec, RFC 7489, defined pct (0–100, default 100) as the percentage of failing mail the policy applies to, so you could roll out enforcement gradually. In May 2026, RFC 9989 replaced RFC 7489 and removed pct. It's now marked "historic." The RFC says operational experience showed pct "was usually not accurately applied" except at 0 or 100. In its place is the t (testing) tag: t=y asks receivers to apply one level below your stated policy (quarantine is treated like none, and reject like quarantine).

Google's and Microsoft's admin docs (checked October 2026) still show pct ramps such as pct=5 or pct=10. So you'll keep seeing pct in the wild, and older receivers may still use it. The practical rule: don't count on pct=25 meaning exactly a quarter. Plan every policy change as if it could affect all failing mail.

A rollout you can repeat across clients

Here's how the vendor guidance fits together into an MSP workflow:

1. Inventory senders and fix SPF and DKIM first. Google says to set up DKIM and SPF at least 48 hours before DMARC. Every legitimate source needs to pass SPF or DKIM aligned with the From domain. Where you can, use DKIM: RFC 9989 says domains publishing p=reject MUST NOT rely solely on SPF and MUST apply valid DKIM signatures, because forwarding breaks SPF.
2. Publish p=none with rua. For example: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.
3. Read the reports, then fix what they show. Google recommends at least a week of daily review. RFC 9989 is more cautious for domains whose users post to mailing lists: at least a month at p=none, then an equally long period at p=quarantine. For each unaligned source, turn on that vendor's DKIM with the client's domain, fix its envelope sender, add it to SPF, or stop it sending as the client.
4. Move to p=quarantine. Watch the reports and the help desk. If you want a softer first step, t=y signals testing to receivers that implement RFC 9989.
5. Move to p=reject when quarantine is clean. Microsoft's guidance is to get every custom domain and subdomain to p=reject, starting with low-volume subdomains and doing the parent domain last. RFC 9989 warns that p=reject on domains whose users post to internet mailing lists can cause interoperability problems, so make that call per client.
6. Lock down parked domains. For domains that never send mail, Microsoft recommends v=DMARC1; p=reject; along with an SPF record of v=spf1 -all.

Use sp= to set a separate policy for subdomains, or np= (new in RFC 9989) for subdomains that don't exist. If you don't set them, subdomains inherit the parent's policy.

How to talk about it with a client

Don't open with "you failed DMARC." Say: "Right now, if someone sends an email pretending to be your accounts team, the big mail providers have no instruction from you to block it. We can change that in a few weeks without risking your real mail." Then show the report data.

Check a domain now

Run the free DMARC checker →

See whether a domain's DMARC record is monitor-only or enforcing. It parses p=, pct, and rua, then gives you the next DNS record to publish. Lookups are passive, and a timeout shows as Unknown, not as a fail.

Founding Partner: $1,999, one time. Run this check across your whole book. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →