What are the updated Google bulk sender guidelines and TLS requirements for email senders?
Matthew Whittaker
Co-founder & CTO, Suped
Published 6 Aug 2025
Updated 24 May 2026
7 min read
Summarize with
The updated Google bulk sender guidance means this: if your domain sends close to 5,000 or more messages in a 24-hour period to personal Gmail accounts, you are a bulk sender for Gmail. Personal Gmail means addresses ending in @gmail.com or @googlemail.com. The Google sender guidelines now state the requirements around SPF, DKIM, DMARC, TLS, reverse DNS, spam rate, message format, and one-click unsubscribe.
The part that catches teams is the recipient scope. Google Workspace recipient mailboxes are not the enforcement target in this wording. A sender using Google Workspace still has to comply when it sends to personal Gmail. I would treat that as an enforcement boundary, not as permission to delay authentication work, because most B2C lists and many SMB-heavy B2B lists contain a large Gmail share.
- Scope: The 5,000-message threshold is counted against personal Gmail recipients by primary domain.
- TLS: Email must be transmitted to Gmail using TLS on the SMTP connection.
- Authentication: Bulk senders need SPF, DKIM, and a DMARC record with at least p=none.
- Unsubscribe: Marketing and subscribed messages must support one-click unsubscribe.
What changed in Google's sender rules
The change was not a brand-new idea that TLS matters. Google had pushed TLS for years. The practical update is that TLS moved into the published sender requirement table, and Google now lists specific failure paths for mail that is not transmitted securely. The Google FAQ also clarifies that sender requirements and enforcement apply to personal Gmail accounts, not Google Workspace inbound or intra-domain mail.
The bigger operational point is that a domain becomes a bulk sender permanently after it meets the Gmail threshold. Cutting volume later does not reset that status. If one campaign or seasonal event crosses the line, I would keep the domain under the bulk-sender controls after that.
|
|
|
|---|---|---|
Recipient scope | Personal Gmail | Personal Gmail |
Volume trigger | Any volume | Near 5,000/day |
SPF and DKIM | SPF or DKIM | SPF and DKIM |
DMARC | Recommended | Required |
TLS | Required | Required |
Spam rate | Below 0.3% | Below 0.3% |
Unsubscribe | Good practice | Marketing mail |
Compact view of Google's current sender requirements.
Do not miss the smaller requirements
- DNS: Sending domains and IPs need valid forward and reverse DNS, including PTR records.
- Format: Messages should follow RFC 5322 and must not impersonate Gmail in the From header.
- Forwarding: Forwarders should add ARC headers, and mailing lists should include a List-id header.
- Unsubscribe: Marketing mail needs one-click unsubscribe and requests honored within 48 hours.
What TLS means here
TLS means Transport Layer Security. In this context, it is encryption for the SMTP session between the sending mail server and Gmail. It is not the same thing as HTTPS links inside the message body. If your click tracking rewrites a visible link through HTTP, that is a separate link-safety issue, not the SMTP TLS requirement Google is talking about.
SMTP TLS
- Owner: Your ESP or sending MTA controls whether the Gmail handoff uses TLS.
- Check: Inspect message headers, SMTP logs, or provider delivery logs.
- Risk: Gmail can rate limit, reject, or place non-TLS mail in spam.
Message links
- Owner: Your ESP, link tracker, website team, and CDN setup control link behavior.
- Check: Review rendered email links after tracking is applied.
- Risk: HTTP links are not the TLS rule, but HTTPS links are still the better practice.
Gmail TLS SMTP errorstext
4.7.29 Temporary failure: message was not sent over TLS. 5.7.29 Permanent failure: message was not sent over TLS.
For most brands using a major ESP, TLS is already on. I still check it because some custom MTAs, older relay paths, or regional vendor setups have exceptions. The sender usually cannot fix this with a DNS record. The sending platform has to negotiate TLS when it connects to Gmail.
How to check if you are affected
Start with the volume question, but do not stop there. The threshold is close to 5,000 messages in a 24-hour period to personal Gmail accounts, counted across the same primary domain. Subdomains roll up to the same primary domain for this purpose. I use the volume thresholds lens because senders often miss transactional, lifecycle, and product email when they only count newsletter volume.
Gmail spam-rate thresholds
Use Gmail spam-rate data as a daily guardrail, not a monthly report.
Target
Below 0.1%
Healthy operating range for bulk senders.
Warning
0.1% to 0.29%
Reputation risk rises and list quality needs attention.
Critical
0.3%+
Google lists 0.3% or higher as the maximum to avoid.
Flowchart showing Gmail volume, TLS, SPF, DKIM, DMARC, and complaint checks.
- Volume: Count all mail streams using the same primary domain, including product and lifecycle mail.
- Recipients: Separate personal Gmail accounts from Google Workspace recipients in reporting.
- Domains: Audit every visible From domain and every platform sending mail for that domain.
- Complaints: Track spam rate daily and keep it below 0.1% wherever possible.
Authentication records to put in place
The Gmail requirement is simple to say and easy to get wrong in a multi-platform sending setup. Bulk senders need SPF and DKIM authentication, a DMARC record, and a From domain that matches either the SPF domain or DKIM domain at the organizational-domain level. I prefer to prove this with live messages, not screenshots from vendor setup pages.
For ongoing operations, DMARC monitoring gives you the source-level view that DNS alone cannot provide. A domain health check is useful for broad DNS coverage, and an SPF checker helps catch lookup-limit and include-chain problems before they cause Gmail failures.
Minimum DMARC record for Gmail bulk sendersdns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Where Suped fits
Suped is the best overall fit for most teams that need DMARC operations, not only record validation. Suped brings DMARC, SPF, DKIM, hosted SPF, SPF flattening, hosted DMARC, hosted MTA-STS, real-time alerts, blocklist (blacklist) monitoring, and MSP multi-tenancy into one workflow with issue detection and practical fix steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
That matters for Google compliance because the hard part is rarely creating one DMARC record. The hard part is finding every legitimate sender, spotting the ones that fail SPF or DKIM, and correcting vendor setup without breaking production mail.
Unsubscribe, spam rate and enforcement
For bulk senders, marketing and subscribed messages need one-click unsubscribe. Transactional messages such as password resets and receipts are not in that specific requirement, but they still have to meet authentication, TLS, DNS, and formatting expectations. The safest operational pattern is to keep unsubscribe logic close to the list or message stream that triggered the send.
One-click unsubscribe headerstext
List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://example.com/unsubscribe/abc123>
Google says the top-of-message unsubscribe link appears only after automated eligibility checks pass. Adding the header does not force the UI to appear. It has to be paired with good sender behavior, low spam reports, and correct headers. For implementation detail, I would read the one-click rules before changing production templates.
Do not treat 0.3% as the target
Gmail's published maximum is 0.3%, but I treat 0.1% as the practical operating limit. Once the rate reaches 0.3%, mitigation options shrink and every new campaign has less room for normal list variance.
A practical compliance checklist
The fastest way to audit this is to send real messages through each mail stream and compare the results with DNS, DMARC reports, and provider logs. Setup-page checks miss forwarding, shared IP issues, DKIM selector drift, and template-specific unsubscribe gaps.
- Inventory: List every ESP, CRM, support desk, billing tool, product system, and relay.
- Authenticate: Publish SPF, enable DKIM, and confirm the From domain matches one authenticated domain.
- Monitor: Read DMARC aggregate reports so unknown senders and broken authentication show up quickly.
- Test: Send a real campaign seed through the email tester and inspect authentication headers.
- Escalate: Ask the sending provider for TLS evidence if headers or SMTP logs show a gap.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If a test fails, I fix the source that generated the message rather than editing the domain record blindly. One domain can have twenty senders with different DKIM selectors and bounce domains. A broad DNS change can hide the real issue or create a new one.
Views from the trenches
Best practices
Treat Gmail personal traffic as enough reason to meet the full bulk-sender standard.
Ask each sending platform to confirm TLS on Gmail SMTP handoff, not only account TLS.
Keep DMARC reports mapped to real vendors so fixes target the sender causing failures.
Common pitfalls
Counting only newsletter volume misses product, support, billing, and lifecycle sends.
Assuming Workspace recipients are covered creates confusion about the enforcement scope.
Checking only DNS records misses live-message failures caused by provider configuration.
Expert tips
Use Gmail errors such as 4.7.29 and 5.7.29 to route TLS issues to the sender owner.
Keep HTTPS tracking links as a best practice, but separate them from SMTP TLS checks.
Move toward SPF and DKIM domain matches now, even where only one match is required.
Marketer from Email Geeks says personal Gmail scope still covers enough B2C and SMB B2B traffic that the practical workload is mostly unchanged.
2024-01-09 - Email Geeks
Expert from Email Geeks says TLS is controlled by the ESP or sending MTA, so customers usually need provider confirmation rather than DNS edits.
2024-01-12 - Email Geeks
What I would do next
I would treat the updated Google guidance as a baseline for every serious sender, even if the written enforcement scope is personal Gmail. Set up SPF, DKIM, DMARC, TLS, forward and reverse DNS, one-click unsubscribe for marketing mail, and daily spam-rate monitoring. Then keep watching the actual mail streams, because vendor drift causes more problems than the first DNS setup.
The TLS requirement is usually an ESP or MTA issue. The domain owner still owns verification. If Gmail starts returning TLS, SPF, DKIM, DMARC, or DNS errors, route the issue to the platform that sent the message and keep a record of the fix. That is the practical way to stay compliant without making random DNS changes.
