When will Gmail update their DMARC policy to quarantine?
Published 19 Jun 2025
Updated 31 Jul 2026
12 min read
Summarize with
Updated on 31 Jul 2026: We clarified Google's announced Gmail quarantine direction, its separate sender-rule enforcement, and the RFC 9989 rollout path.
Google says Gmail will begin using a DMARC quarantine enforcement policy, but it has not published a date for changing gmail.com from p=none to p=quarantine. Checked on July 31, 2026, the public DMARC record for _dmarc.gmail.com still sets the organizational-domain policy to monitoring, while the subdomain policy requests quarantine.
The important detail is the difference between p= and sp=. The root gmail.com policy is still p=none. The sp=quarantine tag applies to subdomains under gmail.com that do not publish their own DMARC record, not to ordinary mail with a visible From address like person@gmail.com.
Current gmail.com DMARC recorddns
v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com
- Direct answer: Google has announced the direction, but there is no announced date for the root gmail.com policy change.
- Current state: the root policy is p=none, and the subdomain policy is sp=quarantine.
- Practical move: do not wait for Google before securing your own domain with SPF, DKIM, and DMARC.
The short answer
The timing of Gmail's root DMARC policy change is unknown, while its present state is clear. Google has not published a schedule for moving gmail.com to quarantine, and the public DNS record still expresses no requested DMARC disposition for root-domain failures. Receiving systems can still filter or reject those messages under their own local policies.
The Gmail sender requirements began in 2024, and Google started ramping enforcement of non-compliant bulk traffic in November 2025. Those requirements govern mail sent to personal Gmail accounts. They do not themselves change the policy Google publishes for its own consumer domain. If you track Google and Yahoo requirements, separate sender requirements for your domain from the policy Google publishes for gmail.com.
What to watch
The signal that confirms a root-policy change is the TXT record at _dmarc.gmail.com. If p=none changes to p=quarantine or p=reject, receivers that honor DMARC have a stronger requested disposition for mail claiming to be from gmail.com when neither SPF nor DKIM passes with alignment.
|
|
|
|
|---|---|---|---|
p= | Root domain | none | No requested disposition |
sp= | Subdomains | quarantine | Request quarantine |
rua= | Reports | Google mailbox | Aggregate data |
Gmail DMARC policy tags that people often mix up.
Google's quarantine statement and the live DNS record
Google's email sender guidelines say Gmail will begin using a DMARC quarantine enforcement policy and warn senders not to impersonate Gmail From headers. The guidance does not publish a root-policy change date, and the live gmail.com record still has p=none.
- Published statement: Google has announced future Gmail DMARC quarantine enforcement.
- Live DNS state: the root remains p=none, while subdomains inherit sp=quarantine when they have no lower DMARC record.
- Separate enforcement: since November 2025, Gmail has ramped temporary and permanent failures for non-compliant bulk mail sent to personal Gmail accounts.
- Spoofed Gmail From headers: bulk senders using an @gmail.com From address outside Gmail can receive temporary SMTP failures under the sender rules.
These are different controls. Gmail's inbound sender-rule enforcement affects mail delivered to personal Gmail accounts. The p= value tells DMARC-participating receivers Google's requested treatment for failing mail that uses gmail.com in the visible From address. An SMTP failure reported by one sender does not prove that Google changed the public root policy.
Why p=none and sp=quarantine get mixed up
The confusion comes from reading the full record too quickly. p=none is the policy for the exact domain in the visible From address when that domain is gmail.com. sp=quarantine is the fallback policy for subdomains under that domain when a lower subdomain does not publish its own DMARC record. A failing message from alerts@mail.gmail.com is not the same policy case as a failing message from person@gmail.com.
Root policy
The root policy answers this question: what should a receiver do when mail using the exact organizational domain fails DMARC?
- Tag: the tag is p=.
- Scope: it covers the exact organizational domain in the visible From address.
- Gmail today: the current value is none.
Subdomain policy
The subdomain policy answers a narrower question: what should a receiver do when the visible From domain is below the organizational domain?
- Tag: the tag is sp=.
- Scope: it covers names beneath the root when they do not publish their own DMARC policy.
- Gmail today: the current value is quarantine.
This matters because many people read sp=quarantine and conclude Gmail already moved its main policy. It has not. For the ordinary consumer address pattern, the root p= value is the one to watch.
What changes if Gmail moves to quarantine
If Google changes gmail.com to p=quarantine, the biggest practical impact lands on mail sent through a non-Google system while using a Gmail address in the visible From header. That pattern is common in small tools, older form plugins, trial accounts, help desk misconfigurations, and some marketing platforms that still allow free-mail From addresses.
Flowchart showing how a receiver moves from the From domain through SPF, DKIM, domain matching, DMARC failure, and policy action.
A quarantine policy does not mean every receiver puts every failing message in spam with identical behavior. DMARC publishes the domain owner's requested handling preference. The receiving system still applies local filtering, reputation, user settings, forwarding logic, and abuse controls. In practice, a quarantine request is a much stronger signal than monitoring only.
The risky sending pattern
The pattern to remove is simple: do not send through a third-party platform with a visible From address at gmail.com unless that platform sends in a way that passes DMARC for gmail.com. For most third-party systems, that means you need a domain you control, with SPF, DKIM, and DMARC set up for that sender.
Safer sender identity patterntext
Bad: From: sender@gmail.com through a non-Google platform Good: From: sender@yourdomain.com with SPF, DKIM, and DMARC passing
Why no firm date can be inferred
Google has not published the internal criteria or timetable for changing gmail.com to quarantine. It has only said that future quarantine enforcement is coming. Because the public record remains p=none, any specific date based on community reports or isolated SMTP failures is speculation.
Many platforms now block free-mail From addresses, rewrite them to a shared domain, or require customers to authenticate a domain before sending. Those changes reduce the legitimate mail that a stricter gmail.com policy could disrupt, but they do not reveal Google's schedule.
- Bulk sender rules: senders near or above 5,000 messages a day to personal Gmail accounts need SPF, DKIM, and DMARC, but p=none still meets Google's minimum DMARC policy requirement.
- Consumer domain policy: Google controls the record for gmail.com, and it has not published a quarantine date.
- Inbound enforcement: Gmail's November 2025 enforcement ramp for non-compliant bulk traffic is separate from the published root DMARC policy.
- Your control: you control your own domain's policy, not Google's consumer-domain policy.
Google's rollout guidance still shows percentage-based examples. RFC 9989, published in May 2026, made pct historic because receivers applied fractional sampling inconsistently. Start at p=none, fix legitimate sources, then test on a controlled subdomain or use t=y where receiver support has been confirmed before removing test mode and enforcing.
What to do instead of waiting
Remove your dependency on Gmail's timing. If you send business, product, support, billing, recruiting, or marketing mail, use a domain you control. Then make sure that domain passes SPF or DKIM with alignment to the visible From domain, publish DMARC reporting, and stage enforcement carefully.
Google Workspace Admin console screen showing Gmail DKIM authentication settings for a custom domain.
The first pass is mechanical: inventory senders, turn on DKIM anywhere it exists, keep SPF below lookup limits, and confirm DMARC reports show real sources rather than surprise systems. A DMARC checker is useful for checking the published record, but a DNS check alone does not prove every sender is authenticated. You need real mail and aggregate reports for that.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
For Google Workspace domains, Google DMARC setup covers the core DNS pieces. The hard part is not publishing the first record. The hard part is knowing which third-party senders still fail and which business unit owns each fix.
Policy readiness gates
Use report evidence and resolved exceptions as practical gates, not a universal pass-rate percentage.
Monitor
Inventory open
Start with p=none while discovering sources.
Fix
Failures owned
Assign and resolve legitimate failures.
Test
Traffic verified
Validate a controlled subdomain or t=y.
Enforce
Exceptions resolved
Remove testing after legitimate failures are rare.
Stage enforcement with a rollback path. RFC 9989 no longer defines fractional pct sampling. Test a dedicated subdomain or use p=quarantine; t=y where receiver support is confirmed, then remove t=y after reports show legitimate traffic is passing. Follow a safe policy transition rather than switching the full production domain without test evidence.
How Suped fits this workflow
Suped is our DMARC platform. In this workflow, Suped's DMARC monitoring turns aggregate reports into source-level visibility, flags authentication failures, and gives steps to fix common SPF, DKIM, and DMARC issues.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
That matters because Gmail's future policy is outside your control, but your own domain's readiness is not. Suped can watch DMARC pass rates, unverified sources, blocklist (blacklist) signals, and deliverability indicators in one place. Hosted DMARC helps teams manage policy testing without repeated DNS edits, and Hosted SPF helps when sender changes keep pushing the SPF record toward lookup limits.
Waiting for Gmail
- Timing: there is no public date to plan against.
- Control: you do not control the gmail.com record.
- Risk: legacy free-mail From usage remains fragile.
Fixing your domain
- Timing: you can start immediately with reporting.
- Control: you choose policy testing and enforcement.
- Risk: authenticated sender identity travels better across receivers.
If repeated DNS edits are slowing the rollout, Hosted DMARC lets teams manage policy changes and reporting behavior without treating every adjustment as a manual DNS release.
How to monitor Gmail and your own readiness
For Gmail's own policy, the monitoring task is small: check _dmarc.gmail.com periodically and watch the p= value. For your own readiness, the task is broader: check SPF, DKIM, DMARC, sending sources, and reputation.
A domain health check gives a fast snapshot of the DNS side. After that, use DMARC reports to see real traffic and real failures. DNS can look correct while a forgotten sender still fails DKIM, uses a mismatched return-path domain, or sends with a From domain nobody owns operationally.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The Gmail policy question has one simple answer, but the preparation work is broader. Audit any system that still sends as a Gmail address, replace it with a domain you control, and move that domain toward enforcement using report data rather than a calendar guess.
Example DMARC starting recorddns
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Once reporting is stable and sources are authenticated, move out of monitoring mode with a controlled subdomain test or the RFC 9989 t=y flag where supported. Remove testing only after legitimate traffic continues to pass.
Views from the trenches
Best practices
Check p= and sp= separately before treating a domain as protected by quarantine policy.
Remove free-mail From addresses in business systems before receivers enforce stricter policy.
Use report data and a test subdomain before changing a production domain to quarantine.
Common pitfalls
Reading sp=quarantine as if it applies to the exact root domain causes bad assumptions.
Waiting for Gmail's policy change leaves your own sending domain exposed for too long.
Treating pct as reliable staged enforcement conflicts with RFC 9989 and receiver behavior.
Expert tips
Watch the actual DNS record, but put most effort into your own sender authentication.
Treat Gmail policy changes as external risk, not as the project plan for your domain.
Require every platform to send as an authenticated domain your team controls directly.
Marketer from Email Geeks says the day Gmail tightened bulk sender checks was calmer than many teams expected, because most serious senders had already cleaned up obvious authentication gaps.
2024-02-01 - Email Geeks
Marketer from Email Geeks says the gmail.com record is easy to misread because sp=quarantine looks like enforcement until you remember it only covers subdomains.
2024-02-01 - Email Geeks
The practical answer
Google says future Gmail quarantine enforcement is coming, but it has published no date for changing the root gmail.com DMARC policy. The current record still uses p=none for the root domain and sp=quarantine for subdomains without a lower DMARC record. The answer is a preparation plan, not a calendar date.
Stop sending business mail as a Gmail address through non-Google systems. Use a domain you control, authenticate every sender, publish DMARC reporting, and move to quarantine when the data says the domain is ready. That puts the outcome under your control, regardless of when Google changes its own record.
