Error guide / 421 4.7.0 Try again later, closing connection
421 4.7.0 Try again later, closing connection
421 4.7.0 Try again later, closing connection is a temporary refusal, most often from Gmail and Google Workspace servers, usually followed by the SMTP command it happened on, such as (EHLO) or (MAIL). The receiving server ends the conversation before accepting the message and asks the sender to come back later. Because it is a 4xx code, nothing is lost yet: a correctly configured mail server keeps the message in its queue and retries over the next hours and days. Users usually notice only a delay, or a warning that delivery has not succeeded yet. It becomes a real problem when the same server gets the same answer every time.
Check your site
What causes it
Google's own error list gives this text without a single cause, because 4.7.0 is a catch-all for temporary policy refusals, but the triggers are well known. The EHLO name: a server that introduces itself as localhost, with a bare IP or with a name that does not resolve looks like a misconfigured or infected machine. Reverse DNS: Google lists a separate 421 4.7.0 for a sending IP without a PTR record, or whose PTR name does not resolve back to the same IP. Reputation and rate: a new IP, a shared IP with bad neighbours or a sudden burst of connections gets throttled. Authentication: Gmail requires every sender to pass SPF or DKIM, and bulk senders to have SPF, DKIM and DMARC, and unauthenticated mail is rate limited with related 4.7.x codes.
How to fix it
- Read the whole bounce or log line. The command in brackets tells you the stage: (EHLO) points at the server's identity and reputation, (MAIL) or (RCPT) more often at the sender address and authentication. If the text goes on with "does not have a PTR record" or "very low reputation", Google has already named the cause for you.
- Run the check on this page for the domain in your From address. It shows SPF with its lookup count, DKIM and DMARC. Gmail requires every sender to pass SPF or DKIM, and bulk senders (around 5,000 messages a day to Gmail accounts) to have SPF, DKIM and a DMARC record, with the From domain aligned. Fix anything marked missing first: unauthenticated mail is throttled however good the IP is.
- Check the sending server's identity. Its EHLO name should be a real fully qualified hostname such as mail.your-domain.com, not localhost. That name should resolve to the server's IP, and the PTR record of the IP should point back to the same name. The hosting check on this site shows the PTR of a server and whether it resolves back. On a VPS or dedicated server the PTR is set in the provider's panel, on shared hosting only the host can change it.
- Look at volume. If the server opens many parallel connections to Gmail, or a campaign starts with a big burst from a fresh IP, lower the concurrency and spread sending over time. New IPs need warming up with small, steadily growing volumes. Check the IP in public blacklists too with the blacklist check on this site: a listing means the reputation problem is real.
- If you relay through Google (smtp-relay.gmail.com or smtp.gmail.com), make sure the client uses TLS on port 587 or 465 and authenticates the way the SMTP relay settings in the Google Admin console require, and that the IP is allowed there if you relay by IP. Apps running in a Docker container that announce themselves as EHLO localhost are a frequent case: set the hostname the app uses.
- Then let the queue do its job. Do not resend by hand or force the queue in a loop, which only adds connections and makes throttling worse. If messages still fail after a day with good authentication, a proper PTR and normal volume, look up the domain and IP in Google Postmaster Tools, which shows the reputation Gmail actually assigns once you send enough mail for it to have data.