When will Gmail update their DMARC policy to quarantine?
Published 19 Jun 2025
Updated 5 Oct 2026
11 min read
Summarize with
Updated on 5 Oct 2026: We clarified Gmail's quarantine timing, alias authentication, and safe DMARC policy testing.
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. The dated DNS snapshot below shows _dmarc.gmail.com with no requested disposition for root-domain DMARC failures and a quarantine request for subdomains that inherit the record.
The important detail is the difference between p= and sp=. The root gmail.com policy in this snapshot is p=none. The sp=quarantine tag applies to subdomains under gmail.com that inherit this DMARC record. It does not apply to ordinary mail with a visible From address like person@gmail.com.
gmail.com DMARC record observed July 31, 2026dns
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.
- DNS snapshot: the recorded 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.
Gmail sender requirements are a separate policy
A p=none policy requests no DMARC-specific handling for failures. Receiving systems can still filter or reject those messages under their own local policies. Authentication and a monitoring policy do not guarantee inbox delivery.
The Gmail sender requirements began in 2024. Google's sender-guideline FAQ says enforcement of non-compliant traffic began increasing in November 2025. These requirements govern mail sent to personal Gmail accounts, including @gmail.com and @googlemail.com. They do not themselves change Google's published policy for its consumer domain. If you track Google and Yahoo requirements, separate requirements for your sending 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 inheriting this record | quarantine | Request quarantine |
rua= | Reports | Google mailbox | Aggregate data |
Gmail DMARC policy tags that people often mix up.
What Google's quarantine announcement confirms
Google's email sender guidelines say Gmail will begin using a DMARC quarantine enforcement policy and warn senders against impersonating Gmail From headers. The guidance gives no date for changing the root gmail.com policy. The announcement alone does not confirm a DNS change.
- 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.
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.
For troubleshooting, Google's sender-guideline FAQ identifies 4.7.32 as a From-domain authentication mismatch and 4.7.31 as a missing DMARC record or unspecified policy. Diagnose the stated failure before treating an SMTP error as evidence of a gmail.com policy change.
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 when a subdomain inherits this record. For example, 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.
- DNS snapshot: the recorded 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 inherit this DMARC record.
- DNS snapshot: the recorded value is quarantine.
This matters because many people read sp=quarantine and conclude Gmail already moved its main policy. That tag does not establish a change to the root policy. For ordinary consumer addresses, the root p= value is the one to watch.
What changes if Gmail moves to quarantine
If Google changes gmail.com to p=quarantine, mail sent directly by a third-party service using a Gmail address in the visible From header is at risk if it fails DMARC. This includes misconfigured website forms or marketing senders that use 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 asks receivers to treat DMARC failures as suspicious, commonly placing them in the spam folder. The receiving system still applies its own filtering and handling rules. A passing DMARC result also does not guarantee inbox placement.
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, use a domain you control. Passing SPF for the provider's Return-Path domain or DKIM for its signing domain is insufficient when neither domain matches the visible From domain under DMARC's rules.
Safer sender identity patterntext
Risky: From: sender@gmail.com through a third-party sender that fails DMARC Safer: From: sender@example.com with passing DMARC
To pass DMARC, at least one passing authentication method needs DMARC alignment: SPF checks the SMTP MAIL FROM domain, usually shown in the Return-Path, while DKIM uses the signature's d= domain. Gmail requires bulk senders to configure both SPF and DKIM, even though only one needs domain matching for DMARC to pass.
Gmail aliases and third-party sending
An SMTP login authenticates access to an account. Verifying an alias or adding a "Send mail as" address does not by itself make SPF or DKIM match the visible From domain.
- For a @gmail.com From address, use an authenticated Google sending path and inspect a delivered test message for dmarc=pass.
- For a custom-domain alias, use a sender authorized for that domain and configure its SPF and DKIM. Sending through Gmail's interface alone does not authenticate the custom domain.
- You cannot edit Gmail's SPF, DKIM, or DMARC DNS records. Publishing authentication records on your own domain does not authorize a third-party service to send as @gmail.com.
- If replies should arrive in a Gmail inbox, send with an authenticated domain you control in From and put the Gmail address in Reply-To. DMARC evaluates the From domain, not Reply-To.
Custom-domain From with Gmail repliestext
From: sender@example.com Reply-To: sender@gmail.com Configure SPF and DKIM for the actual sending service using your own domain.
Google's third-party account support announcement schedules the removal of third-party "Send as" support for January 2027. Google-hosted Gmail aliases and Google Workspace identities are excluded. This is a separate product change and gives no date for gmail.com DMARC quarantine.
Why sender restrictions do not reveal a date
Google has not published the internal criteria or timetable for changing gmail.com to quarantine. Community reports or isolated SMTP failures do not establish a root-policy change date.
A sending platform's decision to block free-mail From addresses, rewrite them, or require an authenticated custom domain is its own sending rule. Those restrictions do not reveal Google's schedule.
Bulk senders near or above 5,000 messages to personal Gmail accounts within 24 hours need SPF, DKIM, and DMARC, but p=none still meets Google's minimum DMARC policy requirement. Google's sender-guideline FAQ counts the primary domain and its subdomains together and makes bulk-sender status permanent once assigned.
What to do instead of waiting
Use a domain you control for business mail. Make sure it passes SPF or DKIM with domain matching 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.
Inventory senders, enable DKIM for each source, keep SPF within its limit of 10 DNS-querying terms including nested includes, and investigate legitimate failures in DMARC aggregate reports. 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 configuration. Publish your DMARC TXT record with your DNS host, not in the Google Admin console. Confirm SPF and DKIM are working first, then identify which third-party senders still fail and assign 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 dedicated subdomain; confirm receiver support before using t=y.
Enforce
Exceptions resolved
Request enforcement after legitimate failures and forwarding exceptions are resolved.
Google's rollout guidance still includes percentage-based pct examples. RFC 9989, published in May 2026, removed that tag after inconsistent receiver handling. Start with p=none and use reports to fix legitimate sources before requesting enforcement.
For receivers supporting RFC 9989, p=quarantine; t=y requests monitoring handling for failures, while p=reject; t=y requests quarantine. Older receivers ignore t=y and apply the full published policy. Test a dedicated subdomain first and keep a rollback path; use test mode only after confirming receiver support. Follow a safe policy transition before changing the production domain.
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
Suped groups authentication results by sending source so teams can investigate legitimate failures and confirm each sender's domain matching before a policy change. These reports cover mail using your domain; they do not reveal Google's rollout schedule.
After initial DNS setup, our Hosted DMARC lets teams manage policy changes and reporting destinations without editing DNS for each adjustment. Continue reviewing aggregate reports after changing the policy.
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.
Read Gmail's published DMARC policybash
dig +short TXT _dmarc.gmail.com
Read the p= value separately from sp=. DNS caches retain earlier answers until their TTL expires, so confirm an apparent change after the cache refreshes.
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.
Inspect received-message headers as well as aggregate reports. Forwarding often breaks SPF; DKIM can survive when signed content remains unchanged. Google's forwarding guidance explains why preserving DKIM matters. Receiver handling of forwarded mail does not establish a change to the domain's published DMARC policy.
Example DMARC starting recorddns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace example.com with your domain and use a report mailbox you control, or Suped's assigned reporting address. Review reports across your normal sending cycle, including occasional senders, before tightening the policy.
Frequently asked questions
The dated DNS snapshot above has p=none for gmail.com and sp=quarantine for subdomains inheriting the record. Query _dmarc.gmail.com for the latest published policy; Google has not announced a root-policy change date.
No. sp=quarantine applies to subdomains beneath gmail.com when they inherit that DMARC record. Normal addresses like person@gmail.com use the root p= policy.
Google has announced future quarantine enforcement without specifying a root-policy change date or advance notice period. Confirm the policy in DNS at _dmarc.gmail.com. Gmail's sender-guideline enforcement ramp, which began in November 2025, is a separate control.
No. A Google Workspace customer domain uses its own DMARC record at _dmarc.example.com for example.com. Publish the record for your custom domain; Google does not move it to quarantine for you.
Move after reports and test messages show legitimate senders pass SPF or DKIM with domain matching. Test a dedicated subdomain and check forwarding paths first. Use t=y only with confirmed receiver support, because older receivers ignore it and apply the full policy.
