Will Yahoo and Google require DMARC p=quarantine or p=reject in 2025?
Published 25 Apr 2025
Updated 8 Oct 2026
12 min read
Summarize with
Updated on 8 Oct 2026: We rechecked Google and Yahoo's p=none minimum and clarified the requirements for safe DMARC enforcement.
No. Yahoo and Google did not publish a blanket 2025 requirement that bulk senders must use p=quarantine or p=reject. Their current written sender rules require a valid DMARC record and passing DMARC for direct bulk mail, and p=none still meets the published DMARC policy floor in 2026.
For leadership, p=none is the minimum DMARC policy accepted for bulk sender compliance. The practical protection target is p=quarantine or p=reject once every legitimate sender passes DMARC through SPF or DKIM using a domain that matches the visible From domain.
- Direct answer: No public Yahoo or Google 2025 rule required all bulk senders to enforce DMARC.
- Minimum floor: Bulk senders needed a valid DMARC record, with p=none accepted.
- Better target: Move to quarantine or reject after reports prove legitimate mail passes DMARC.
Google and Yahoo's published DMARC minimum
p=none was acceptable under the written Google and Yahoo bulk sender requirements in 2025 and remains accepted in 2026. Both Google's sender guidelines and Yahoo's sender requirements require a valid DMARC policy and a domain match through passing SPF or DKIM for direct bulk mail.
|
|
|
|---|---|---|
p=none | Enforced DMARC | |
p=none | Enforced DMARC | |
Gmail and Yahoo BIMI | p=quarantine or p=reject | Full enforcement |
Non-sending domains | Bulk sender rules do not apply | p=reject |
Policy status by sender context
DMARC compliance and domain protection have different goals. p=none satisfies the baseline DMARC policy requirement, but it makes no request to quarantine or reject mail that fails DMARC. Receiver spam filtering still applies.
For ongoing visibility, Suped's DMARC monitoring groups aggregate report data by sending source so teams can identify DMARC domain-match failures, assign an owner, and decide which policy change is safe next.
What changed in 2024 and 2025
The main change began in February 2024. Google required bulk senders to authenticate mail with both SPF and DKIM, publish DMARC, keep spam rates below its threshold, and support one-click unsubscribe for marketing and subscribed mail. Google counts close to 5,000 or more messages to personal Gmail accounts in 24 hours across the same primary domain, including its subdomains. Bulk status does not expire. These requirements apply to personal Gmail recipients, rather than Google Workspace recipients. Yahoo's FAQ defines bulk mail as "significant volume" without a published numeric threshold.
In November 2025, Gmail began stronger enforcement against non-compliant traffic, including temporary and permanent rejections, according to Google's sender FAQ. This did not change the DMARC policy floor to p=reject.
For context, Microsoft introduced similar authentication requirements for domains sending more than 5,000 messages per day to its consumer mailboxes in May 2025. Its published DMARC minimum was also p=none, so the change did not create an industry-wide mandate for quarantine or reject.
Google Postmaster Tools compliance dashboard showing sender requirement checks.
Provider recommendations for stronger authentication go beyond the published minimum. Enforced DMARC lets a domain owner request firmer handling for authentication failures, but a recommended end state is different from an announced 2025 requirement.
Bulk sender requirements beyond DMARC
Publishing p=reject does not repair other sender-compliance failures. Google's sender guidelines and Yahoo's sender requirements include these additional checks:
- Configure both SPF and DKIM. DMARC itself passes when at least one passing method authenticates a domain matching the visible From address.
- Keep spam complaint rates below 0.3% at both providers. Google's recommended working target is below 0.1%.
- Marketing and subscribed messages need one-click unsubscribe headers and a visible body link. Use RFC 8058's HTTPS POST method for Gmail and honor opt-outs within 48 hours. Ordinary transactional messages are excluded from the one-click requirement.
- Use valid forward and reverse DNS (PTR) for sending IPs, RFC 5322 message formatting, and TLS for Gmail delivery.
What RFC 9989 changed in 2026
RFC 9989 replaced the original DMARC specification in May 2026 and moved DMARC onto the IETF Standards Track. The version value remains v=DMARC1, so publication of the new standard does not require changing that value.
- Existing records: The version value remains v=DMARC1, so the new standard does not require a record-wide migration.
- Percentage sampling: pct is now historic because receivers applied percentage values inconsistently.
- Testing mode: t=y signals testing, with the expectation that compatible receivers handle DMARC failures one policy level below the published policy. Older receivers can ignore it and apply the full published policy.
- Non-existent subdomains: np can set a policy for names that do not exist beneath the organizational domain.
- Reject readiness: Domains publishing p=reject must apply valid DKIM signatures and cannot rely solely on SPF for a DMARC pass.
Older receivers still implement pct, while RFC 9989 removes percentage sampling. Settings such as pct=25 cannot provide a consistent safety boundary across receivers.
Why p=none is only the floor
p=none requests no change to delivery solely because a message fails DMARC. To request aggregate reports from participating receivers, include the rua tag with a working reporting address. That is useful during discovery because many organizations do not know every system that sends as their domain.
If a forged message fails DMARC and the domain has p=none, the domain owner has not asked the receiver to quarantine or reject it. Receiver filtering still applies, but the domain's own DMARC policy has not taken a protective position.
p=none
- Purpose: Collect reports and map legitimate senders before enforcement.
- Risk: The domain policy does not request quarantine or rejection for failed mail.
- Use case: Initial discovery and sender cleanup.
p=quarantine or p=reject
- Purpose: Request quarantine or rejection when mail fails DMARC.
- Risk: Legitimate mail can fail DMARC if neither passing SPF nor passing DKIM authenticates a domain matching the visible From domain.
- Use case: Production domains with validated senders, including domains used for BIMI.
Use p=none only long enough to find and fix senders. Then move to enforcement after the evidence is clean. Leaving a public brand domain at monitor-only indefinitely accepts continued direct spoofing risk. Receivers make the final delivery decision using DMARC and other filtering signals. Enforcement does not prevent lookalike-domain abuse or forged display names.
How to move to quarantine or reject safely
Plan enforcement around verified sender readiness. Prove every legitimate stream passes DMARC, fix the exceptions, and then raise the policy. Before changing DNS, run Suped's DMARC checker against the current record so you know whether the syntax and tags are valid.
If you need a starting record, build one with Suped's DMARC record generator, then publish one DMARC TXT record at _dmarc.example.com for example.com. Edit an existing record instead of adding a second. Replace dmarc@example.com in these examples with your reporting address and confirm reports arrive.
Monitor-only starter recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Keep p=none until critical mail streams pass. Under RFC 9989, p=quarantine; t=y signals testing with the expectation that compatible receivers use the lower policy, none, for DMARC failures. Receivers that do not support t=y can apply quarantine fully. Verify delivery as though quarantine is active; removing t=y ends the testing request.
Quarantine test record for compatible receiversDNS
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
Reject policy recordDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
- Inventory: List every sender using the domain, including invoices, support tools, apps, scanners, and HR systems. Validate infrequent mail across a representative sending cycle.
- Fix: Configure both SPF and DKIM, ensure at least one passing method authenticates a matching domain, and use valid custom-domain DKIM before p=reject.
- Test: Verify direct delivery and important forwarding or mailing list paths before enforcement. When using t=y, assume incompatible receivers apply the full published policy.
- Watch: Track bounces, support tickets, and aggregate report changes after each DNS update. Allow DNS caches to expire and keep the prior policy ready for rollback if legitimate mail fails.
For larger environments, Suped's Hosted DMARC lets teams stage policy changes through Suped's product without repeatedly replacing the full TXT value. This helps when DNS access is controlled by another team or an MSP.
Assess readiness for DMARC enforcement
If a domain is still at p=none, set an internal enforcement schedule based on sender ownership and report evidence. Enforced DMARC reduces direct domain spoofing risk.
Readiness for DMARC enforcement
Use operational evidence, not a universal pass-rate percentage, before moving a sending domain to quarantine or reject.
Ready
All known senders pass
Every legitimate source is known, passes DMARC, and has an owner.
Needs review
Unknown mail remains
Unexplained sources remain or a sender owner has not confirmed its traffic.
Do not enforce yet
Critical mail fails
A critical business stream still fails DMARC.
Suped's DMARC platform groups aggregate reports into sending sources, highlights DMARC domain-match failures, and records remediation steps. That workflow gives teams evidence about individual mail streams before a policy change.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Practical recommendation
If you are a bulk sender to Gmail or Yahoo, plan for enforced DMARC after sender validation. The published minimum remains p=none, while quarantine or reject provides stronger domain protection after sender cleanup.
DMARC rollout mistakes that risk delivery
Poor DMARC rollouts usually come from rushing the policy change or treating SPF as a complete answer. A sender can pass SPF and still fail DMARC if the authenticated domain does not match the visible From domain. In default relaxed DMARC matching, mail.example.com and example.com match because their organizational domain is the same. Strict settings, adkim=s or aspf=s, require an exact domain match for the corresponding method.
Watch these failure points
- Vendor mail: Marketing, billing, support, and survey platforms often need custom DKIM setup.
- Subdomains: Review each subdomain's sending sources, its own DMARC record, and the parent sp policy before enforcement so receipts or alerts are not overlooked.
- Forwarding: SPF often fails after a message is forwarded. DKIM can preserve DMARC if its signing domain matches and signed content stays intact; mailing list edits can break DKIM too. Gmail exempts indirect mail from its direct-mail domain-matching requirement, but critical indirect delivery still needs testing.
- Testing tags: pct is historic under RFC 9989. Use t=y for its defined test mode, not as percentage sampling.
For a deeper policy path, the switch policy safely explanation covers timing and decision criteria for moving beyond monitor-only DMARC.
BIMI requirements and non-sending domains
BIMI is a separate use case that requires a stronger DMARC policy. Gmail's BIMI documentation and Yahoo's BIMI requirements require p=quarantine or p=reject. Use full enforcement for BIMI; p=none does not meet its DMARC requirement. Gmail's documentation still specifies pct=100, which is a provider-specific eligibility rule even though RFC 9989 removes percentage sampling.
A brand can meet the bulk sender minimum and still be ineligible for BIMI or exposed to direct domain spoofing. If brand logos are part of the project, review the BIMI requirements before setting the DMARC target. An enforced policy alone does not guarantee that a logo will display.
DMARC policy rollout: review reports and fix senders before p=quarantine or p=reject.
Use a stronger policy sooner for domains confirmed not to send mail, including parked or defensive domains. Publish p=reject and an SPF record of v=spf1 -all. Add a null MX only if the domain also does not receive mail. A null MX declares that the domain accepts no incoming email; it does not replace SPF or DMARC.
Historical community views on DMARC enforcement
These July 2024 community comments record expectations before 2025. Use the published Google and Yahoo requirements for compliance decisions.
Best practices
Inventory every sender before policy changes so legitimate mail keeps passing DMARC checks.
Move to enforcement after source checks; use custom-domain DKIM before publishing p=reject.
Keep one owner for DNS changes, sender fixes, and enforcement rollback decisions.
Common pitfalls
Treating p=none as finished leaves direct spoofing risk; DMARC cannot stop lookalike domains.
Jumping straight to reject before testing scan tools, HR systems, and billing mail breaks workflows.
Relying on SPF alone fails when the visible From domain does not match the return path.
Expert tips
Use t=y only with known receiver behavior; older receivers can apply the published policy fully.
Compare Gmail and Yahoo results separately because each provider weighs complaints differently.
Track subdomains separately when vendors send receipts, alerts, or product mail under your brand.
Expert view
An Email Geeks participant reported in July 2024 that no 2025 Yahoo or Google quarantine-or-reject mandate had been announced, while stronger policies were being recommended.
2024-07-30 - Email Geeks
Expert view
Expert from Email Geeks says p=none made senders look at their mail streams, and that naturally pushed many domains toward p=reject.
2024-07-30 - Email Geeks
Frequently asked questions
No. Google required bulk senders to publish DMARC and direct mail to pass its domain-match check, but the policy could be p=none. Non-compliant traffic faced stronger enforcement, while p=reject was not the published floor.
No for general bulk sender compliance. Yahoo required passing DMARC with a valid policy and accepted p=none, but enforced DMARC is needed for some brand-logo use cases such as BIMI.
It satisfies the minimum DMARC policy requirement, but it does not guarantee inbox placement. Bulk senders still need both SPF and DKIM, a DMARC domain match, low complaint rates, and the other applicable sender requirements.
Move after reports covering representative sending cycles show that legitimate senders pass DMARC and every remaining failure is understood. Validate infrequent messages and important forwarding or mailing list paths. Test quarantine first when the domain has complex sender history.
p=quarantine requests suspicious handling, often spam-folder delivery, and still risks disrupting legitimate mail. p=reject requests rejection after sender validation. Receivers make the final delivery decision using DMARC and other filtering signals.
Yes. Their published bulk sender rules still accept p=none, with passing DMARC and all other sender requirements satisfied. RFC 9989 changes the DMARC specification, but it does not change those provider-specific minimums.
