421 4.7.0 Try again later, closing connection. (EHLO)
421 4.7.0 [TSS04] Messages from [IP] temporarily deferred due to unexpected volume or user complaints
421 4.3.2 The maximum number of concurrent connections has exceeded a limit, closing transmission channel
421 Service not available, closing transmission channel
A 421 gives your message four to five days of retries before anything counts as failed, and that window comes from RFC 5321 itself. The exact pacing inside that window (how soon the first retry fires, how often it tries again) is left to whatever sent the message, and that single detail actually determines what happens next.
A real mail queue, whether that is Google Workspace, Microsoft 365, or your own server, keeps trying on a schedule.
A script, plugin, or CRM sending straight over SMTP often does not. No built in queue means no automatic second try. Read the bounce text below before you touch any settings: it tells you which side issued the 421, and that answer changes everything else on this page.
Find your situation first
What the bounce or log shows | What it means | Read this |
|---|---|---|
The responding host is | Your own relay refused the connection before it ever reached the recipient | Your Google Workspace or Gmail relay refused you, or Your Microsoft 365 relay refused you |
Your app, plugin, or CRM logged the 421 once and nothing since | Nothing is queued behind it, so it will not retry on its own | An app, script, plugin, or CRM sent it, with no queue behind it |
The bounce names the recipient's domain or a provider like Yahoo, and mentions volume, complaints, reputation, or connections | The recipient's own server issued the deferral | The recipient's server issued it, and nothing you configure fixes it right away |
You have a delay notice ("will be retried for N more days") instead of a final failure | It is not a bounce yet, it is a status update from your own queue | Read the bounce before you decide it failed |
None of the above, or you are already past four to five days with no change | The normal retry window has run out | Escalate it |
The responding host name is the fastest way to tell which row applies, and Gmail's own message view shows it in full.
The Received line names the exact server that issued the 421, which is the single detail the table above depends on.
Your Google Workspace or Gmail relay refused you
The EHLO hostname was rejected
Gmail's SMTP relay service will close the connection at the EHLO step itself, before authentication, and hand back 421 4.7.0 Try again later, closing connection. (EHLO).
Developers hit this most often through Docker containers, serverless functions, or local test environments, where the mail library announces itself with localhost, 127.0.0.1, or another private address instead of a real hostname.
One reporter on the Nodemailer project traced an intermittent version of exactly this failure back to the relay closing the session at EHLO with no further detail from Google's side.
It is a config problem, not a reputation problem.
Set the client hostname (the name option in most SMTP libraries) to a real, resolvable domain you control, then retry.
Gmail's own rate limit deferral
A separate 421 4.7.28 from the same relay means Gmail's own sending caps kicked in, not a hostname problem, and it hides behind Gmail's generic "message blocked" notice on the recipient's side.
That variant already has its own breakdown in what actually sits behind Gmail's blocked message notice, including the daily volume tiers, so it is not repeated here.
Your Microsoft 365 relay refused you
Exchange Online's authenticated SMTP submission allows up to three concurrent connections and thirty messages per minute per account.
Push past either ceiling, and Microsoft throttles the session.
The connection limit specifically returns its own error rather than a generic 421, but the practical fix is the same either way: cut the number of simultaneous SMTP sessions your app opens, or space out sends instead of firing them in a burst, and confirm the account is not also trying to send through a second app at the same time.
An app, script, plugin, or CRM sent it, with no queue behind it
This is the gap almost nothing on the topic covers, and it is the one that actually matters for most people who search this error.
A real mail transfer agent treats a 421 as routine: it holds the message and tries again on a schedule, giving up only after RFC 5321's four to five day window closes.
A script that opens an SMTP connection, sends one message, and exits does not do that unless someone wrote a retry loop for it.
How to tell if anything is actually queued
Check your own sending code or integration logs for a second attempt after the first 421. If there is none, the message is not "on its way eventually."
It is sitting wherever your code left it, and resending it manually is the only thing that will move it.
The recipient's server issued it, and nothing you configure fixes it right away
Yahoo's volume and complaint deferral
Yahoo's 421 4.7.0 [TSS04] deferral fires when a sending IP crosses Yahoo's own thresholds for volume or spam complaints in a short window.
No setting on your side clears it faster than Yahoo's own throttle resets.
Slowing your send rate to that domain and waiting it out is the actual fix, not resending faster.
A generic "service not available" or connection limit deferral
A bare 421 Service not available or a connection count error (Microsoft's Exchange Online Protection returns its own version when a resource forest is receiving too many simultaneous sessions) means the receiving side is temporarily full or under load.
Sending less at once, not more, is what clears it.
Read the bounce before you decide it failed
Most inboxes never show a hard failure for a 421. They show a delay notice, something like "will be retried for 4 more day(s)," sitting inside the same thread as the original message.
That notice is not a bounce. It is your own queue telling you it is still trying, on the schedule below.
Attempt | Typical timing | What it tells you |
|---|---|---|
First retry | Minutes to roughly 30 minutes after the 421 | Normal, RFC 5321 does not fix this number, senders choose it |
Following retries | Every few hours, tapering to once or twice a day | Still inside the RFC 5321 window |
Final attempt | Four to five days after the first try | RFC 5321's outer bound, a real bounce follows only after this |
RFC 5321 sets the four to five day outer bound but leaves the exact spacing to whoever built the sending queue, and providers do not all honor it the same way.
A well known Hacker News thread from March 2022 collected reports of Yahoo giving up on a stalled connection after roughly three hours rather than days, with commenters split on whether that is a reasonable modern choice or a departure from the spec.
Not every provider waits the full window. Whatever your provider does, do not resend by hand while a delay notice is still showing.
That adds a second message to the same queue instead of speeding up the first one.
Confirm it's actually fixed
Wait for one full retry cycle (see the table above) before you judge anything. Do not test five minutes later. If the cause was your own relay (EHLO, concurrent connections), the next attempt after your fix should go through cleanly and stop generating new delay notices.
If the cause was the recipient's side (Yahoo, a generic capacity limit), a clean send some hours later, at a lower rate, is the real signal, not the absence of a new 421 right after your last try.
Escalate it
The message is still deferred past the four to five day RFC 5321 window with no delivery and no permanent bounce
You have confirmed your own hostname, connection count, and send rate are not the cause
The same 421 comes back from the same recipient domain across multiple different messages and different days
You have already slowed sending to that domain and it did not change anything after 24 hours
If all of these are true, contact your provider's support (Google Workspace, Microsoft 365, or your SMTP relay) with the exact bounce text and timestamps rather than resending again.
Support teams want the literal string, not a paraphrase.
What already closes two of these gaps
A managed sending queue retries a deferred message on schedule instead of dropping it after one failed attempt, which is the exact gap covered above for scripts, plugins and CRMs sending without one.
TrueEmailer sends from infrastructure that queues and retries automatically, with SPF, DKIM and DMARC configured at setup and the client hostname set correctly by default, the same configuration value discussed in the EHLO section above.
None of that touches a 421 that originates on the recipient's side.
Nothing sender side changes the volume or connection limits Yahoo, Microsoft or any other receiving system enforces on its own end.
Related error codes
A 421 is temporary. That single fact changes the whole retry story. A 550 is permanent, class 5, with no retry window at all, covered in 550 permanent failure for one or more recipients.
A DMARC policy failure produces its own permanent code with a completely different fix path, walked through in 554 5.7.5 permanent error evaluating DMARC policy.
FAQ
Does a 421 mean my email bounced?
Not yet. A 421 is a temporary deferral inside the class 4 status codes. Your message only counts as bounced once the retry window closes, which RFC 5321 sets at four to five days, and a real failure notice arrives separately from the delay updates.
Should I resend the email manually?
Only after you have confirmed nothing is queued to retry it automatically, which is common with scripts, plugins, and CRMs sending directly over SMTP.
If a real mail queue (Google Workspace, Microsoft 365, your own server) is already retrying, a manual resend adds a second message competing for the same send window instead of speeding anything up.
Is a 421 a sign I'm blacklisted?
Rarely by itself. A hard blocklist listing usually shows up as a 550 rejection with a named list, not a 421. A 421 more often means a rate, connection, or hostname problem on either side rather than a reputation block.
What's the difference between 421 and 550?
A 421 is temporary and class 4; the same message can still go through later. A 550 is permanent and class 5, and no amount of retrying changes the outcome.
Five causes behind a 550 5.7.1 bounce walks through the permanent side of that split in detail.
Is 421 the same as greylisting?
No, though they can look similar from the outside. Greylisting is a deliberate, short, one time delay a receiving server uses to filter spam, and a retry within minutes usually clears it for good.
A 421 can be a one off delay or a longer deferral tied to volume, connections, or a hostname problem, and it can repeat across several attempts rather than clearing after one retry.
Whose problem this actually is
Read the responding host before you change anything. Same three digit code, three different fixes. Your own relay, an app with no queue, and the recipient's server all produce identical looking bounces for entirely different reasons.
RFC 5321 gives you four to five days before a 421 turns into a real failure, and almost nothing you can do in the first hour speeds that up beyond fixing whichever of the three causes above actually applies.
Error strings and fixes verified September 16, 2026 against RFC 5321, Google Workspace Admin Help, Microsoft Learn, and live developer and community reports.