421 4.7.0 — try again later

A 421 4.7.0 reply is a temporary deferral, not a bounce. The receiver has closed the connection and asked you to retry — usually because of your sending rate or your reputation. Here is why, what it costs you, and how to clear it.

Check your domain free → Jump to the fix ↓

What it means

The cause.

The leading 421 is an SMTP reply code defined in RFC 5321 as "Service not available, closing transmission channel". It is a 4xx code, which makes it transient: the server is refusing this connection right now but expects a later attempt to succeed. The 4.7.0 that follows is an enhanced status code from RFC 3463 — class 7 is "Security or Policy Status", and 4.7.0 specifically is "other or undefined security status". Read together, the receiver is saying it has declined the connection for a policy reason it is not spelling out in detail.

The "try again later, closing connection" wording is Google's. Gmail and Google Workspace emit 421 4.7.0 when they throttle a sender — typically an unusual or rising send rate, too many concurrent connections from one IP, or a sending IP whose reputation is low enough that Google rate-limits it rather than accepting the mail outright. Other receivers use 421 the same way for load, connection limits and greylisting. Because the reason is deliberately vague, 421 4.7.0 covers several underlying conditions rather than one specific misconfiguration.

This is a connection-level deferral, not an authentication result. It is not the same as spf=fail, dkim=fail or a DMARC failure reported in Authentication-Results — those describe a single message that was evaluated. A 421 is the receiver closing the door before or during the transaction, expecting your mail server to queue the message and retry with backoff.

Why it matters

The impact.

On its own a single 421 costs you nothing: a correctly configured mail server queues the message and redelivers it, and the recipient never notices. The danger is retry behaviour. If your server — or a script — reconnects immediately and hammers the receiver, Google extends the deferral and the reputation problem behind it deepens, turning a brief throttle into hours of stalled mail or an outright block.

Persistent 421 4.7.0 responses are a signal that your sending reputation or authentication is weak, and that matters more since the 2024 Gmail and Yahoo bulk-sender rules. Senders who authenticate with SPF, DKIM and aligned DMARC, keep complaint rates low and warm their volume are throttled far less. If deferrals are routine rather than occasional, the receiver is telling you it does not yet trust this IP or domain enough to accept your mail at full rate.

What to do

The fix, in order.

Work top to bottom, then re-check — DNS changes take a few minutes to take effect.

1 Let your server retry — do not loop. A 421 is a request to come back later, so honour it. Confirm your mail server or sending application queues the message and retries with exponential backoff rather than reconnecting in a tight loop. Immediate retries are the fastest way to turn a short deferral into an extended block.
2 Confirm it is not a one-off blip. Check your logs. If the 421 4.7.0 appears once and the message goes through on the next attempt, it was transient load and there is nothing to fix. Only a sustained pattern across many messages points to a reputation or rate problem worth chasing.
3 Slow your sending rate and concurrency. If the deferrals cluster, you are sending too fast for the trust the receiver has in you. Reduce the number of simultaneous connections from a single IP and spread volume out. New or newly-active IPs need to be warmed up gradually rather than sending at full volume on day one.
4 Fix the reputation signals behind the throttle. Run your domain through the email tester to confirm SPF, DKIM and DMARC pass and align, and that your sending IP has a valid PTR (reverse DNS) record — Google rate-limits senders that lack one. Clean authentication and a matching PTR are what move you off the throttled tier.
5 Keep complaints and bad addresses down. Reputation is also earned by who you send to. Prune addresses that hard-bounce, honour unsubscribes promptly, and keep spam complaints below the 0.3% threshold Gmail expects of bulk senders. Lower complaint rates mean fewer deferrals over time.
6 Re-test once your volume settles. After tightening retry logic, rate and authentication, watch the logs over a few days. The 421 4.7.0 rate should fall as the receiver rebuilds trust. If it persists on a dedicated IP with clean auth, contact the receiver's postmaster or your relay provider with the exact log lines.

Confirm the error is gone.

Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.

Check your domain → Or send a test email

Common questions

About this error.

What does 421 4.7.0 — try again later mean? It is a temporary SMTP deferral. The 421 code (RFC 5321) means the service is not available and the connection is being closed; the 4.7.0 enhanced code (RFC 3463) marks it as a security or policy reason. In practice the receiver — usually Gmail — has throttled your connection over sending rate or reputation and expects you to retry later.

How do I fix 421 4.7.0 — try again later? First make sure your server retries with backoff instead of looping. If the deferrals persist, slow your send rate and concurrency, warm new IPs gradually, and fix the reputation signals behind the throttle: valid PTR record, passing and aligned SPF, DKIM and DMARC, and low complaint and bounce rates.

Is 421 4.7.0 — try again later permanent? No. The leading 4 makes it a transient error, unlike a 5xx permanent failure. A correctly configured mail server queues the message and redelivers it automatically. It only becomes a lasting problem if you retry aggressively or ignore the reputation issue causing the repeated deferrals.

Why does Gmail keep sending 421 4.7.0? Repeated deferrals mean Google does not yet trust your IP or domain enough to accept mail at full rate. Common causes are an unwarmed IP, a missing PTR record, sending too fast, weak authentication, or a high complaint rate. Fix those and the throttling eases.

Is 421 4.7.0 an authentication failure? Not directly. It is a connection-level deferral, not an spf=fail, dkim=fail or DMARC result reported in Authentication-Results. Weak authentication can be one reason the receiver throttles you, but the 421 itself is the server closing the connection, not a verdict on a single message.

Should I retry immediately after a 421 4.7.0? No. Retrying immediately is the worst response — Google extends the deferral when a sender reconnects in a tight loop. Let your mail server wait and retry with exponential backoff, which is the behaviour the code is asking for.

Fix the cause, and check it.

Blacklist checker → Check your domain and every sending IP against the lists receivers consult. Spamhaus ZEN removal → If a listing is behind the bounce, here is how to get your IP off it. Full domain check → SPF, DKIM, DMARC, MX and the blacklists, scored in one run.