DMARC p=quarantine: what it means and how to roll it out safely

p=quarantine is the middle DMARC policy, and for many MSP clients it's the first one that actually protects them. It's the first step out of monitoring mode into what RFC 9989 calls Enforcement. Here's what it asks receivers to do, what it doesn't guarantee, and how to move a client from p=none to quarantine without sending their invoices to spam. It's written to RFC 9989, the May 2026 DMARC standard that replaced RFC 7489.

What p=quarantine means

RFC 9989 §4.7 defines the policy values from the domain owner's side:

• none: "The Domain Owner offers no expression of preference."
• quarantine: "The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern."
• reject: "The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid."

"Such mail" means messages that use the domain in the From: header but fail DMARC, meaning they have neither an aligned SPF pass nor an aligned DKIM pass. Mail that passes DMARC isn't affected by the policy at all.

What receivers actually do with it

DMARC states a preference. It doesn't give orders. RFC 9989 §5.3.6 says failing messages "are handled in accordance with the Mail Receiver's local policies," which "may take into account" the domain's policy. In practice, quarantine usually means the spam or junk folder. Google's DMARC help describes it as: "Mark the messages as spam and send it to the recipient's spam folder." Other receivers may apply extra scrutiny or hold the message for review.

Two more points from the RFC:

• Receivers can still filter mail that passes DMARC (§5.4). A DMARC pass means the domain's use was authorized, not that the content is safe.
• Under §7.4, a receiver that won't reject on a p=reject policy alone, without other evidence, treats it as quarantine instead. So quarantine is also what p=reject often amounts to in practice.

Why quarantine counts

RFC 9989 §3.2.9 defines Enforcement as any state where the policy is not p=none. Messages with a quarantine or reject policy that fail DMARC "will not reach the inbox at Mail Receivers that participate in DMARC and honor the Domain Owner's expressed handling preference."

So for spoofing protection, quarantine is the line that matters. If the client wants to use BIMI to show a brand logo, Google notes that BIMI requires the DMARC policy to be quarantine or reject. Cyber insurance applications sometimes ask about DMARC too. Beazley's ransomware supplement, for example, lists DMARC as one of the incoming email controls you can tick. What counts as a satisfactory answer is set by each form and underwriter, not by this page.

Subdomains and non-existent subdomains

A p=quarantine record on client.com also covers its subdomains, unless:

• sp= sets a different policy for existing subdomains
• np= sets a policy for non-existent subdomains, which are a common spoofing target, such as invoices.client.com when no such name exists

If neither is set, p applies to subdomains (§4.7, §4.10.1). A record like v=DMARC1; p=quarantine; sp=none; ... leaves every subdomain at monitoring only. That's sometimes intentional during a rollout, but often it's a leftover.

Testing quarantine with t=y (not pct)

Older guides, including Google's DMARC rollout article, step into quarantine with pct=, for example p=quarantine; pct=5. RFC 9989 removed pct. It's registered as historic, because "operational experience showed that the 'pct' tag was usually not accurately applied" except at 0 or 100 (Appendix A.6). RFC 9989 also says unknown tags MUST be ignored, so receivers that have moved to the new standard are expected to ignore pct. Receivers still implementing RFC 7489 may honor it, so a pct value can still change how some mail is handled, but inconsistently. That's the reason it was retired. Don't rely on it for a rollout, and if you inherit a record with one, plan to replace it with t=y.

The replacement is the test flag, t=y. RFC 9989 says it signals that the owner "is currently testing its specified DMARC assessment policy" and expects "the policy applied to any failing messages will be one level below the specified policy." With p=quarantine; t=y, the expected handling is none. With p=reject; t=y, it's quarantine. t=y doesn't change reporting. Remove it (or set t=n, the default) when you're ready for full quarantine.

How to explain it to a client

"Right now, anyone can send email that looks like it's from your domain, and the receiving mailbox has to decide for itself whether it's genuine. Quarantine tells them that anything that fails our checks should be treated as spam. Before we turn it on, we make sure everything that legitimately sends as you passes, so your real invoices and newsletters aren't affected. Then we keep watching the reports for anything new."

A rollout you can repeat

1. Monitor. Publish p=none with an rua address, and read the aggregate reports.
2. Fix the senders. Every legitimate service sending as the client's domain needs aligned DKIM, or aligned SPF. Typical gaps are CRM, marketing, ticketing and invoicing tools.
3. Test. Publish p=quarantine; t=y while you watch the reports for remaining failures.
4. Enforce. Drop t=y. Watch for complaints and DMARC failures from sources you missed.
5. Decide about reject. RFC 9989 §7.4 says domains whose users post to mailing lists SHOULD NOT publish p=reject. Those that do should first spend at least a month at p=none and then an equally long time at p=quarantine, comparing the results.

A sample record at step 3:

```

_dmarc.client.com TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@client.com"

```

Check the client's DMARC policy now

Run the free DMARC checker →

It shows whether the domain is monitor-only or enforcing, parses p= and rua, flags duplicate records, and gives you the next DNS record on the none → quarantine → reject path.

Founding Partner: $1,999, one time. Move every client from p=none to enforcement with reports and alerts that show your work. 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 →