Gmail 421 4.7.28 on a new sending domain: variants and how to ramp
Gmail's 421 4.7.28 is a temporary throttle, not a block: it saw an unusual rate from your IP, DKIM, SPF or link domain. Read which one, then ramp volume slowly.
On this page(8 sections)
If Gmail answers with 421 4.7.28, it did not refuse your message. It asked your server to come back later because it saw an unusual rate of mail tied to something you control. On a brand-new domain that usually means you sent too much, too fast, before Gmail had any history to judge you by.
The useful part of the error is the sentence after the code. It names what Gmail is rate limiting, and that tells you where to look first.
What does 421 4.7.28 mean?
A 421 reply is a temporary failure: in SMTP, the 4xx class means "try again later" and the 5xx class means "stop". Google lists several 421 4.7.28 messages in its Gmail SMTP errors and codes table, and for all of them it points you to its email sender guidelines. A correctly configured sending server queues the message and retries. The related 550 5.7.28 is the permanent version for an IP address, so a 421 that turns into a 550 means the situation got worse, not that it settled.
Which variant did you get?
Read the full text of the bounce or deferral log line. Google's table lists these wordings, which map to different parts of your setup:
| Gmail says it detected an unusual rate (or quota) for... | What it points at | First thing to check |
|---|---|---|
| your IP address, or IP netblock | The sending IP or its neighbors | Did you move to a new provider or dedicated IP recently? |
| your DKIM domain | The domain in your DKIM d= tag |
Is a new signing domain sending volume with no history? |
| your SPF domain | The domain in the envelope sender (Return-Path) | Is a new bounce domain carrying your first big send? |
| one of your URL domains | A domain linked in the message body | Is a new tracking or link domain in the template? |
| the same Message-ID | Many messages sharing one Message-ID | Is a bug or a loop stamping identical IDs? |
The plain "unusual rate of email" message is the general form, and the Message-ID row is a quota message rather than a rate message. Gmail's own table gives no remediation beyond the sender guidelines, so what follows is working practice, not an official rule.
Why does a new domain trigger it?
A new domain has no sending history, so every volume level looks like a spike. Google's guidance asks you to "start with a low sending volume to engaged users, and slowly increase the volume over time" and to avoid sudden spikes if you have no history of sending large volumes. A launch email to your whole list from a domain registered last week is exactly that spike.
Changing infrastructure can recreate the problem on an old domain. A new email provider, a new DKIM signing domain, a new return-path domain or a new link-tracking domain each present Gmail with an identity it has not seen send at scale. If you changed several at once, you cannot tell which one Gmail is reacting to, which is why the variant in the message matters.
Our post on warming up a brand-new sending domain covers the longer plan, and domain versus IP reputation explains why the DKIM and SPF variants exist at all: Gmail tracks reputation per domain, not only per IP.
What should you do in the first hour?
- Do not hammer retries. Let your mail server's normal queue schedule do the retrying. Forcing the same volume again can turn a throttle into a block.
- Read the exact variant from the SMTP log and note which domain or IP it names.
- Cut the volume to Gmail recipients for now, not to zero. Keep sending the most expected mail, such as password resets, at a trickle.
- Check authentication. SPF and DKIM must pass and align with your From domain. Google requires SPF or DKIM for all senders, and SPF, DKIM and DMARC for senders above 5,000 messages a day to Gmail.
- Look at the content. One new link domain in a big template is a common culprit for the URL variant.
- Check Postmaster Tools if you have enough volume for data, and keep the spam rate under 0.30%, ideally under 0.10%, per Google's guidance. Our spam rate post explains the thresholds.
How do you ramp after a 421 4.7.28?
Resume in stages and only move up when the previous stage deferred nothing. There is no official schedule, so treat this as an example to adapt, not a promise:
| Stage | Who gets mail | Move on when |
|---|---|---|
| 1 | Your most engaged Gmail recipients, small batch | No 421s and near-zero complaints |
| 2 | Recent openers and clickers, double the batch | Same, for a few days |
| 3 | The rest of the active list in steady chunks | Same, with no bursts |
| 4 | Full volume at a steady rate, not a single blast | Ongoing |
Send at a steady pace, not in bursts, and from one consistent set of identities. Keep the From domain and DKIM domain stable while you ramp, and avoid launching a new link domain in the same week. If the deferrals persist for days despite a low, clean volume, Google provides a contact form for bulk senders.
What if Yahoo or Outlook say something similar?
Other providers use their own codes. Yahoo's deferrals are covered in our TSS04 guide, and the sender rules for Gmail and Yahoo are compared in the bulk sender requirements post.
A note on Koltrix
Koltrix signs each domain with its own 2048-bit DKIM key, so a new domain also gets its own DKIM identity. That is good for isolation, and it also means a new domain starts with no Gmail history of its own. Plan its first sends like any new domain: small, engaged and steady.
Bottom line
421 4.7.28 is Gmail slowing you down, not shutting you out. Read which identity it names (IP, DKIM domain, SPF domain, link domain or Message-ID), cut and then slowly raise your volume to engaged recipients, and keep your authentication and identities stable while Gmail learns who you are. The official sources cover the code and the general ramp-up advice; the staged schedule is practice, so measure it against your own deferral logs.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
