A 421 or 4.7.0 reply is a receiving server saying "not now". It is not a rejection and it is not a verdict on your message. It is a temporary failure: the server closed the conversation, or refused the message for the moment, and expects you to try again later. Large mailbox providers use it all the time as a pressure valve. They may be handling too much traffic from your IP address, they may not yet trust a new sender, they may have seen complaints about your recent mail, or they may simply be busy. The danger is in how you react. A sender that retries every few seconds, or that opens dozens of parallel connections to "push it through", turns a mild throttle into a block. This guide explains what the codes mean, how to read the text that comes with them, how to tell an innocent throttle from a reputation problem, how to set retries and rate limits that keep you safe, and what to do when the deferrals do not clear.
What the codes mean
SMTP replies that start with 4 mean "transient failure". Within them, 421 is defined as the service being unavailable and the connection closing; servers use it for overload, for too many simultaneous connections from one address and for policy deferrals at the start of a session. The related 450, 451 and 452 replies are sent in answer to a command, and say that the requested action was not taken for a temporary reason. The enhanced codes add detail. A 4.7.x code is in the "security or policy" group: the failure is temporary, and it relates to a policy decision about you, not to a missing mailbox or a full disk. 4.7.0 is the generic form; providers add their own text and sub-codes. Our guide to SMTP reply codes and the article on queued and deferred email cover the basics.
How the big providers phrase it
The text after the code is where the explanation is. These are typical shapes, not exact quotations, so always read the message you actually received.
| Provider | Typical shape of the message | What it usually indicates |
|---|---|---|
| Gmail | 421-4.7.28 or 421 4.7.0 with text about an unusual rate of mail, or about low reputation, and a link to Google's guidance | Volume from your IP or domain is above what Gmail trusts for its reputation, or recent mail looks unsolicited |
| Yahoo and AOL | 421 4.7.0 with a code such as TSS04 and text about messages being temporarily deferred due to unexpected volume or user complaints | Throttling because of sudden volume or complaints; a link to the sender help pages is usually included |
| Microsoft (Outlook.com, Hotmail, Microsoft 365) | 451 4.7.650 or 421 RP-001 style replies, with text about too many messages or a poor reputation | Rate limiting by IP or domain; Microsoft documents its codes in its mail flow pages |
| Small or self-hosted servers | 421 4.7.0 Too many connections or 450 4.7.1 Greylisted | A connection limit, or greylisting, which clears on a retry after a delay |
Gmail and Yahoo also publish sender requirements, including authentication, a low spam complaint rate and one-click unsubscribe for bulk mail. Deferrals are often the first visible sign that you do not meet them. Read the Gmail and Yahoo bulk sender requirements and compare them with your setup.
Is it a throttle or a reputation problem?
The two look the same in a log, but they need different responses. Look for these signs.
- It started with a spike. If deferrals began when you sent a large campaign, imported a new list or started sending from a new IP address or domain, this is a volume throttle. Reduce the speed and it should clear. See the warm-up guide.
- It affects one provider only. One provider reacting is typical of provider-specific limits. If every provider defers you at the same time, look at your own server, DNS or network.
- It comes with complaint or content signals. Text that mentions complaints, "unsolicited" mail or reputation suggests the problem is the quality of your mail, not only the rate.
- It clears after a few hours and returns. That points to a rate limit that you keep exceeding. A steady cap, with a slower ramp, is the fix.
- It persists for days and spreads to rejections. The provider has formed a negative view of your sending. Move to the recovery steps below and check Google Postmaster Tools, the complaint-rate data and the blocklists.
What to do right now
Resist the urge to retry harder. The right response is to behave like a polite sender. First, stop opening more connections. Reduce the number of simultaneous connections to the affected provider, and lower the messages-per-connection and the overall rate. Second, let your mail system retry on its own schedule. A sensible schedule increases the gap after every failure, for example a few minutes, then ten, then thirty, then hours, up to several days. Third, make sure retries for the affected provider are queued separately, so that one provider's slowdown does not delay the rest of your mail. If you operate your own MTA, these controls are called per-domain concurrency, rate and retry settings; if you use a service, the platform applies them for you, and your job is to avoid sending more than your reputation supports. The article on rate limits, retries and backoff shows a robust pattern.
Change what you send, not only how fast
If the deferrals mention complaints or unsolicited mail, slowing down is not enough. Look at the audience and the content. Send first to the most engaged recipients, those who opened or clicked in the last 30 to 90 days. Pause mail to older, cold or purchased segments. Check that every message includes a working unsubscribe link and a clear reason the person is receiving it. Fix any address whose sign-up you cannot document. Compare complaint rates by campaign to find the one that caused the problem. A complaint rate that approaches the levels mailbox providers publish as limits needs action immediately, as described in complaint rates and feedback loops.
Check authentication and infrastructure
Many deferrals trace back to basics. Check that the sending domain has valid SPF, that DKIM signs the message and that DMARC is published and aligned; see authenticating your sending domain. Check that the sending IP has reverse DNS that matches its forward name (see reverse DNS and PTR records), and that the name in the SMTP greeting is a real hostname. Make sure TLS works; the troubleshooting guide for connection and TLS errors helps if the problem is in the handshake. Finally, check that the IP is not on a blocklist with the steps in checking blocklists.
A safe recovery plan
- Pause non-critical bulk mail to the deferring provider for several hours and keep transactional mail flowing at a low rate.
- Reduce concurrency and rate for that provider to roughly a quarter of what you were sending.
- Confirm that authentication passes and that the complaint rate in your data is low.
- Resume gradually: increase the volume in steps, only when the previous step had no deferrals, and watch the logs after each increase.
- Send to engaged recipients first and hold back cold segments until the reputation has recovered.
- Record what happened and what fixed it, so that the next campaign starts with the right limits.
If transactional mail, such as password resets, shares an IP address or a domain with campaign traffic, a campaign throttle can delay it. Separating the streams avoids that; see separating transactional and marketing email streams.
When to contact the provider
If deferrals continue for more than a few days after you have slowed down, authenticated your mail and cleaned your audience, use the sender support form linked in the error text or on the provider's postmaster pages. Include the sending IP addresses, the domain, example message identifiers, the exact error text with timestamps and a short description of what you changed. Do not ask them to "whitelist" you; ask what they see and what they recommend. Replies can take days, so keep your volume low in the meantime.
Throttle-aware sending, built in Per-provider rate control, automatic backoff and delivery logs that show every deferral.
References and further reading
Frequently asked questions
What does SMTP 421 4.7.0 mean?
A temporary failure with a policy reason. The receiving server is deferring your mail, often because of volume, complaints or low reputation, and expects a retry later.
Should I keep retrying a 421 deferral?
Retry, but with growing delays and lower concurrency. Rapid retries and extra connections make deferrals worse.
How long do 4.7.x deferrals last?
A simple rate limit may clear in hours once you slow down. A reputation-related deferral can take days and needs changes to your audience and content.
Is a deferral the same as a bounce?
No. A deferral is temporary and the message stays in the queue. If it is still failing at the end of the retry period, the message is returned as a bounce.
How do I avoid 421 deferrals when sending campaigns?
Warm up new IPs and domains, ramp volume gradually, authenticate your mail, send to engaged recipients first and keep complaint rates low.