What are the recent changes to Google's bulk sender guidelines?
Matthew Whittaker
Co-founder & CTO, Suped
Published 2 Jun 2025
Updated 15 May 2026
8 min read
Summarize with
The recent changes to Google's bulk sender guidelines are mainly enforcement changes, not a brand new authentication model. As of May 15, 2026, the big update is that Gmail started ramping enforcement in November 2025 for traffic that does not meet its sender requirements. Non-compliant mail can now see temporary failures, permanent rejections, or spam folder placement, depending on the issue.
The core requirements still come from the February 1, 2024 rules: authenticate mail, keep spam complaints low, use TLS, publish valid forward and reverse DNS, avoid Gmail From header spoofing, and make marketing messages easy to unsubscribe from. The current Google sender guidelines page has the detailed requirements, while the Google FAQ has the enforcement updates and practical clarifications.
- Main change: Gmail is moving from published requirements to stricter enforcement for non-compliant traffic.
- Bulk threshold: Sending close to 5,000 messages to personal Gmail accounts in 24 hours makes a domain a bulk sender.
- Permanent status: After a domain is classified as a bulk sender, Google says that status does not expire.
- Practical priority: Fix SPF, DKIM, DMARC, TLS, PTR records, unsubscribe handling, and spam rate before chasing softer causes.
The short answer
The recent Google changes are easiest to read as a tighter compliance program. The guidelines moved away from being best-practice advice and now work more like a pass or fail gate for high-volume senders. I read the newest wording as a signal that Gmail expects senders to prove authentication, prove low complaint rates, and prove that recipients can leave lists without friction.
|
|
|
|---|---|---|
TLS required | Dec 2023 | All senders |
Bulk rules live | Feb 2024 | 5k threshold |
Mitigation limits | Jun 2024 | Spam rate |
Enforcement ramp | Nov 2025 | Rejections |
Dashboard added | 2025 | Compliance view |
Compact view of the main Google sender changes.
Five-part infographic showing Gmail bulk sender compliance requirements.
Do not treat the 5,000 limit as temporary
The 5,000-message mark is based on mail to personal Gmail accounts in a 24-hour period, counted at the primary-domain level. Once Google classifies the domain as a bulk sender, lowering volume later does not remove that status.
Who the rules apply to
Google's sender rules apply to mail sent to personal Gmail accounts, meaning addresses ending in @gmail.com or @googlemail.com. The rules are not written for mail sent to Google Workspace accounts, although the same engineering work often improves mail sent everywhere.
For an implementation checklist that maps these requirements into sender tasks, use the Gmail compliance checklist. The key point is that Gmail counts mail across the same primary domain, so splitting volume across subdomains does not avoid bulk sender status.
- All senders: Need SPF or DKIM, valid DNS, TLS, RFC 5322 formatting, low spam rates, and no Gmail From header impersonation.
- Bulk senders: Need SPF, DKIM, DMARC, From header authentication at the same organizational domain, and one-click unsubscribe for marketing mail.
- Domain counting: Mail from a root domain and its subdomains is counted together for the 5,000-message threshold.
- Workspace caveat: The published Gmail enforcement scope is personal Gmail recipients, not Google Workspace recipients.
What changed in enforcement
The most important recent shift is that Gmail is attaching clearer consequences to specific failures. Temporary 4.7.x responses give senders a chance to slow down and fix the issue. Permanent 5.7.x responses mean Gmail has blocked the message because a requirement failed.
|
|
|
|---|---|---|
4.7.23 | PTR | DNS mismatch |
4.7.27 | SPF | SPF failed |
4.7.29 | TLS | TLS missing |
4.7.30 | DKIM | DKIM failed |
4.7.31 | DMARC | Record missing |
4.7.32 | From | Domain mismatch |
Common Gmail enforcement signals for bulk sender requirements.
Spam rate bands Gmail cares about
Gmail calculates user-reported spam rate daily. The safer operating target is under 0.1%, with 0.3% treated as the hard danger line for bulk senders.
Healthy
Below 0.1%
Good operating zone
At risk
0.1% to 0.29%
Negative inbox impact
Non-compliant
0.3% or higher
Mitigation unavailable
Earlier reading
- Guideline feel: Many teams treated the page as advice for better deliverability.
- Unsubscribe: One-click unsubscribe was often delayed behind template and platform work.
- Authentication: Some senders accepted DMARC reporting gaps as a future project.
- Partners: Affiliate and co-marketing traffic often had weaker oversight.
Current operating model
- Guideline feel: Gmail now ties failures to rate limits, rejections, spam foldering, and support limits.
- Unsubscribe: Marketing mail needs RFC 8058 one-click headers and a visible body link.
- Authentication: DMARC reporting needs active monitoring, not just a TXT record.
- Partners: Affiliate senders need regular checks and fast removal when they create spam.
Authentication changes to fix first
For bulk senders, the first job is boring and technical: make the identity chain consistent. SPF should authorize the sending service. DKIM should sign the mail with a domain you control. DMARC should exist on the visible From domain, and at least one authenticated domain must satisfy the same-domain DMARC requirement.
I would not jump straight to a strict DMARC policy if reporting is not understood yet. Start with DMARC monitoring, confirm every legitimate sender, then move policy in stages. Suped's DMARC workflow is built around that path: identify sources, detect authentication failures, show steps to fix them, and alert when new failures appear.
Starter DMARC record for monitoringDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
This is also where a broad check helps. A domain health checker can catch missing DNS records, weak authentication, and configuration drift before Gmail turns the issue into a bounce pattern.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Unsubscribe and consent details
The unsubscribe requirement is specific: marketing, promotional, and subscribed messages from bulk senders need one-click unsubscribe support and a clearly visible unsubscribe link in the message body. Transactional messages, such as password resets and reservation confirmations, are excluded from the one-click requirement.
The one-click part needs headers. A mailto link or a preferences page inside the body does not satisfy the one-click header requirement by itself. Gmail also expects unsubscribe requests to be honored within 48 hours.
One-click unsubscribe headersHTTP
List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://example.com/unsubscribe/abc123>
Keep confirmation even when wording changes
Google's older wording around confirmed opt-in has changed over time, but the current page still tells senders to make sure recipients opt in and to confirm each recipient's email address before subscribing them. I keep that as a hard operational rule because it lowers complaint risk.
Affiliate, links, and reputation checks
Another wording change that matters in practice is affiliate marketing. Google's current guidance does not read like a blanket ban on affiliate traffic. It says spammy affiliates can damage the brand's mail, so senders should monitor affiliates and remove anyone sending spam.
I treat that as a reputation-control requirement. Track who is sending, what domains they use, where click tracking redirects, and whether linked domains are being flagged. Gmail also says web links in the body should be visible and easy to understand, which matters when a tracking domain looks unrelated to the brand.
This is where blocklist and blacklist monitoring helps. If a shared IP, sending domain, or tracking domain is listed, Gmail delivery can degrade even when SPF, DKIM, and DMARC are technically passing. Suped includes blocklist monitoring alongside authentication checks so the investigation does not stop at DNS.
After changing templates, links, headers, or tracking domains, send a real message and inspect the result with an email tester. DNS checks prove records exist; a delivered test shows what the receiving side sees.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A practical compliance order
The fastest way through the recent changes is to fix requirements in the order Gmail can enforce them. Start with hard authentication and infrastructure failures, then move into complaint rate, unsubscribe behavior, and partner governance. For more detail on the enforcement shift, see the November 2025 update.
- Inventory senders: List every platform, application, affiliate, and internal system sending from the primary domain or subdomains.
- Fix DNS: Confirm SPF includes only real senders, DKIM uses at least 1024-bit keys, and reverse DNS matches sending hosts.
- Publish DMARC: Start with reporting, review sources, then move toward quarantine or reject after legitimate mail passes.
- Check unsubscribe: Add one-click headers to marketing mail and process requests within 48 hours.
- Watch complaints: Operate below 0.1% user-reported spam and keep 0.3% as the line you never cross.
- Review partners: Remove affiliates or co-marketing sources that create spam complaints, unsafe-link warnings, or blacklist listings.
Where Suped fits
For most teams that need an ongoing workflow, Suped is the best overall practical choice because it brings DMARC, SPF, DKIM, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, blocklist checks, and MSP multi-tenant views into one place, with issue detection and fix steps attached to the sources causing the failures.
Views from the trenches
Best practices
Treat Gmail requirements as a live checklist, not a one-time DNS project with no owner.
Keep opt-in proof and confirmation steps, even when the public wording changes over time.
Review affiliate and partner sending weekly, then remove sources that create spam reports.
Track click domains and final URLs together so unsafe-link warnings are easier to trace.
Common pitfalls
Assuming DMARC at p=none is the end state leaves spoofing and brand abuse unresolved.
Using shared click tracking domains without reputation checks makes warnings harder to trace.
Watching only open rates misses the spam complaints and bounces Gmail actually weighs.
Letting affiliates send without clear controls can damage the brand's primary domain.
Expert tips
Test real messages after DNS changes, because pass results in DNS do not prove inbox behavior.
Separate transactional and marketing streams so complaints do not affect critical mail.
Keep a rollback plan for template, header, and tracking changes that alter Gmail signals.
Use weekly source reviews to catch new senders before Gmail turns failures into bounces.
Marketer from Email Geeks says Google removed a stronger confirmed opt-in phrase, but kept opt-in and confirmation guidance in the sender requirements.
2026-02-12 - Email Geeks
Marketer from Email Geeks says the affiliate wording changed toward monitoring affiliates and removing spam-producing partners, which is more operational than a blanket ban.
2026-02-19 - Email Geeks
What to do next
The answer to the title is direct: Google's recent bulk sender changes are stricter enforcement, clearer failure handling, a compliance dashboard, permanent bulk sender status once the 5,000-personal-Gmail threshold is reached, and tighter operational expectations around unsubscribe, spam rate, partners, links, and authentication.
The practical move is to treat Gmail compliance as continuous monitoring. A domain can pass today and fail next week when a new sender is added, an SPF record exceeds limits, DKIM breaks during a platform migration, a partner sends low-quality traffic, or a tracking domain gets listed on a blocklist (blacklist). Suped is useful here because it keeps the technical record checks, reports, alerts, and source-level fixes connected.
