Will Yahoo and Google require DMARC p=quarantine or p=reject in 2025?
Published 25 Apr 2025
Updated 2 Aug 2026
11 min read
Summarize with
Updated on 2 Aug 2026: We rechecked the provider rules and updated the rollout guidance for RFC 9989.
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.
The accurate message for leadership is that p=none is the compliance starting point, not the operational finish line. The practical 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.
The direct answer
p=none was acceptable under the written Google and Yahoo bulk sender DMARC requirements in 2025, and both providers still publish that minimum. Gmail tightened enforcement against non-compliant traffic in November 2025, but that enforcement covered the sender requirements as a whole. It did not require every sender to publish p=quarantine or p=reject.
Short answer
Do not cite a 2025 Yahoo or Google enforcement-policy mandate unless the context is a specific program such as BIMI. For ordinary bulk sender compliance, the written requirement was passing DMARC with a valid policy, and p=none permitted.
|
|
|
|---|---|---|
 Google | p=none | Enforced DMARC |
 Yahoo | p=none | Enforced DMARC |
Yahoo BIMI | p=quarantine | p=reject |
Domain protection | Monitor | p=reject |
Policy status by sender context
DMARC compliance and DMARC protection are related, but they are not the same. For compliance with the baseline sender rules, p=none can be enough. For protection against direct domain spoofing, it is not enough because receivers are told to monitor failed mail instead of quarantining or rejecting it.
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, publish DMARC, keep spam rates below its threshold, and support one-click unsubscribe for marketing and subscribed mail. Google classifies a sender as bulk after it sends close to 5,000 or more messages to personal Gmail accounts in a 24-hour period, counted across the same primary domain. Once assigned, that bulk sender status does not expire. Yahoo uses "significant volume" and does not publish the same numeric threshold.
In November 2025, Gmail started a stronger enforcement ramp for traffic that failed its sender requirements, including temporary and permanent rejections. That raised the consequence of non-compliance. It 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.
The confusion came from Google and Yahoo recommending stronger authentication beyond the published minimum. Their requirements use authentication and domain matching to identify legitimate mail. Enforced DMARC lets a domain owner request firmer handling for failures, but a recommended end state is not the same as an announced 2025 rule.
What RFC 9989 changed in 2026
RFC 9989 replaced the original DMARC specification and moved DMARC onto the IETF Standards Track. Existing v=DMARC1 records remain valid, but rollout guidance changed in ways that matter when moving beyond p=none.
- 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 asks receivers using RFC 9989 to apply a policy one level below the published policy while testing. Receivers using an older specification can ignore this tag and apply the published policy fully, so it is not a universal safety switch or percentage sampling.
- Non-existent subdomains: np can set a policy for names that do not exist beneath the organizational domain.
These standard changes do not raise Google or Yahoo's published bulk sender floor above p=none. They do mean that current deployment plans should stop relying on pct=25 or similar percentage steps.
Why p=none is only the floor
p=none is a discovery mode. It tells receivers to evaluate DMARC and send requested aggregate reports, but it does not ask them to change delivery when a message fails. That is useful at the start because many organizations do not know every system that sends as their domain.
Attackers receive the same weak instruction. 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: Failed mail is monitored, but the domain policy does not ask for blocking.
- Use case: Initial discovery and sender cleanup.
p=quarantine or p=reject
- Purpose: Tell receivers to treat failed mail as suspicious or reject it.
- Risk: Legitimate senders fail if SPF or DKIM does not use 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.
How to move without breaking mail
Do not jump straight to reject because someone expects a future mailbox rule. Prove every legitimate stream passes DMARC, fix the exceptions, and then raise the policy. Before changing DNS, run a DMARC checker against the current record so you know whether the syntax and tags are valid.
If you need a clean starting record, build one with the DMARC record generator, then publish it at _dmarc for the domain. Keep the reporting address monitored because aggregate reports provide the evidence needed before enforcement.
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 asks compatible receivers to apply the policy one level lower while continuing reports. Older receivers can ignore the new flag and apply quarantine fully, so assume that outcome during testing. Confirm critical mail after publishing, then remove t=y to apply quarantine fully.
Quarantine testing recordDNS
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
Full reject 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.
- Fix: Make each sender pass SPF or DKIM with a domain that matches the visible From domain.
- Test: Use t=y only after critical senders pass, assume older receivers can apply quarantine fully, then remove the flag after testing.
- Watch: Track bounces, support tickets, and aggregate report changes after each DNS update.
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.
What to do now
If a domain is still at p=none, do not react to an imaginary 2025 deadline. Set an internal enforcement deadline based on sender ownership and report evidence because enforced DMARC reduces direct 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 helps teams decide when a domain can leave monitoring without relying on raw XML or a made-up percentage threshold.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The difficult decision is not whether p=reject is stronger. It is whether legitimate mail is ready. Suped's workflow turns report data into source ownership and specific fixes, giving the policy change an auditable basis.
Practical recommendation
If you send meaningful volume to Gmail or Yahoo, plan for enforced DMARC as the mature state. Do not tell stakeholders it was mandated in 2025. Explain that the published minimum remains p=none, while quarantine or reject provides stronger domain protection after sender cleanup.
Common mistakes that create risk
Poor DMARC rollouts usually come from rushing the policy change or treating SPF as a complete answer. DMARC checks the visible From domain and whether SPF or DKIM authenticates a matching domain. A sender can pass SPF and still fail DMARC if the SPF domain belongs to a vendor and does not match the From domain.
Watch these failure points
- Vendor mail: Marketing, billing, support, and survey platforms often need custom DKIM setup.
- Subdomains: A parent domain can look clean while a subdomain still sends failing mail.
- Forwarding: Forwarded mail often breaks SPF, so DKIM with a matching signing domain is the more durable pass path.
- 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.
When stronger policy is already required
Some use cases already require p=quarantine or p=reject even though neither was the general Yahoo or Google bulk sender rule in 2025. BIMI is the clearest example. Yahoo requires an enforced DMARC policy for BIMI logo display, so p=none is not enough for that use case.
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.
DMARC rollout from p=none through report review and sender fixes to p=quarantine and p=reject.
Use a stronger policy sooner for domains that do not send mail. A parked or defensive domain does not need months of monitoring. Publish a reject policy, add a null MX record where appropriate, and close a direct impersonation route.
Views from the trenches
Best practices
Inventory every sender before policy changes so legitimate mail keeps passing DMARC checks.
Move to enforcement only after reports show SPF or DKIM uses a matching domain for mail.
Keep one owner for DNS changes, sender fixes, and enforcement rollback decisions.
Common pitfalls
Treating p=none as finished leaves brand domains open to spoofed mail and lookalike abuse.
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 for defined testing, then remove it only after critical sending paths are clean.
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 from Email Geeks says no written 2025 Yahoo or Google mandate required p=quarantine or p=reject, but the pressure to move beyond p=none was clear.
2024-07-30 - Email Geeks
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
