What does Gmail’s 421 4.7.28 error mean for your sends?

You just sent a high-volume email campaign. The send completed—except for a few hundred recipients. You check the bounce report and see it: 421 4.7.28. Your messages were rejected by Gmail's servers, not because the addresses are wrong, but because your IP sent too much, too fast.

This is not a permanent ban. It’s a throttle. Gmail’s SMTP server temporarily rate-limited your IP address to protect its network from spam. If you don’t understand what’s triggering this, or how to fix it, you’ll keep hitting walls—especially during list imports, new domain launches, or automated campaigns.

Fixing a Gmail 421 4.7.28 IP temporarily rate limited error isn’t about changing settings. It’s about diagnosing why your IP exceeded limits, understanding how sending patterns affect deliverability, and taking steps to avoid recurring blocks.

Key takeaways

  • Gmail 421 4.7.28 means your IP was temporarily rate-limited due to excessive sending in a short window, not a permanent block.
  • Repeated occurrences risk harming your sender reputation, increasing long-term bounce rates and inbox placement issues.
  • High-volume campaigns, new domains without proper warming, and poor queue management are leading causes of this error.

Why does Gmail temporarily rate limit IP addresses?

Gmail temporarily rate limits IPs to block spam, protect inbox quality, and manage server load. If your IP sends too many emails too quickly—especially with low engagement or high bounce rates—Gmail may delay or reject messages with a 421 4.7.28 error, even if your content is legitimate. This is not a rejection of your message’s content; it’s a signal that your sending behavior triggered automated defenses.

Rate limits aren’t just for spammers

Even if you're sending transactional or marketing emails for a real business, Gmail will enforce rate limits. High-volume senders without proper warming or infrastructure controls often hit these limits. For example, an IP that sends 20,000 emails in an hour—even if all are authorized—can be rate-limited if those emails aren’t engaging users or if the list includes inactive or invalid addresses.

Let’s be clear: Gmail doesn’t block senders for sending volume alone. It reacts to patterns that indicate abuse. These include low open rates, high bounce rates, sudden spikes in volume, and lack of feedback loop (FBL) data.

What causes the 421 4.7.28 error?

The 421 4.7.28 code means Gmail has temporarily paused incoming mail from that IP due to excessive sending. It’s not permanent—but it will persist until the sending patterns slow down and align with expected norms. This can happen with cold IPs (new senders) that haven’t been warmed up, or with poorly maintained lists that include outdated or invalid addresses.

High bounce rates, for example, signal poor list hygiene. Gmail tracks this across domains and IPs. If your list includes many addresses that don’t exist, bounce back, or consistently mark your emails as spam, Gmail assumes you’re sending to non-receivers. That triggers protective mechanisms like rate limiting.

Even small senders can trigger 421 4.7.28 if they send too fast—say, a 5,000-email blast on a new IP without gradual sending ramp-up. This is why email infrastructure must include proper warm-up, sender reputation monitoring, and list hygiene checks before deployment.

Proactive checks can prevent you from hitting these limits. Tools like MailTester help identify invalid or risky addresses before they affect your sending reputation. Use our bulk verification to clean your list, or inbox placement testing to check how your messages land in real inboxes. The real-time API lets you verify addresses as you collect them—before they cost you delivery. And once you’re sending, consistent hygiene and warm-up reduce the risk of hitting rate limits altogether.

How to verify if your IP is rate limited by Gmail

If you're getting a 421 4.7.28 error from Gmail, it means your IP has hit Gmail's sending rate limits. Check your SMTP logs for this specific response code. Use MxToolbox to test your IP's deliverability to Gmail. Review your ESP’s delivery reports for consistent rejections during narrow time windows. These signals confirm a rate limit, not a permanent block.

Check your SMTP logs for 421 4.7.28

  • Open your mail server logs and filter for responses from mail.google.com.
  • Look for the exact error code: 421 4.7.28 — this is Gmail’s official signal of temporary rate limiting.
  • Confirm the time of day and volume of messages sent when the error occurred. Rate limits often trigger after a spike in sending.
  • If this response appears repeatedly in a short span, it’s a strong indicator your IP is being throttled.

Test your IP’s deliverability with diagnostics

  • Use an established tool like MxToolbox to run an SMTP test from your IP to Gmail’s servers.
  • Run the test multiple times in quick succession — if the first few succeed but later ones return 421 4.7.28, you’ve hit a rate limit.
  • Compare results with a known clean IP to confirm the behavior is not isolated to your setup.
  • Check RFC 5321 for the standard SMTP response codes — 421 signals a temporary failure not tied to recipient validity.

Review delivery reports from your ESP

  • Log into your email service provider (e.g., SendGrid, Mailchimp, Klaviyo) and access delivery or bounce reports.
  • Filter by recipient domain gmail.com and look for rejection patterns tied to time stamps.
  • Rejections clustered within a 5–10 minute window suggest a rate limit, not a DNS, SPF, or DKIM issue.
  • If similar send volumes succeed at other times, it confirms timing-based throttling.
Rate limits are not faults — they’re a control mechanism. Gmail’s system applies them during spikes to prevent abuse, not to reject valid mail.

Once confirmed, the fix is about pacing: reduce send volume per minute, use a warming strategy if you're new, or rotate IPs if you're sending at scale. You can test your new approach with inbox placement tools to validate delivery before scaling. For teams managing large lists, a bulk verification process can help avoid sending to addresses that trigger spam-like patterns, reducing the risk of rate limits. The key is visibility — knowing what’s happening before it disrupts deliverability.

Common causes of 421 4.7.28 when sending to Gmail

When Gmail returns a 421 4.7.28 error, it means your IP address has been temporarily rate-limited due to sending too many messages too quickly, often triggered by poor list hygiene, aggressive sending patterns, or weak sender reputation. This is not a permanent block—it’s Gmail’s way of throttling behavior that resembles spam.

Sending too fast without warming up your IP

You’re likely hitting this error if you’re sending large volumes of email right after setting up a new IP address or switching to a shared server. Gmail actively monitors sending patterns, and sending hundreds of emails in minutes without gradual ramp-up can trigger rate limiting. Sending too fast signals automated behavior, even if it’s not malicious.

Let’s say you send 5,000 emails in under 10 minutes from a new IP. Gmail may block or throttle that burst, especially if earlier messages show low engagement or high bounce rates. This is common when skipping IP warming entirely. The recommended approach is to start with small batches and gradually increase volume over several days, allowing Gmail to assess your sending behavior.

High number of invalid or outdated email addresses

Even a single bad address in a large list can disrupt delivery. A list with 20% invalid or outdated addresses increases your bounce rate, which Gmail monitors closely. High bounces signal low list hygiene, which affects your sender reputation over time.

For example, if a sender emails a list where 1 in 5 addresses bounces, Gmail may interpret this as a sign of outdated or purchased lists—common spammer behavior. This leads to stricter filtering and temporary rate limits like 421 4.7.28. Verifying your list before sending can eliminate this. MailTester’s bulk verification identifies invalid, disposable, and catch-all addresses before they hit Gmail’s filters.

Shared IPs and reputation segmentation issues

With shared IP pools, your sending behavior shares space with others. If someone else on the same IP sends spammy content or has poor list quality, your reputation—despite clean behavior—can still get throttled.

Gmail doesn’t care who sent what on a shared IP; it only sees the aggregate behavior. Without sender reputation segmentation, you’re at the mercy of others’ actions. This is why dedicated IPs (or verified shared IPs with sender-specific metrics) perform better. Using tools like MailTester’s inbox placement testing helps evaluate how well your messages land, especially in Gmail and Hotmail inboxes.

Poor engagement and spam feedback loops

If past emails to Gmail users consistently show low open rates, no clicks, or end up in spam folders, Gmail reduces trust in your messages. High numbers of spam reports—even if you didn’t send spam—can trigger rate limits.

Engagement is one of Gmail’s top signals. For example, if 90% of your messages go unread, Gmail considers your content irrelevant. Over time, this erodes reputation and increases throttling risks. Real-time verification helps reduce such risks by filtering out addresses that won’t engage or will report spam.

Step-by-step: Fix and prevent Gmail 421 4.7.28 rate limiting

You’re hitting Gmail’s 421 4.7.28 rate limit when your sending IP exceeds Gmail’s per-timeframe sending thresholds. To fix and prevent it, first confirm your IP isn’t over the limit with real-time SMTP testing. Then reduce batch size, warm up new IPs, clean your list, verify your authentication setup, and keep bounces and spam complaints under 0.1%. These steps directly reduce the chance of rate limiting and rebuild sender reputation.

1. Confirm your sending IP’s rate limits with real-time SMTP testing

Let’s start with the root issue: you can’t fix something you can’t see. Use MailTester’s real-time verification API to test your sending IP’s behavior against Gmail’s servers before sending. This checks if your IP is within accepted rate limits—something basic tools won’t tell you.

API testing simulates actual delivery attempts using standard SMTP protocols. It surfaces issues like throttling or delays before they hit your audience. Try the API to validate your setup and avoid surprise bounces.

2. Reduce batch size and pace out sends

If you just sent 100,000 emails in 30 minutes, that’s the most likely cause. Gmail’s rate limits are strict—especially on new or high-volume IPs. Break large sends into smaller batches (e.g., 500–1,000 emails per hour).

Spreading sends over time helps you avoid triggering automated throttling. It’s an industry-standard practice for volume senders. RFC 6650 outlines best practices for email sending frequency and volume pacing.

3. Clean your list before sending

Role addresses (e.g., sales@, admin@), disposable addresses, and invalid emails get rejected and increase bounce rates. These hurt deliverability and can trigger rate limits.

Use MailTester’s bulk verification to remove invalid, risky, and disposable addresses before sending. It flags catch-all domains and role accounts with high accuracy. Clean your list now.

4. Warm up new IPs gradually

New IPs face aggressive scrutiny. Sending full volume on day one invites rate limits. Instead, start small—send 100–500 emails per day, gradually increasing over 7–14 days.

Monitor engagement and feedback. This builds trust with mailbox providers. It’s not optional for new IPs, especially with Gmail.

5. Validate SPF, DKIM, and DMARC

Missing or misconfigured authentication breaks sender reputation. Even if your IP isn’t rate-limited, poorly authenticated messages often end up in spam or get blocked.

Double-check your DNS records. SPF should list only authorized IPs. DKIM must sign messages. DMARC enables monitoring. Use tools like MxToolbox to verify.

6. Monitor bounce and complaint rates

Keep hard bounces under 0.1%. Spam complaints should be below 0.1% too. Both are direct indicators of sender health.

If either exceeds 0.1% over a 30-day period, Gmail may throttle or block your IP. Set up monitoring. MailTester’s inbox placement tests help you verify actual inbox delivery post-send. Test delivery in real mailboxes.

Rate limiting isn’t a bug—it’s a defense. Fix it by respecting limits, not bypassing them.

Use Email Verification to prevent 421 4.7.28 before it happens

You can prevent Gmail’s 421 4.7.28 “IP temporarily rate limited” error by cleaning your email list before sending. Invalid addresses trigger hard bounces, which hurt your sender reputation and increase the chance of IP rate limiting. Running your list through a tool like MailTester’s bulk verification catches these issues early, reducing bounce rates and protecting your IP address health. This proactive step is far more effective than reacting to delivery failures after they happen.

Invalid addresses poison sender reputation

Every time your server sends to an invalid email address, you risk a hard bounce. These bounces aren’t just about failed deliveries—they tell receiving servers that your outbound traffic includes low-quality or outdated data. High bounce rates correlate directly with poor sender reputation. ISPs like Gmail monitor this behavior closely, and consistent bouncing can lead to temporary rate limiting, even if your content is otherwise valid.

MailTester’s bulk verification scans your list for invalid, catch-all, and risky addresses before you send. It checks real-time DNS records, SMTP responses, and domain policies to identify issues that might otherwise go unnoticed. The result is a list that’s more accurate and easier to deliver to.

Keep your IP healthy with 98.9% accuracy

MailTester’s bulk list verification achieves 98.9% accuracy by cross-checking against real-time data from mail servers and domain configurations. This isn’t a theoretical score—it’s based on repeated validation across millions of addresses. Cleaning your list with this level of precision means you’re sending fewer messages to invalid destinations, which keeps your bounce rate low and maintains strong IP reputation.

With an average bounce rate of under 1% across verified lists, you’re far less likely to trigger Gmail’s rate-limiting systems. You’re not just avoiding bounces—you’re building a sustainable sending posture. As the Google Safe Browsing API documentation notes, sending behavior is a key factor in email delivery decisions.

Integrating MailTester with your existing tools—like Mailchimp, SendGrid, or HubSpot—automates verification. You can verify lists before campaigns run, or embed real-time checks into your sign-up flows. Use the integration dashboard to connect your platform securely, then run clean, trusted campaigns with confidence.

How often does 421 4.7.28 occur in real-world email sending?

The 421 4.7.28 error—indicating a temporary IP rate limit—is a frequent issue during high-volume sending, especially when domains aren’t properly onboarded or sender reputation isn’t managed. It commonly surfaces during list-hygiene failures, peak sending windows, or sudden traffic spikes, even for established senders.

It’s not rare—especially when reputation or infrastructure isn’t tuned

You'll see 421 4.7.28 most often when sending from a shared IP, a newly established domain, or a list that hasn’t been scrubbed. If your list contains invalid, dormant, or role-based addresses, volume spikes trigger Gmail’s rate-limiting defenses, even if your content is clean. It’s not a sign of spam—it's a sign your sending infrastructure isn’t balanced.

Even large senders experience this during unplanned surges—like a flash campaign or a product launch rollout. Gmail uses behavioral signals, not just content, to decide when to throttle volume. If your sending pattern suddenly jumps beyond typical baselines, Gmail can react with a 421 4.7.28 response as a protective measure.

Why shared IPs and unverified lists increase risk

Organizations using shared email infrastructure are especially vulnerable. When one sender on a shared IP hits a Gmail rate threshold, all senders on that IP can be throttled—sometimes for hours. This affects not just the offender but others with clean sendership. A single poorly maintained list can impact your delivery.

Let’s be clear: 421 4.7.28 is a rate-limiting signal, not a block. But repeated occurrences harm your domain’s reputation over time. The longer you send to invalid or inactive addresses, the more Gmail trusts your behavior, and the more likely it is to throttle your traffic.

Prevention starts with list hygiene. Run verification checks before every send. Use tools like MailTester's bulk verification to catch non-existent, catch-all, and role-based emails before they hit your server. This reduces bounce risk and maintains consistent sending patterns.

Gmail’s rate-limiting behavior is documented in RFC 6521, which defines SMTP reply codes for delivery delays. The 421 4.7.28 code specifically refers to temporary rate-limiting due to policy enforcement. It’s not a hard bounce—it’s a grace period, but one that erodes your delivery window if ignored. Fixing it isn’t about tricks; it’s about sending intelligently with verified addresses and stable volume.

Can you fix 421 4.7.28 by contacting Gmail directly?

You cannot fix a 421 4.7.28 error by contacting Gmail support. The error is a rate limit imposed by Gmail’s infrastructure when your sending IP exceeds its allowed message volume over a short period. Gmail does not offer human support for SMTP-level delivery issues like this. The block resolves automatically once the rate limit window passes—typically within minutes to a few hours.

Why direct contact doesn’t work

  • Gmail’s automated infrastructure doesn’t route SMTP errors to human support teams.
  • There is no public ticketing system or escalation path for temporary delivery blocks like 421 4.7.28.
  • Attempts to reach out via general support channels or Google Cloud Console will not resolve the issue.

What you can actually do

  • Wait out the delay. The error is temporary. Most rate limit windows last 10–60 minutes, depending on volume and history.
  • Check your sending volume against Gmail’s thresholds. Sending more than ~3,000 emails per hour from a single IP often triggers rate limits.
  • Use bulk email verification to remove invalid or risky addresses before sending to reduce the risk of hitting rate limits.
  • Implement rate-limited sending—space out messages over time instead of sending in bursts. This is a core deliverability best practice.
  • Monitor your sender reputation. A poor sender history increases the likelihood of temporary blocks even at moderate volumes.
  • Check your IP against blocklists using tools like MxToolbox or Spamhaus for unintended blacklisting.
  • Use a dedicated IP for high-volume campaigns, and maintain a clean sending track record to reduce the chance of hitting rate limits.
Proactive list hygiene and responsible sending are the only reliable defenses against rate-limit errors. You can’t negotiate with the algorithm—only adapt.

Tools like real-time email verification help you avoid sending to invalid or risky addresses. Inbox placement testing gives you a live signal of your message’s delivery path—before you send it to your full list.

Why 421 4.7.28 is worse than a simple bounce

Unlike a standard bounce, which indicates a single failed delivery, Gmail’s 421 4.7.28 error means your IP address is being temporarily throttled due to excessive message volume. This isn’t just a one-off failure—it’s a system-level rate enforcement that can hurt your sender reputation, reduce inbox placement, and delay delivery for all messages from that IP until your sending behavior normalizes.

It’s not just a bounce— it’s a behavior signal

When Gmail returns 421 4.7.28, it’s not judging the message. It’s judging your sending pattern. If your IP exceeds volume thresholds or sends too many messages too quickly, Gmail applies throttling as a protective measure. This doesn’t just block a few emails—it signals to Google’s systems that your sending behavior is suspicious.

According to industry data from Return Path and the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), inconsistent sending patterns and volume spikes are among the top drivers of inbox placement drops, even if no messages are flagged as spam. A single 421 4.7.28 failure can be the start of a longer-term reputation issue.

How to recover and prevent reoccurrence

Recovery isn’t instant. Gmail may throttle all outgoing mail from that IP for hours—sometimes longer—until your sending behavior aligns with expected norms. There’s no manual override. The system resets when your volume stabilizes and your engagement metrics improve.

Let’s be clear: this isn’t a problem with individual email addresses. It’s a problem with how your entire IP behaves over time. If you're sending at scale, you need to monitor sending volume, spacing, and engagement. Tools like inbox placement testing can confirm whether your messages are actually reaching the inbox or being delayed by rate limits.

Proactive verification helps avoid this entirely. Before you send, use bulk email verification to remove invalid, catch-all, and disposable addresses. These are often linked to high bounce rates and poor engagement—key ingredients in triggering throttling. You can also integrate real-time verification into your sending workflow to stop bad addresses at the source.

For teams using third-party platforms like Mailchimp or SendGrid, check your MailTester integrations to test deliverability with real Gmail inboxes. You’ll know whether your current sending patterns will trigger rate limits—before they do.

How MailTester’s real-time API can monitor your send health

You can catch risky or invalid emails before they hit your SMTP server, test deliverability in real Outlook, Gmail, and Yahoo inboxes before launch, and detect early signs of rate limiting by running inbox placement tests—using MailTester’s API to audit your list regularly, ensuring low bounce rates and a clean sender reputation. Let’s break down how.

Pre-send verification with real-time API

  • Integrate MailTester’s real-time verification API into your workflow to flag invalid, risky, or catch-all addresses before sending.
  • Validate every email against SMTP, DNS, and domain reputation checks—no guesswork, no reliance on outdated list data.
  • Use the API to automatically reject or flag emails that return a 421 4.7.28 error or similar rate-limiting response, helping you avoid IP reputation damage.

Deliverability testing and inbox placement monitoring

  • Run inbox placement tests across Gmail, Outlook, and Yahoo using real user inboxes—no simulations, no proxies—to see how your campaigns land.
  • Test your message content and sender profile before launch to spot issues that could trigger temporary rate limits or spam filters.
  • Monitor deliverability over time with periodic audits—early signs of rate limiting, like increased bounce rates or delayed delivery, surface before they impact your campaigns.
  • Combine API checks with inbox testing to validate both delivery and placement, especially for time-sensitive or high-volume sends.

Rate limiting isn’t always a sign of spam—it can be triggered by volume, reputation, or technical misconfigurations. The key is spotting it early. Tools like MailTester help you distinguish between transient issues and deeper send health problems through consistent, real-world testing.

Industry standards like the RFC 6523 define how MTAs communicate rate limits; understanding them helps you design systems that self-adjust. Gmail’s 421 4.7.28 response is a direct signal: your sending behavior is too aggressive relative to their policies.

Use the bulk verification feature to clean large lists, then maintain health with automated API calls. Keep your bounce rate under 0.5%—a benchmark often cited by ESPs like Google and Microsoft—as a baseline for good sending practices.

With MailTester, you’re not just checking if an email exists—you’re validating the entire send chain, from address health to final inbox delivery.

Maintain inbox placement and reduce future 421 4.7.28 risk

IP rate limiting in Gmail often results from sudden spikes in sending volume or poor list hygiene. Consistent sending patterns reduce the likelihood of triggering throttling.

Key practices to avoid 421 4.7.28 errors

  • Verify your email list regularly using a tool with 98.9% accuracy, like MailTester, to remove invalid and risky addresses.
  • Monitor your sender reputation through third-party services such as SenderScore or Postmark to catch early warning signs.
  • For large-volume campaigns, use dedicated IPs and follow a proper warm-up process over 2–4 weeks to build trust with receiving servers.

These steps together reduce bounce rates, improve inbox placement, and help maintain long-term deliverability without relying on reactive fixes.

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 421 4.7.28 mean in Gmail SMTP replies?

It means your sending IP has exceeded Gmail’s temporary rate limit for mail volume in a short time. The message is rejected temporarily, not permanently.

How long does the 421 4.7.28 rate limit last?

Typically minutes to a few hours, depending on the volume and rate of subsequent sends. It resets after the IP’s sending rate falls within Gmail’s thresholds.

Can a shared IP cause 421 4.7.28 more easily?

Yes. Shared IPs are vulnerable to other senders’ high-volume or poor-list practices, increasing the chance of rate limiting for everyone on the pool.

How do I know if my list is causing 421 4.7.28 errors?

If you see recurring 421 4.7.28 errors right after sending large batches, your list likely includes outdated or invalid addresses. Verify it first.

Is MailTester compatible with SendGrid and Mailchimp?

Yes. MailTester integrates with SendGrid, Mailchimp, HubSpot, and Klaviyo to automate list verification before sending.

What’s the most effective way to stop 421 4.7.28 errors?

Clean your list before sending using a 98.9% accurate email verification tool and send in controlled volumes over time.

Can I test inbox placement before sending?

Yes. MailTester’s inbox placement testing checks how your emails land in real inboxes across Gmail, Yahoo, and Outlook before you send.

Do purchased verification credits expire in MailTester?

No. Once you buy credits, they never expire. You get 100 free verifications to start with.

How accurate is MailTester’s email verification?

MailTester achieves 98.9% accuracy in identifying valid, invalid, catch-all, and risky email addresses.

Why are role addresses bad for deliverability?

Role addresses (e.g. sales@, info@) often have high bounce rates and poor engagement. Sending to them can signal poor list hygiene to Gmail.

Should I warm up a new IP before sending?

Yes. Warm up by sending small volumes to engaged users over 7–14 days to build sender reputation and avoid rate limits.

How does a catch-all address affect 421 4.7.28?

Catch-all addresses accept all emails, so they appear valid but don’t represent real users. Sending to them increases bounce risk and undermines reputation.