Will the deferred messages eventually arrive?

Usually yes. A reply beginning with 4 asks your server to try the same message again later, and a correctly configured sender keeps retrying on a backoff schedule for a few days before giving up and returning a failure notice. The risk is not loss, it is delay: anything time sensitive, such as a password reset or a one time code, can expire while it waits.

How long does a 421 4.7.28 rate limit last?

Google does not publish a duration, so treat it as lasting until the cause is gone rather than as a timer you can wait out. Retrying harder makes it worse. Pause the bulk sending, fix authentication and consent, then come back at a lower rate and watch the deferral count.

Does a 4.7.28 mean my domain is on a blocklist?

No. It is Gmail applying its own temporary limit to one identifier, which may be your IP address, your IP netblock, your DKIM or SPF domain, or a URL domain in the message. A public blocklist listing is a separate problem with its own symptoms and its own removal process, so check for it separately rather than assuming.

421 4.7.28 Gmail rate limit: what it means and the fix

The mail starts arriving late. Nothing bounced, nobody got a failure notice, the sent folder looks normal. Then a customer says the invoice never showed up, somebody opens the outbound queue, and there are a few hundred messages waiting, each stamped with the same line: 421-4.7.28. Gmail took the connection, looked at who was sending, and decided to accept the mail more slowly than you are handing it over.

This is the quietest deliverability failure there is. The mail is not rejected, so no alarm fires. It is deferred, so the server keeps retrying and some of it lands hours later. Reset links expire in the queue. Order confirmations arrive after the phone call asking where they are. By the time anyone treats it as a problem the pattern has been running for a week. Here is how we read these responses when a client brings us one, and the order we work in to clear them.

A 4xx is a delay, a 5xx is a decision

SMTP replies split on the first digit. A reply starting with 4 is a temporary failure: the receiving server is asking yours to try the same message again later, and a correctly configured sender keeps retrying on a backoff schedule for a few days before it gives up and returns a failure notice. A reply starting with 5 is permanent, and the message is finished. That split is defined in RFC 5321, and it is why rate limiting hides so well. Your server is behaving the way the standard asks, in silence, while the backlog grows.

A log full of 421 and 450 responses is not a block. It is a speed limit with a short note attached about why it was applied, and that note is what most people throw away before asking for help.

4.7.28 names the thing that got rate limited

Google publishes the Gmail SMTP error table in Workspace Admin Help, and 4.7.28 appears there in several forms. They share one explanation, that Gmail detected an unusual rate of unsolicited mail and temporarily rate limited it to protect users, and all point at the email sender guidelines. What changes between the variants is the identifier being named:

your sending IP address
your IP netblock, the range that address sits in, not the address alone
your DKIM domain, the domain in the signature
your SPF domain, the domain Gmail authenticated from the envelope sender
a URL domain that appears in the body of the message

Read the identifier and you have most of the diagnosis. A named IP address or netblock on a shared platform means the reputation being throttled is not only yours, and the work is to get your mail authenticated under your own domain so it is judged on its own record. A named DKIM or SPF domain is the more useful case: Gmail knows who you are and has formed an opinion about that domain. A named URL domain usually points at a link shortener or a tracking domain shared with every other customer of the platform, which is why we move clients onto a tracking domain of their own.

So the first thing we ask for is not a screenshot of the delay warning. It is the full SMTP response out of the log.

4.7.27 and 4.7.29: two deferrals with a same-day fix

421 4.7.27 says the message was rate limited because SPF authentication did not pass for it. The table prints the authentication result alongside, naming the SPF domain and the IP address that failed the check, and points to Google's SPF setup guidance. This is a configuration fault, not a reputation judgement. Something is sending as your domain from an address your SPF record does not cover, which happens when a new tool is plugged in, when a record is edited and a mechanism gets dropped, or when the record quietly stops resolving because it passed the ten DNS lookups the standard allows. That last case is the SPF too many DNS lookups problem.

421 4.7.29 says the message was rate limited because it was not sent over a TLS connection, and that Gmail requires bulk senders to use TLS for SMTP. This one comes from an appliance or an old application server: a scanner or a billing script that opens a plain connection on port 25. Note that 421 4.7.0 TLS required for RCPT domain is a different message, so match the full code and not just the 421.

450 4.2.1: when the limit belongs to the recipient

The other code that fills logs is 450 4.2.1, and the common version of it is not about you. Google's wording is that the user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered, and that the message will be delivered if the user can accept mail at that time. One mailbox is being filled faster than it is allowed to accept. Your domain is not in trouble.

The setup we look for first is an archive or blind copy of every outgoing message aimed at a single Gmail or Workspace mailbox, a pattern that turns up in CRMs, helpdesks and invoicing tools. The second is a monitoring job pointed at somebody's personal account. There is also a 450 4.2.1 variant that reads as a peak SMTP relay limit exceeded for the customer: that one is about the Workspace relay service, and it means a relay set up for occasional application mail is now carrying a campaign.

What we check first on a client domain

The full SMTP response from the mail log, several samples, to see which identifier is named and whether it is always the same.
Volume and shape: messages per hour by stream, and whether the deferrals started with a campaign, a new tool or a migration.
Authentication for every stream that uses the domain: SPF passing, and DKIM signing with a domain aligned to the From header.
Whether outbound connections are negotiating TLS, including from the devices and scripts nobody remembers.
The Postmaster Tools dashboards for the domain. Google's documentation describes what each reports: spam rate is the share of messages recipients marked as spam by hand, domain reputation is a quality rating for the domains you send from, authentication is the share of mail passing SPF, DKIM and DMARC, and compliance status measures you against the sender requirements.

If the domain sends around five thousand messages or more to Gmail accounts in a day, Google's sender guidelines FAQ treats it as a bulk sender, with the requirements in force since February 2024: authenticate outgoing mail, do not send unsolicited mail, make unsubscribing easy. The FAQ also states that a sender meeting that criterion even once is permanently considered a bulk sender, so one large send last year still counts.

Clearing a 4.7.28, in the order we work

Separate the streams first. The receipts and resets a customer is waiting for should not be queued behind a campaign. Pause the campaign, let the queue drain, confirm the important mail is moving.
Fix authentication until it is boring. Every stream that sends as the domain passes SPF, signs with DKIM, and aligns with the From domain. Until that is true, Gmail is judging a mixture of senders under one name.
Turn on TLS everywhere, including the old things. The appliance in the back office counts.
Give bulk mail its own identity. A dedicated sending subdomain keeps a campaign's reputation off the mail your business depends on, which is the setup in our guide to sending subdomains. The same goes for links: a tracking domain of your own, not one shared with every other customer of the platform.
Lower the rate and climb back slowly. Reduce concurrency and messages per hour, then increase over days while watching the deferral rate. Retrying harder against a rate limit does not get mail through faster.
Fix the reason people reported it. A rate limit for unsolicited mail is a statement about consent. Send to people who asked recently, drop addresses that have not engaged in months, and keep one click unsubscribe working.
Resume, and keep watching. Only after the first five, or you will be back in the same queue next week.

The Workspace limits that look like rate limiting and are not

Sometimes the throttle is not Gmail protecting its users, it is the sending account hitting its own ceiling. The figures below are the list values on Google's limits page, checked 15 October 2026: 2,000 messages a day per user account, 1,500 a day for mail merge, 500 a day for trial accounts; 2,000 recipients per message with at most 500 of them external; 10,000 recipients a day in total and 3,000 external recipients a day; and 100 recipients per message for mail sent over SMTP by POP and IMAP users. Google states that after a limit is reached the user cannot send new messages for up to 24 hours, that the daily figures run over a rolling 24 hour window rather than resetting at a fixed hour, and that the limits can change without notice, so verify any figure, this page included, on the day you need it.

When a business keeps bumping into these, the answer is the right tool for the volume: a group for internal distribution, the Workspace SMTP relay for application mail, a real platform for a newsletter.

What we watch for the next month

A cleared rate limit is not the end of the job, because the thing that caused it recovers slowly. For about a month we watch four numbers: the deferral rate per hour from the mail logs, so a return shows up the same day; the spam rate trend in Postmaster Tools, read over weeks rather than any single day; the authentication percentage, which exposes a forgotten sender when it dips; and domain reputation, which moves last and confirms the fix landed. If they come back on the same identifier with authentication clean and volume sane, the problem is upstream: a shared platform, or a list that was never really opt in.

How Guanacos Tech helps

We do this as part of deliverability work for small and mid-sized teams across North America and Latin America: read the real SMTP responses out of your logs, find which identifier Gmail is throttling, get every stream authenticated and aligned, split the bulk mail off the mail your business runs on, then watch the recovery with you. How we work fits on one page. If you want the queue cleared rather than researched, we offer email deliverability consulting for small business, and half an hour with your logs open is enough to say which code you have and what clearing it takes.

Gmail rate limited your mail and nothing bounced: how to read a 421 4.7.28 and clear it