DMARC p=none vs Quarantine vs Reject: A Rollout Guide

Use p=none while you inventory legitimate senders and study aggregate reports. Choose p=quarantine only when every important mail stream has aligned SPF or DKIM and an owner can investigate failures. Reserve p=reject for domains where rejecting failed mail is appropriate and recoverable. Do not move policies by an arbitrary timetable or percentage.

The current DMARC standard, RFC 9989, removed the old pct tag because partial percentages were applied inconsistently. It adds the t testing flag for some former pct=0 behavior; t=y is not percentage rollout. Receiver and vendor adoption may lag a new standard, so confirm support with the services that publish, parse, and act on your record before using it.

Start with What is DMARC for cold email? if you need the concept first. Use the DMARC Checker to inspect the public SPF and DMARC records, but pair that result with received-message headers and aggregate reports. A public-record check cannot inventory every legitimate sender or predict how each receiver will handle a message.

Compare the three policy choices

Policy	Published assessment of mail that fails DMARC	Use it when	Main limitation
p=none	The domain owner does not request special failure handling	You are discovering sources, fixing alignment, or deciding whether enforcement is appropriate	It does not request quarantine or rejection
p=quarantine	The domain owner considers failures suspicious	Legitimate mail is aligned and the owner wants failures treated more cautiously	Receivers decide their actual handling and can override the request
p=reject	The domain owner considers failures unauthorized	The domain is suitable for strict enforcement and valid mail has been tested	A missed sender or forwarding path can lose legitimate mail

RFC 9989 defines DMARC as a domain-owner assessment that receivers can use in their own handling decisions; it is not a command that every receiver must apply identically. A DMARC pass requires a passing SPF or DKIM result whose authenticated domain aligns with the visible From domain. A passing SPF result for an unrelated domain does not make DMARC pass.

Separate dedicated sending domains from general-purpose domains

A dedicated sending subdomain with tightly controlled mail streams is a different decision from a company domain used by employees, support systems, forwarding, and mailing lists. RFC 9989 says general-purpose email domains should not publish p=reject because indirect flows can break authentication even when the original message was legitimate.

If a domain with general users nevertheless chooses p=reject, RFC 9989 Section 7.4 says it should first publish p=none for at least one month, then p=quarantine for an equally long period, and compare message dispositions. Those are minimum observation periods for this high-risk exception, not automatic promotion dates: unresolved legitimate mail, mailing-list impact, missing aligned DKIM, or an unowned rollback still blocks reject.

Record the domain's role before choosing policy:

• Dedicated sending subdomain: list its permitted platforms and expected message types. Enforcement may be easier to reason about when the boundary is real and maintained.
• General-purpose user domain: map employee mail, groups, aliases, forwarding, support, billing, forms, and third-party systems. Treat reject as an exception requiring explicit risk acceptance, not a universal destination.
• Organizational domain with subdomains: review sp behavior and any subdomain-specific records. Do not assume one safe decision applies to every namespace.

DMARC addresses unauthorized use of the domain in the visible From field. It does not stop lookalike domains, display-name impersonation, harmful content, or every delivery problem.

Build the decision record before changing DNS

One owner should maintain this record for each legitimate stream:

Field	Evidence to record
Visible From domain	The exact domain recipients see
Sending service and business owner	Platform, purpose, and person accountable for fixes
SPF result and aligned domain	Result from a received message, not only the DNS record
DKIM result and aligned signing domain	Result and selector from a received message
Aggregate-report observation	Source IP, disposition, counts, and date range
Indirect-flow risk	Forwarding, mailing list, gateway, or other transformation
Failure response	Who pauses the change, restores the prior record, and investigates

Test real messages from sales engagement, CRM, support, billing, forms, authentication, transactional, and internal systems. Include low-frequency mail; aggregate reports describe observed traffic and cannot prove that a seasonal or rarely used sender is safe.

Use aggregate reports as evidence, with limits

RFC 9990 defines aggregate reports around domain-level authentication observations. They can reveal sending IPs, authentication results, alignment, counts, and reported dispositions. They do not include individual email addresses, individual-user IP addresses, or message content.

Reports still have important limits:

• receivers are not required to send them
• a report covers what that receiver observed, not every message everywhere
• a source can be legitimate, unknown, or abusive; the IP alone does not decide which
• report data can be incomplete or forged, so investigate anomalies before changing policy
• sending reports to an external processor exposes domain-level traffic metadata and needs an approved privacy and retention arrangement

Keep report access limited to the people who operate authentication and investigate abuse. Document the processor, retention period, and deletion path if a third party receives the data.

Change policy through explicit gates

Use evidence gates. Outside the specific general-user p=reject observation periods above, a calendar date alone does not make the next policy safe:

1. Inventory: every known mail stream has a named business and technical owner.
2. Authenticate: a received sample from each stream passes SPF or DKIM with the required alignment.
3. Observe: aggregate reports no longer show unexplained high-value sources, and known indirect flows have been reviewed.
4. Plan rollback: the prior DNS value is recorded, DNS access is available, and one person can reverse the change.
5. Choose the smallest suitable domain boundary: prefer a controlled sending subdomain when its mail stream is genuinely separate.
6. Apply the reviewed policy: quarantine or reject only when its failure handling matches the domain's role and accepted risk.
7. Verify after the change: check DNS propagation, received-message results, service alerts, support reports, bounces, and new aggregate data.

Do not publish pct=25, pct=50, or another partial percentage as a staged-control mechanism under current RFC 9989 guidance. If your organization considers the new t=y testing behavior, verify that its receivers and reporting tools support the current standard and document what the flag does in that environment. A safer operational boundary can be a dedicated test subdomain rather than an assumed percentage sample.

Provider minimums are not an enforcement recommendation

Google, Yahoo, and Microsoft describe DMARC requirements for covered high-volume senders and accept p=none as a baseline. Meeting a provider minimum does not mean spoofing is blocked, a stricter policy is safe, or a message will reach the inbox.

DMARC is only one input. Receivers also use reputation, complaints, content, sending patterns, and other signals. A DMARC pass validates authorized domain use; RFC 9989 explicitly says it does not guarantee that inbox delivery is safe or desirable.

Source ledger, uncertainty, and maintenance

Checked 2026-09-29:

• RFC 9989: current DMARC policy, alignment, domain-owner actions, interoperability limits, removal of pct, the t testing flag, and the general-purpose-domain caution.
• RFC 9990: aggregate-report format, operational limits, security considerations, and privacy boundaries.
• Google email sender guidelines and sender FAQ: current Gmail requirements for covered senders.
• Yahoo sender best practices: current Yahoo bulk-sender requirements.
• Microsoft high-volume sender requirements: current Outlook requirements for covered senders.

Provider enforcement, receiver support for newer RFC behavior, and your sender inventory can change. Folderly Research and Deliverability Operations owns this guide and should review it on 2026-12-28, or sooner after a relevant RFC or provider-policy change.

Check the public record, then verify real mail

Run the domain through the DMARC Checker, assign owners in the decision record, and verify real received-message results. Use the Email Authentication Analyzer for the setup checklist and the AI Cold Email Deliverability Checker for message-level review. These tools support the review; they do not discover every sender, control receivers, or guarantee placement.