SMTP 420: connection timeout, mostly a Yahoo-specific reply

420 is not part of the RFC 5321 base reply-code table, but it is a real reply code that Yahoo's mail infrastructure (and some older mail systems) genuinely emits. It is worth being precise here rather than lumping it in with purely invented numbers: 420 means the connection timed out or the service became unavailable partway through the session - the server was responding, then stopped, typically due to an idle timeout being exceeded or the service shutting down the connection for load reasons.

Who is at fault

The fault is usually on the receiving server's session handling, not yours - most often an idle timeout triggered because your client paused too long between commands, or the service deliberately closing connections under load. Yahoo's own documented behaviour around session timeouts has changed over the years as part of

broader anti-abuse tightening, and what counted as an acceptable pause between commands some years

ago may now trigger a 420 where it previously did not. If a sending integration that has worked

reliably against Yahoo for a long time suddenly starts producing 420s without any change on your

own side, it is worth checking whether Yahoo has adjusted its timeout thresholds, which is more

likely than a sudden regression in code that has not changed.

The exchange

220 mta.yahoo.com ESMTP
EHLO mail.yourdomain.com
250-mta.yahoo.com
250 SIZE 41943040
MAIL FROM:<sender@yourdomain.com>
250 ok
RCPT TO:<recipient@yahoo.com>
250 ok
[... long pause before DATA is sent ...]
420 Timeout waiting for data from client

The long pause before issuing DATA exceeded Yahoo's session idle timeout, and the server closed the connection with 420 rather than waiting indefinitely.

How Gmail, Microsoft 365 and Yahoo word the same idle-timeout condition

Yahoo is distinctive here in using the non-standard 420 base code where Gmail and Microsoft 365 use the more RFC-conventional 421 for the same underlying idle-timeout condition.

Diagnostic commands

Check whether your sending client is pausing too long between SMTP commands, which is the most common cause:

$ swaks --to recipient@yahoo.com --from sender@yourdomain.com --server mta.yahoo.com -v
-> EHLO mail.yourdomain.com
<- 250 mta.yahoo.com
-> MAIL FROM:<sender@yourdomain.com>
<- 250 ok
[15+ second gap before next command]
<~  420 Timeout waiting for data from client

If your application logic does significant work (database lookups, template rendering, rate-limit checks) between opening the SMTP connection and sending DATA, that work is happening on an already-open, timing connection - move it before the connection opens instead.

The ordered fix

1. Review your sending application's logic for any work happening after the connection opens but before the message is fully transmitted - that delay is what trips the idle timeout.
2. Pre-render the message content before establishing the SMTP connection, so the session itself runs start to finish with minimal pauses.
3. Increase your own client-side command pacing only if needed - most well-behaved SMTP clients complete a full transaction in well under a second once content is ready.
4. Retry the send once the application-side delay is eliminated; this condition does not require waiting on the receiving server at all.
5. If delays are unavoidable (e.g. generating large attachments), consider establishing the connection only once content is fully ready rather than opening early.

What not to do

• Do not assume Yahoo is blocking you. This is a session-timing issue, not a reputation or policy rejection, and has nothing to do with blocklists.
• Do not add artificial delays or retries without fixing the root pacing issue. If your application still pauses too long before DATA, a retry will time out identically.
• Do not treat 420 as equivalent to a rate-limit block. It is purely about session idle time, independent of how many messages you are sending overall.
• Do not search broadly for "SMTP 420" expecting RFC documentation. You will find it described mainly in vendor-specific and community sources, not the core SMTP specification.

Why this is more common with larger or dynamically generated messages

Idle-timeout closures like this show up disproportionately on messages that are rendered,

personalised, or have attachments generated at send time, because the rendering work is the thing

most likely to happen after the connection opens rather than before it. A simple structural fix -

fully rendering the message object in memory, then opening the SMTP connection only once it is

ready to transmit - removes the dependency between connection lifetime and content-generation time

entirely, regardless of how slow or fast that generation step happens to be on any given send.

MailPilot's sending pipeline prepares message content before opening any SMTP session and completes transactions without mid-session application delays, which avoids idle-timeout closures like this across every provider it connects to, Yahoo included.