SMTP error 454: temporary authentication or TLS failure

A bare 454 reply is a 4xx temporary failure — RFC 5321 defines 454 generically as "TLS not

available due to a temporary reason", but in practice it is reused by many receiving servers for

any temporary local-side problem that blocks the current session, most commonly a STARTTLS

negotiation failure or a transient authentication rejection. The enhanced status code appended

after it (often 4.7.0 or 4.3.0) narrows down which.

A real transcript

EHLO yourdomain.com
250-mx.example.com
250 STARTTLS
STARTTLS
220 2.0.0 Ready to start TLS
AUTH LOGIN
454 4.7.0 Temporary authentication failure

A TLS-specific variant looks like this instead:

EHLO yourdomain.com
250-mx.example.com
250 STARTTLS
STARTTLS
454 4.7.0 TLS not available due to temporary reason

How the big three word it

Who is at fault

Split roughly down the middle. A TLS-side 454 is usually the receiving server's transient

problem (a cert renewal in progress, a TLS service restarting) and clears on retry with no change

needed from you. An authentication-side 454 is more often yours: an expired OAuth token, an

app password that was rotated, or enough recent failed attempts to trigger a temporary lockout on

the receiving side.

Diagnose it yourself

1. Check the enhanced status code first — 4.7.0 with "TLS" in the text points at the

handshake; 4.7.0/4.7.1 with "auth" or "login" in the text points at credentials.

1. Test the TLS handshake directly: `openssl s_client -starttls smtp -connect

mx.example.com:587` — a handshake that completes cleanly rules out a TLS problem on your end.

1. Confirm your credentials are current. For OAuth-based sending, check the token has not

expired and the refresh flow is actually running; for app-password sending, confirm the

password was not rotated or revoked since your last successful send.

1. Check your own recent failure count. Several providers apply the temporary lockout

mentioned in the Yahoo example after a handful of failed attempts in a short window — if you

have been retrying aggressively, that retry behaviour may be the actual cause.

The fix, in order

1. Wait and let the retry run if the cause is on the receiving side — most TLS-side 454s

clear within minutes without any action from you.

1. Refresh or regenerate credentials if the cause is authentication — a new app password or a

forced OAuth token refresh resolves the majority of auth-side cases.

1. Slow down your retry rate if you suspect you triggered a temporary lockout; retrying

immediately and repeatedly extends the lockout window on several providers rather than clearing

it faster.

1. Check your TLS library and cipher support if the handshake itself fails consistently rather

than intermittently — an outdated TLS library on your sending side can fail against a receiver

that has dropped support for older TLS versions.

1. Escalate to the provider only after ruling out your own credentials and TLS stack, since

this code gives almost no detail on its own.

What the retry behaviour actually looks like

A 454 is a 4xx deferral, so your own outbound queue — not the recipient — controls what

happens next. A typical MTA backs off on a schedule roughly like 15 minutes, then 30, then 1-2

hours, continuing for several days before the message bounces as undeliverable; it does not retry

every few seconds, and it does not retry forever. The practical effect differs by cause: a TLS-side

454 from a cert renewal in progress usually clears on the very next scheduled attempt, often

within minutes, because the underlying condition on the receiving server resolves quickly. An

auth-side 454 tied to a stale OAuth token will not clear on its own no matter how many times the

queue retries — the token needs to actually refresh — so watching the same 454 recur across

several scheduled retries with no change is itself diagnostic: it points at a credential problem

you need to fix, not a transient server hiccup you can wait out.

What not to do

• Do not assume 454 always means the same thing — the enhanced status code and free text after

it change the diagnosis completely, and treating every 454 as a TLS problem will send you

chasing certificates when the real issue is a stale OAuth token.

• Do not retry authentication in a tight loop after a failure — this is the single most common way

to turn a one-off 454 4.7.0 into a longer lockout, since repeated failed attempts are exactly

what several providers' temporary-ban logic is watching for.

• Do not rotate credentials reflexively on every occurrence — if the cause is TLS-side and

recipient-side, changing your password or token does nothing and just adds operational overhead.

MailPilot's OAuth-connected mailboxes (Gmail, Outlook) keep their tokens refreshed automatically,

and SMTP/IMAP connections are monitored for authentication health as part of daily reputation

tracking, which is the layer where a stale credential causing recurring 454s would normally

surface before it affects delivery.