Why is Gmail rate limiting my marketing and transactional emails after a period of low sending volume?
Updated on 4 Aug 2026: We updated this guide with Gmail's current 4.7.28 retry sequence, clearer reputation scopes, and bulk-sender compliance checks.
Gmail is most likely rate limiting your marketing and transactional emails because the current traffic is larger or faster than the recent pattern Gmail has seen. A domain or IP that sends very little for several weeks has a thin recent baseline. When it suddenly sends a large campaign, Gmail can treat that traffic as unusual and slow acceptance with temporary 4xx deferrals.
The most useful clue is the exact Gmail response. If the bounce says 4.7.28 and mentions an unusual rate of mail from your SPF domain, this is a temporary Gmail rate limit tied to the return-path or SPF domain Gmail sees. Other 4.7.28 variants can name an IP address, IP netblock, DKIM domain, URL domain, or repeated Message-ID, so do not assume every event has SPF scope.
Marketing and transactional streams are not perfectly isolated just because one uses a subdomain and the other uses the root domain. Gmail can apply limits to the visible From domain, return-path domain, DKIM domain, IPs, or URL domains. Start with the identity named in the Gmail response, then check whether the transactional stream shares it. If the response names no scope, treat the IP, SPF, and DKIM identities as affected until the logs show otherwise.
The direct answer
A long quiet period lowers Gmail's expectation of how much mail your domain or IP will send. If you usually send small journey traffic and then send a large marketing batch, Gmail sees a volume spike. The spike can be enough to rate limit the authenticated domain or sending IP named in the response, even if the domain has existed for years and previous campaigns performed well.
What the Gmail response means
This wording points to a rate limit rather than a normal mailbox-level bounce. Gmail is telling you which sending identity or traffic scope triggered the throttle.
- Status: A 4xx code means defer and retry, not permanently fail.
- Scope: Investigate the IP, domain, URL domain, or other identity named in the response.
- Cause: Recent low volume followed by a large campaign is a common trigger.
- Risk: Provider retry windows can expire and convert deferrals into reported bounces.
Typical Gmail 4.7.28 response
4.7.28 Gmail has detected an unusual rate of mail originating from your SPF domain [bounce.email.brand.co.uk]. To protect users from spam, mail sent from your domain has been temporarily rate limited. Review Gmail bulk sender guidance.
The confusing part is that your sending platform can label the outcome as technical, unknown, or bounced. That usually happens after the message sits in retry for hours and the platform gives up. Separate the original SMTP response from the platform's final reporting category before changing DNS or suppressing recipients.
|
|
|
|---|---|---|
4.7.28 | Temporary rate limit | Use the named scope and slow volume |
4.4.7 | Retry window expired | Inspect prior deferrals |
SPF domain | Return-path reputation scope | Map all sources using it |
No named scope | Scope is not isolated in the response | Check IP, SPF, and DKIM |
How to read common Gmail evidence.
Why low volume causes a sudden Gmail throttle
Gmail does not only care that you sent a similar campaign two months ago. It evaluates recent sending behavior. A domain that sends a few journey emails for six weeks and then sends hundreds of thousands of marketing emails has changed its sending pattern sharply.
That is why a campaign can go from 99.5% delivery to a large Gmail failure rate without an obvious DNS change. The change was the sending rhythm. After a quiet period, the next high-volume send asks Gmail to accept more mail than the sender's recent track record supports.
Internal sending-gap planning tiers
Conservative planning tiers for deciding when to rewarm. These are not Gmail limits or published thresholds.
Normal
0-7 days
Regular sends with no long quiet gap
Caution
8-21 days
Recent baseline starts to thin out
Rewarm
22+ days
Treat large Gmail volume as risky
Gmail publishes no fixed quiet-period cutoff. The longer the gap and the larger the planned increase, the more conservative the next Gmail send should be. If you send one major campaign every other month, keep a small, engaged Gmail segment moving between large sends or treat each major campaign like a partial rewarm.
What Gmail sees
- Volume: A sharp jump against recent Gmail traffic.
- Identity: Return-path, DKIM, From domain, IP, and URL domains.
- Feedback: Spam reports, subscription quality, message content, and delivery errors.
- History: Recent signals carry more practical weight than old campaign results.
What senders often see
- Reports: Unknown or technical bounces after retries expire.
- Confusion: Marketing failure followed by transactional delays.
- Assumption: Similar campaign size means similar Gmail treatment.
- Fix: Rebuild steady volume before the next large batch.
What to check first
Start with evidence, not assumptions. Get the full unedited SMTP response for both the marketing platform and the transactional platform. Pull the raw event reason and SMTP response, not only the dashboard category, so the original deferral is not hidden by a final bounce label.
- Bounce text: Confirm whether Gmail returned 4.7.28, 4.4.7, or another code.
- Named scope: Record the IP, SPF domain, DKIM domain, URL domain, or other identity in Gmail's response.
- Volume graph: Compare the last 30 to 60 days against the failing campaign day.
- Gmail split: Segment Gmail addresses separately from the rest of the list.
- Authentication: Run a domain health check before sending again.
- Compliance: For bulk mail, verify PTR records, TLS, SPF, DKIM, DMARC alignment, and one-click unsubscribe for marketing or subscribed messages.
Google Postmaster Tools showing lower reputation and temporary Gmail rate-limit errors.
Google Postmaster Tools can help when the root domain has enough Gmail volume to show data. Review Compliance status, domain reputation, IP reputation, spam rate, authentication, and delivery errors around the campaign date. Sparse data does not prove that no problem exists. If the dashboard shows a compliance failure, low reputation, or a delivery error spike, treat the next send as a recovery send.
Do not confuse this with outbound mailbox sending caps such as Workspace limits. Those limits control how much mail a Google Workspace account can send. The issue here is Gmail deciding how much inbound mail it will accept from your sending identity.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Before resuming volume, send a real message through the same platform, bounce domain, DKIM selector, and From domain you plan to use. A live email tester run will not prove Gmail reputation is fixed, but it catches broken authentication, bad headers, and content issues before you add volume.
How marketing can affect transactional mail
Transactional mail can be affected after a marketing spike when the streams share reputation signals. A different platform does not guarantee isolation. If the marketing stream uses email.brand.co.uk and the transactional stream uses brand.co.uk, the traffic can still share an organizational domain, DKIM domain, bounce domain, URL domain, or sending IP.
The practical question is which identifiers overlap. Map each stream in a small matrix and mark every shared item. More overlap creates more ways for a Gmail rate limit on one stream to affect the other.
|
|
|
|---|---|---|
From | email subdomain | root domain |
Bounce | marketing bounce | transactional bounce |
DKIM | platform selector | app selector |
Links | tracking host | app host |
IPs | bulk pool | transactional pool |
Isolation checks for marketing and transactional streams.
If the transactional sender has different bounce domains, DKIM domains, and IPs, it has stronger separation. If it shares an organizational domain, branded URL domain, or sending IP pool, isolation is weaker. Transactional bounce logs matter because they show whether Gmail named the same scope or a related identity.
Gmail rate-limit investigation flow from SMTP response to controlled rewarming.
A practical recovery plan
The fix is to reduce Gmail volume, rebuild recent reputation, and keep transactional traffic protected while the marketing stream recovers. Do not resend the failed campaign to the same Gmail audience at full size. That repeats the pattern Gmail just throttled.
- Pause: Stop large Gmail batches until deferrals fall back to normal.
- Segment: Send first to recently engaged Gmail recipients only.
- Ramp: Increase Gmail volume in controlled steps over several sends.
- Separate: Keep transactional mail on its own authenticated path.
- Monitor: Watch Gmail deferrals, spam rate, complaints, and DMARC failures.
Example Gmail recovery ramp
Illustrative percentages of normal Gmail campaign size, not Gmail limits. Adjust each step using deferrals and recipient feedback.
Gmail volume
A recovery ramp is not a fixed daily schedule. It is a decision loop. If Gmail deferrals rise, hold or step back. If Gmail accepts the mail and recipient feedback stays controlled, increase. For a deeper recovery model, use a ramp-up strategy based on engagement tiers, not a flat percentage of the whole list.
Do not retry the whole failed audience
A full resend to Gmail after a 4.7.28 event usually extends the problem. Gmail has already told you the rate is unusual.
- Better: Start with recent clickers, buyers, active app users, or confirmed readers.
- Hold: Suppress inactive Gmail recipients until reputation recovers.
- Protect: Keep password resets, receipts, and account alerts separate.
If you are also seeing 421 4.7.28 deferrals, treat them as the same family of symptoms: Gmail is slowing acceptance because the traffic profile looks risky.
How to control Gmail retries and throughput
Gmail publishes no universal messages-per-minute limit for bulk senders. Its current 4.7.28 guidance uses the SMTP response as the control signal, so throughput should fall as soon as temporary deferrals rise.
- Stop: After 4.7.28, do not send Gmail traffic for at least 10 minutes.
- Identify: Use the error text to find the affected IP, SPF domain, DKIM domain, or other scope.
- Test: After the pause, send through one SMTP connection.
- Wait: If that connection is deferred, stop for another 10 minutes.
- Increase: After a successful test, add connections one at a time while watching SMTP errors.
When your sending provider controls connections
Ask the provider to lower Gmail throughput and confirm that 4xx responses use exponential backoff. Leave deferred recipients in the existing retry queue. Starting a second campaign to the same recipients creates duplicate traffic and works against the throttle.
Where Suped fits
Suped is our DMARC and email authentication platform. For this workflow, it helps identify which marketing and transactional sources authenticate with SPF and DKIM, which domains they use, and when source-level failures change during a Gmail incident. The SMTP response still determines whether Gmail has applied a 4.7.28 rate limit.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Use Suped's DMARC monitoring to confirm that every marketing and transactional source passes authentication and uses the expected domain. Source-level failures, unverified senders, and sudden shifts in authentication health help narrow the incident to a bounce domain, source, or selector that changed behavior.
Suped's product also includes Hosted SPF, SPF flattening, Hosted DMARC, Hosted MTA-STS, real-time alerts, and blocklist (blacklist) visibility. The blocklist monitoring view belongs in the incident checklist when a Gmail issue occurs alongside wider IP or domain reputation concerns. A blocklist or blacklist entry is not the usual cause of a Gmail 4.7.28 rate limit, so keep it separate from the SMTP diagnosis.
Manual incident handling
- Collection: Pull bounce logs, DNS records, source lists, and Postmaster data.
- Analysis: Compare each platform's SPF, DKIM, and DMARC behavior.
- Risk: Missed source changes delay recovery and protect fewer streams.
Suped workflow
- Detection: Automated issue detection flags authentication and source problems.
- Action: Steps to fix help teams correct DNS and sender setup quickly.
- Scale: MSP and multi-tenant views help manage many domains at once.
Views from the trenches
Best practices
Keep low, steady Gmail volume between campaigns so reputation does not cool off for weeks.
Pull full SMTP responses before diagnosing bounces reported by marketing or app platforms.
Map every shared sender identity before assuming subdomains isolate reputation completely.
Common pitfalls
Treating a 4xx Gmail deferral as a hard bounce hides the real temporary rate limit.
Sending one large campaign after six quiet weeks can exceed Gmail's recent expectation.
Ignoring transactional bounce logs leaves shared domain reputation questions unresolved.
Expert tips
Use engaged Gmail recipients first, then expand volume only when deferrals stay normal.
Check Google Postmaster Tools on the root domain when Gmail volume is high enough.
Keep critical transactional traffic on separate bounce, DKIM, and IP infrastructure.
Marketer from Email Geeks says the full Gmail bounce message is the first evidence to collect because categories alone hide whether the event was a deferral or a permanent rejection.
2025-02-04 - Email Geeks
Marketer from Email Geeks says a 4.7.28 response usually points to temporary Gmail rate limiting, and the named SPF domain should drive the first investigation.
2025-02-04 - Email Geeks
The practical fix
When Gmail reports an unusual sending rate, slow the affected scope even if authentication passes and an older campaign of similar size delivered normally. Collect the full SMTP responses, map shared identities across marketing and transactional streams, check domain and IP reputation, and rebuild volume with engaged recipients. Keep a maintenance stream between major campaigns so the next send does not arrive after a long quiet gap.
Suped keeps the authentication side visible during recovery. DMARC, SPF, DKIM, sender sources, hosted SPF, MTA-STS, alerts, and blocklist or blacklist checks help the team identify which authenticated stream changed while Gmail SMTP logs control the rate-limit response.
