What causes Gmail 4.7.28 rate limit exceeded in email workflows?

You send a campaign, and suddenly Gmail starts rejecting your messages with a 4.7.28 error. No bounce, no complaint — just silence. You check your logs, and the only clue is “rate limit exceeded.” You’re not spamming. You’re just trying to deliver email at scale.

Gmail doesn’t punish volume outright — it’s designed to protect inboxes, not block workflows. That error appears when your sending pattern hits a real-time throttle, whether from a sudden burst, misconfigured API rate limits, or a new domain with no reputation history.

Think of Gmail’s rate limits like a highway ramp meter: it allows steady, predictable flow but cuts you off when you try to merge at full speed. The 4.7.28 error isn’t a system fault — it’s a signal that your delivery process needs alignment, not a rewrite.

Key takeaways

  • Gmail 4.7.28 errors occur when sending exceeds real-time IP, domain, or account rate thresholds, triggering throttling.
  • Burst campaigns, unbounded APIs, or sending from new/low-reputation domains are common triggers.
  • Rate limits are enforced per source (IP, domain, account), not just per message volume.

Is Gmail 4.7.28 a hard bounce or a temporary throttle?

Gmail 4.7.28 is a temporary throttle, not a hard bounce. It means your message was accepted but delayed or rate-limited due to volume constraints from your sender IP or domain. Unlike permanent failures like 5.1.1 (invalid address), 4.7.28 indicates the recipient address is valid and the issue is sender-side throttling—common when sending large volumes or rapid spikes.

Understanding the difference: soft limit vs. hard rejection

When Gmail returns 4.7.28, it’s signaling a soft limit. The server accepts the message, but delays delivery or slows down future messages from the same sender. This is part of Gmail’s anti-spam defense—the system allows you to send mail, but only within certain thresholds.

Hard bounces (like 5.1.1 or 5.2.1) mean the address is broken or unreachable. 4.7.28 doesn’t imply that. It means the inbox exists, but you’re sending too fast. If you're seeing this consistently, the problem isn’t the email address—it’s your sending rhythm.

What triggers this error in real workflows

4.7.28 often shows up during mass campaigns, automated trigger emails, or when sending through an under-optimized delivery stack. Common causes include: sending more than 500 messages per minute from a single IP, or failing to rotate sender IPs across batches. Gmail uses real-time volume thresholds, so even legitimate senders hit limits during peak activity.

You can verify if your sender reputation is healthy using tools from Spamhaus or MxToolbox. These help identify if your IP is flagged or if your sending velocity is too high.

Let’s be clear: 4.7.28 is a warning, not a failure. Your message isn’t “dead” — it just needs breathing room. The real fix isn’t to reverify the address, but to manage sending speed and use proper authentication.

Before sending at scale, validate your list with MailTester’s bulk verification. It flags invalid, risky, and catch-all addresses before they impact delivery. For ongoing workflow integration, use the real-time verification API to filter bad addresses in real time.

How does sender reputation impact Gmail rate limits?

Gmail uses your sender reputation—built from spam complaints, bounce rates, and email engagement—as a key factor in determining your rate limits. Even if every address in your list is valid, high bounce rates or low open/click rates signal poor list hygiene, prompting Gmail to reduce your daily sending capacity. A sender with consistent, high engagement and clean compliance history typically receives higher thresholds than one with erratic or low-performing patterns.

Reputation signals that shape rate limits

Gmail doesn’t just look at whether an address is valid—it watches how users interact with your messages. If recipients frequently mark your emails as spam, or if your bounce rate exceeds 2%, Gmail treats your account as a higher risk, which can trigger rate limitations. You can have a technically flawless setup, but if engagement is low, Google assumes your content lacks relevance and adjusts limits accordingly.

Spam complaints are especially damaging: even one complaint per 1,000 emails can trigger a reputation downgrade. Meanwhile, email engagement—such as open rates and click-throughs—is a strong signal of user interest. High engagement correlates with higher rate allowances, because Gmail sees your emails as valuable and trusted.

How to build and maintain a strong sender reputation

Let’s be clear: you can’t bypass reputation signals. No matter how many emails you send, Gmail will restrict you if your historical performance is inconsistent or poor. The best way to stay within rate limits is to send only to engaged, validated subscribers.

Use tools like MailTester to filter your list before sending. Bulk verification removes invalid addresses and catch-alls, reducing bounce rates. Real-time API checks help you validate addresses on sign-up, keeping your list clean from the start. Inbox placement tests let you see how Gmail likely treats your messages in practice.

Consistency matters. Sending small batches daily with strong engagement performs better than sudden spikes, even if those spikes are under the technical limit. Over time, Gmail learns your patterns. If your sending behavior is predictable and your audience engages, you’ll see higher thresholds naturally.

For deeper insight, consult the RFC 6655 on email delivery and the Spamhaus Project, which provides industry-standard data on abuse and reputation tracking. You can also explore how MailTester helps maintain sender health: bulk verification, API integration, or inbox placement testing.

How to verify your sending system is within Gmail’s limits?

You can confirm your sending system stays under Gmail’s rate limits by simulating real sends with inbox placement testing, monitoring your ESP’s rate-limit headers like X-Rate-Limit or X-Retry-After, and logging SMTP responses to catch burst patterns that trigger throttling. This proactive approach catches issues before they trigger 4.7.28 errors in production.

Step-by-step verification process

  1. Run inbox placement tests with real-world conditions. Use tools like MailTester’s inbox placement tester to send a controlled batch of emails to Gmail under normal load. This simulates how Gmail evaluates your sender reputation and rate behavior. A consistent 4.7.28 error during testing reveals throttling patterns you’d otherwise only see in live campaigns. Test your inbox placement risk now.
  2. Monitor rate limit headers from your email service provider. Look for headers like X-Rate-Limit, X-Retry-After, or RateLimit-Limit in your SMTP response logs. These signals indicate how close you are to hitting a ceiling. For example, if X-Retry-After returns 60, your system needs to wait 60 seconds before sending again. Ignoring these cues leads to repeated 4.7.28 errors.
  3. Correlate SMTP responses with your sending schedule. Log every SMTP response — especially 4.7.28, 4.2.1, or 550 errors — alongside timestamps and send volume. Look for spikes in failures tied to bursts of 100+ messages sent within a short window. Gmail typically throttles senders who exceed 300–500 messages per minute from a single IP over sustained periods.
  4. Validate your sending infrastructure with real-time API checks. If you’re using a high-volume email system, validate individual addresses via a real-time verification API (like MailTester’s) before sending. This lets you catch invalid or rate-limited addresses before they impact your delivery flow. Check individual addresses in real time.

What to watch for in the logs

When reviewing logs, filter for bursts exceeding 50 emails in under 10 seconds. Even a single 4.7.28 response in high-volume sending can signal that your rate is too aggressive for Gmail’s threshold. These thresholds are not fixed — they vary based on sender reputation, volume consistency, and message content.

For example, RFC 5321 defines the standard SMTP transaction flow, but Gmail uses additional heuristics beyond RFCs to assess legitimacy. You’re not just sending messages — you’re proving ongoing trustworthiness through sustained, consistent behavior.

Rate limiting is not a failure of your infrastructure — it’s Gmail’s way of protecting its users from abuse. The goal isn’t to avoid limits entirely, but to stay below them without triggering throttling.

How can email verification prevent Gmail 4.7.28 errors?

Verifying your email list before sending reduces bounce rates and prevents your IP from being flagged for sending to invalid, catch-all, or role-based addresses—common triggers for Gmail’s 4.7.28 rate limit. By filtering out risky addresses early, you lower delivery pressure, improve sender reputation, and avoid throttling.

Invalid and risky addresses trigger rate limits

Gmail’s 4.7.28 error indicates a sending rate threshold has been exceeded. This often happens not from volume alone, but from poor list hygiene. Sending to invalid emails, catch-alls, or role-based addresses like sales@ or info@ generates bounces and signals low-quality sending behavior. Over time, this erodes your sender reputation, making Gmail more likely to throttle or block your messages.

According to RFC 6409, mail systems are expected to reject messages to addresses that cannot receive mail. Sending to such addresses violates this principle and contributes to rate limiting. A list riddled with these addresses is a red flag to Gmail’s filtering systems.

Verification reduces delivery pressure and improves hygiene

Let’s say you send 10,000 emails, but 15% are invalid or bounce-prone. Even at a moderate volume, the cumulative impact of bounces and soft errors triggers Gmail’s defenses. Verifying your list first cuts that number significantly—often by 50% or more—reducing the load on your sending infrastructure and protecting your reputation.

MailTester’s 98.9% accurate verification checks each address against real-time SMTP responses, catch-all detection, and role-based heuristics. It identifies risky emails before they enter your pipeline—so you’re not sending to addresses that will fail anyway. This means fewer bounces, fewer complaints, and less chance of hitting Gmail’s rate limits.

You can run this check at scale using the bulk verification tool, integrate it with your workflow via the real-time API, or test how your message lands in real inboxes with the inbox placement tester. Each step reduces the risk of delivery failure and helps maintain a strong sender reputation.

What’s the role of list hygiene in avoiding Gmail rate throttling?

Gmail’s 4.7.28 rate limit exceeded error often stems from poor sender reputation, which starts with a dirty email list. If your list contains invalid, outdated, or low-engagement addresses—especially disposable emails, catch-alls, or role accounts—Gmail sees this as a red flag. High bounce rates and low engagement signal spam behavior, triggering rate limits even if you're sending legitimate content. Clean lists reduce those signals, keeping you under Gmail’s radar.

How list hygiene directly prevents throttling

  • Run bulk list verification before sending to remove invalid or non-existent addresses—use MailTester’s bulk verification to catch 98.9% of invalid emails in minutes.
  • Eliminate disposable email domains (like mailinator or temp-mail.org) that are rarely used for real communication and are blocked by most major providers.
  • Filter out role accounts (e.g., sales@, support@, info@) since they rarely engage and often bounce, hurting sender reputation over time.
  • Remove catch-all addresses—these accept any email, even forged ones, and are commonly abused by spammers, making them suspect in Gmail’s eyes.
  • Automate verification using the MailTester API to validate addresses in real time, before they’re added to your send queue.

Why engagement and reputation matter to Gmail

Gmail doesn’t just track delivery volume—it measures how users interact with your messages. A high rate of bounces from old or fake addresses signals to Gmail that you’re not a real sender, which can trigger throttling, even at low volume. According to RFC 6650, sender reputation is a core factor in mail filtering decisions, with reputation derived from engagement, bounce rates, and user feedback.

Let’s be clear: a large list with 80% junk addresses won’t help your deliverability. Gmail’s systems are designed to protect users from spam. If you send to many unengaged or invalid addresses, you’re essentially asking to be blocked. Instead, trim your list regularly.

Use inbox placement testing to simulate real-world delivery and see how your clean list performs across Gmail, Yahoo, and Outlook before a major send.

How to integrate MailTester into your deliverability workflow?

You can prevent Gmail’s 4.7.28 rate limit exceeded errors by validating emails in real time before sending, cleaning your list weekly with bulk verification, and simulating inbox placement to catch problems before they hit your sender reputation. Let’s walk through how to build that into your workflow.

Step 1: Check emails in real time with the API

Use the MailTester real-time verification API just before dispatching each email. This ensures only valid, deliverable addresses go out — no guesswork, no wasted sends. It checks for syntax, domain validity, and whether the mailbox is accepting mail.

Why it works: SMTP errors like 4.7.28 usually show up when your server hits Gmail’s rate limits due to sending to invalid or quarantined addresses. Catching those addresses early avoids the trigger. A well-documented RFC 5321 behavior underpins this — sending to a non-existent or rate-limited mailbox can cause upstream feedback loops.

Step 2: Run bulk verification weekly

Set up automated weekly jobs using MailTester’s bulk list verification to scrub your entire list. This removes invalid, disposable, and catch-all domains before they cause bounces or damage your sender reputation.

Regular maintenance is essential. According to data from Return Path (now Validity), uncleaned lists see up to 20% more bounces — and those bounces are a primary signal that triggers Gmail’s rate-limiting mechanisms.

Step 3: Test inbox placement before full rollout

Before large sends, run your message through MailTester’s inbox placement test. It simulates delivery to Gmail, Outlook, and other major inboxes, showing you how likely your email is to land in the inbox rather than spam or junk.

You’re not just checking if an address exists — you’re measuring how Gmail sees your message. Sender reputation, content quality, and authentication all factor in. If your message is flagged early, you fix it without triggering rate limits during a real send.

“List hygiene isn’t optional. It’s the foundation of consistent inbox placement.”

Integrate these checks into your existing workflows using MailTester’s integrations with Mailchimp, HubSpot, and SendGrid. You can automate verification without changing your current email service. Start with 100 free verifications at MailTester’s pricing page, and credits never expire.

Which email services are most sensitive to 4.7.28 errors?

Gmail is the most sensitive to 4.7.28 rate limit exceeded errors due to its massive scale and public transparency around API behavior. Out of all major email providers, it enforces rate limits most strictly and consistently, especially for bulk sending. You’re more likely to hit 4.7.28 with Gmail than with Yahoo or Outlook, even if your sending volume is similar.

Gmail’s strict enforcement stems from its infrastructure and public API standards

Because Gmail powers billions of accounts and has well-documented rate limits for its APIs—like those used by Google Workspace—it applies consistent, predictable throttling. If you exceed send limits, even temporarily, Gmail returns 4.7.28 early and often. The code is rarely ambiguous, and the enforcement is immediate.

Yahoo and Outlook also apply rate limits, but they often use different error codes—like 550 or 554—and are more lenient on burst patterns. They may tolerate short spikes better than Gmail, especially on lower-volume senders. However, this doesn’t mean they’re forgiving at scale. Once thresholds are hit, you’ll still face delays or rejections, just not with the exact same response code.

Shared IPs amplify rate limit risk for small-scale senders

Smaller senders using shared infrastructure—such as AWS SES, SendGrid, or other cloud-based email services—are most vulnerable to sudden throttle spikes. Since you’re sharing an IP address with many other users, one sender’s burst can trigger widespread rate limiting. If you're sending 100 messages per minute on a shared IP, and another user spikes to 500, you may get the 4.7.28 error even if you're staying under your personal limit.

This is why testing your workflow with real inbox placement tools is critical. MailTester lets you simulate real sends across Gmail, Yahoo, and Outlook and detect rate limit behavior before you go live. You can catch 4.7.28 spikes early with inbox placement tests, and use bulk verification to clean your list and avoid unnecessary strain. Test your deliverability before you send.

Understanding how each provider handles throttling helps you design workflows that don’t trigger these errors. The key is not just reducing volume—but pacing, validating, and testing. Even if you’re not hitting a hard 4.7.28 code, consistent throttling can still damage sender reputation.

How does MailTester handle catch-all and disposable addresses?

You can trust MailTester to accurately identify catch-all domains and disposable email addresses. It checks if any address on a domain is deliverable to detect catch-alls, and flags disposable domains using known patterns and blocklists—helping you avoid bounces and protect your sender reputation. Every verification returns a clear verdict: valid, invalid, catch-all, or risky.

Catch-all domains: tested, not guessed

  • MailTester doesn't assume a domain is catch-all just because it accepts mail. It sends probe messages to test actual deliverability to real addresses on that domain.
  • This method avoids false positives—some domains only appear catch-all but actually reject unknown addresses. Real testing means you won't waste sends on domains that can't handle email routing correctly.
  • For example, if example.com accepts [email protected] but rejects [email protected], MailTester logs this as a non-catch-all. This prevents false flagging.

Disposable emails: caught early with precision

  • MailTester identifies disposable email domains like tempmail.org or 10minutemail.com using maintained blocklists and known domain patterns.
  • These domains are high-risk for engagement and often used for spam or bot activity. By tagging them early, you protect your sender reputation and filter out low-value addresses.
  • According to the Spamhaus Project, disposable email services are frequently linked to abuse, making early detection a key part of modern deliverability hygiene.

Each email verification returns one of four clear verdicts: valid, invalid, catch-all, or risky. This granular reporting lets you segment your list with confidence—filtering out risky addresses before they impact your inbox placement.

Use bulk verification to clean large lists, integrate the real-time API into your signup flows, or test actual inbox placement with our inbox tester. Verify your list once, and reduce bounces, spam complaints, and rate limit issues—especially when sending through Gmail or other strict providers.

How can you test if your email flow is rate-limited before it breaks?

You can proactively detect Gmail’s 4.7.28 rate limit by simulating real sends using MailTester’s inbox placement testing. This lets you observe whether the error surfaces during delivery attempts without risking real campaigns. By testing across IPs, domains, and times, you isolate triggers before they cause outages. The in-app AI assistant then analyzes logs to suggest rate-limiting adjustments tied to your sending profile.

Simulate delivery to catch throttling early

Instead of waiting for bounces or blocked sends, use MailTester’s inbox placement tester to send test emails to real Gmail inboxes. This replicates actual delivery conditions, including Gmail’s rate-checking mechanisms. If the 4.7.28 error appears during simulation, you know it’s a systemic issue — not just a one-off failure.

Try sending the same message from different sender IPs and domains. Compare results across time of day. Rate limits are often triggered by bursty sending patterns, especially during peak hours (e.g., 9–11 AM local time). Testing at different intervals helps reveal whether timing or sender identity is the bottleneck.

  1. Run inbox placement tests on your email flow using MailTester’s inbox tester. Choose Gmail as the target, then send a sample of your typical message to real inboxes. Watch for 4.7.28 in the delivery logs.
  2. Test across multiple sender configurations. Use different IPs and domains (even subdomains) to see if certain combinations trigger the limit more than others. SPF/DKIM alignment or domain reputation can influence throttling.
  3. Compare delivery across time zones. Send tests at multiple hours (e.g., 8 AM, 1 PM, 7 PM) to detect time-based throttling patterns. Google often applies stricter checks during high-volume periods.
  4. Use the in-app AI assistant to analyze your test logs. It cross-references sending volume, frequency, and IP reputation with known throttling thresholds. It may suggest reducing send frequency, adding delays, or using a new IP if current ones are flagged.
  5. Adjust your workflow based on insights. Apply changes like pacing sends over 24 hours or segmenting high-volume batches. Re-test with inbox placement to confirm improvements.

Rate limiting is not a bug — it’s a design feature to prevent spam abuse. Gmail’s own documentation confirms that “high message volume from a single IP or domain can trigger rate limiting” (Google Support). You don’t need to avoid sending; you just need to do it smarter.

For ongoing verification, use MailTester’s bulk verification to clean outdated or risky addresses before sending. This reduces the load on your server and lowers the chance of being flagged as spam. The verification API can be integrated into your workflow to scrub addresses in real time.

The bottom line: how to stop Gmail 4.7.28 errors from disrupting your workflow

Gmail’s 4.7.28 rate limit exceeded error triggers when sending volume outpaces Gmail’s dynamic thresholds. The most effective fix is to avoid bursts and distribute sends over time to stay under these thresholds.

Prevention is the only sustainable strategy

  • Verify your entire list with a tool like MailTester before each campaign to catch invalid, risky, or catch-all addresses upfront.
  • Monitor sender reputation and inbox placement continuously—early detection stops minor issues from becoming delivery blackouts.
  • Consistent list hygiene and volume pacing reduce reliance on reactive fixes.

Fixing deliverability after a spike is slower, more costly, and less effective than preventing it. Automated verification and real-time monitoring turn potential failures into reliable delivery.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does Gmail 4.7.28 mean?

It means Gmail temporarily throttled your sending due to rate limits. It’s a soft error, not a permanent bounce. You can continue sending, but with delays.

How long do 4.7.28 rate limits last?

Duration varies—typically hours to a full day. It’s based on sustained sending patterns, not a fixed interval.

Can a high bounce rate cause 4.7.28?

Indirectly, yes. High bounces signal poor list hygiene, which Gmail uses to lower rate limits for that sender.

Does MailTester prevent 4.7.28 errors?

It helps prevent them by filtering out invalid addresses before sending, reducing bounce risk and protecting sender reputation.

What’s the best way to test for Gmail throttling?

Run inbox placement tests through a deliverability tool. It simulates your email under real Gmail conditions and reports if rate limits are triggered.

Are catch-all emails dangerous for deliverability?

Yes. They often lead to hard bounces or soft rejects. Gmail may interpret sending to catch-alls as sending to spam traps, risking throttling.

Does MailTester handle role accounts like info@ or sales@?

Yes. It flags role addresses as risky. These are commonly used in spam campaigns and degrade reputation if sent to en masse.

Can disposable email domains cause 4.7.28 errors?

They don’t cause 4.7.28 directly, but they contribute to high bounce rates and poor engagement, which affect sender reputation and trigger throttling.

Do shared IPs increase the risk of 4.7.28?

Yes. Shared IPs are sensitive to aggregate behavior. A single sender abusing the limit can affect all others on the same IP.

How often should I clean my email list?

At least weekly, especially before large sends. Use MailTester’s bulk verification to maintain a clean list and avoid throttling.

Can I use MailTester with SendGrid or Mailchimp?

Yes. MailTester integrates with SendGrid, Mailchimp, Klaviyo, and HubSpot to verify lists before sending, reducing bounce and throttle risk.

Does MailTester offer real-time verification API?

Yes. Use the real-time API to verify individual or batch addresses on demand, ensuring only valid emails enter your workflow.