What 421 Service not available Means
421 is a transient negative completion reply. The receiving server is telling you it cannot process the transaction at this moment and is closing the channel. Per RFC 5321 §4.2, your sending mail server should retry later with backoff — usually 15 minutes, then exponential.
Almost every receiving SMTP implementation. Postfix, Exim, Microsoft Exchange, Google's Gmail-bound MX, and most enterprise gateways return 421 for transient capacity or rate-limit conditions. The text after the code (e.g. 'try again later', 'too many connections') is where the real cause lives.
Common triggers: the receiving server is overloaded; you opened too many concurrent connections from one IP; you've hit a per-IP rate ceiling; your IP has a soft reputation flag the gateway is using to slow you down; or scheduled maintenance is closing connections.
How to Fix 421 Service not available
- 1
Read the text after 421 — the real cause is there
421 alone is generic. The receiving server appends a human-readable reason — examples include '421 4.7.0 try again later', '421 4.4.5 server busy', '421 4.7.0 IP not in whitelist'. The reason text tells you whether to wait, throttle, or remediate.
- 2
Slow your send rate from the originating IP
If your sending platform is opening many connections in parallel, the receiving server may be capping you. Drop concurrent SMTP connections from one IP to 1-2 maximum. Most enterprise gateways start returning 421 above 5 simultaneous connections from a single sender IP.
- 3
Confirm your reverse DNS (PTR) resolves
Many large receivers issue 421 when the sending IP's PTR record doesn't resolve, or doesn't match the HELO/EHLO hostname. Use the MX Lookup tool at coldrelay.com/tools/mx-lookup and verify the PTR record on your sending IP matches the hostname your server presents at HELO.
- 4
Check IP reputation
If 421 is recurring for the same recipient domain, your IP may have entered the gateway's 'soft block' state — not blocklisted, but throttled. Check the IP against major DNSBLs at coldrelay.com/tools/blacklist-checker and check Google Postmaster Tools (if sending to Gmail) for the IP's reputation tier.
- 5
Verify SPF, DKIM, DMARC alignment
421 can be triggered by authentication failures masked behind a generic deferral. Run the Email Deliverability Test at coldrelay.com/tools/email-deliverability-test against your domain. SPF must include the actual sending IP, DKIM must validate, and DMARC must align with one of them.
Note: Authentication failures more commonly show up as 5xx codes, but some gateways soft-fail with 421 first to let the sender self-heal.
- 6
Wait and retry — but cap your retries
RFC 5321 retry guidance is exponential backoff with a 4-5 day total queue lifetime. If your messages still fail after a full retry cycle, the issue is structural (reputation, authentication, or filtering) and you need to remediate before sending more.
References
- ◇RFC 5321 §4.2.1 — Reply Code Severities
Defines 4yz as Transient Negative Completion.
- ◇RFC 3463 — Enhanced Mail System Status Codes
Defines the X.Y.Z enhanced status codes that often accompany 421.
- ◇
421 Service not available in the Cold Email Context
421 is the single most common 'we're rate-limiting you' signal in cold email. Sending platforms that pool many customers onto shared IPs (or push too many concurrent SMTP connections from one IP) routinely see 421 from Gmail and Outlook. The fix is structural: dedicated sending IPs, conservative connection concurrency, correct PTR records, and clean SPF/DKIM/DMARC. ColdRelay's infrastructure gives each customer dedicated IPs inside an isolated Azure tenant, configures reverse DNS at provisioning, and writes SPF/DKIM/DMARC automatically — eliminating the reputation and configuration causes of generic 421 deferrals.
Frequently Asked Questions
Is 421 a hard failure?
No. 421 is a transient (temporary) negative completion reply per RFC 5321. Your sending server should retry. If the underlying cause persists, however, the retries will keep failing and the message will eventually be returned to the sender after the queue lifetime expires (typically 4-5 days).
How long should I wait before retrying after 421?
RFC 5321 recommends exponential backoff starting around 15-30 minutes. Most production mail servers default to: first retry at 15 min, then 30 min, 1 hr, 2 hr, 4 hr, doubling up to a queue lifetime of 4-5 days. Most sending platforms handle this automatically.
Does 421 hurt my IP reputation?
Not directly. 421 itself is not a reputation event. However, the underlying cause of repeated 421s (high concurrency, poor PTR, soft-blocked IP) often correlates with low reputation. If you see 421 repeatedly to one recipient domain, treat it as a yellow flag and remediate before scaling sends.
Why am I getting 421 from Gmail specifically?
Gmail returns 421 4.7.0 or 421 4.7.28 most commonly when the sending IP has flagged reputation, when you've exceeded their per-IP rate limit, or when the IP lacks a valid PTR record matching HELO. Check Google Postmaster Tools for the IP's tier — anything below 'High' triggers throttling.
Can SPF/DKIM/DMARC misconfiguration cause 421?
Yes, indirectly. Some receivers issue 421 as a soft-fail when authentication results are inconsistent (e.g. SPF passes but DKIM fails). The intent is to give the sender a chance to self-heal before a hard rejection. Always run the Email Deliverability Test against your domain to confirm all three records pass.