SMTP 454 4.7.5: temporary authentication or TLS problem

454 is a real, RFC-defined reply code — RFC 3207, the STARTTLS extension, specifies 454 TLS not available due to temporary reason as a legitimate server response. Paired with enhanced status code 4.7.5, it generally signals a temporary authentication or security-policy problem: a certificate issue, an SMTP AUTH credential rejected transiently, or a security requirement the server can't currently satisfy. This is a 4xx deferral, not a permanent failure.

Who is at fault

Could be either side. A server-side TLS certificate expiring or misconfiguring triggers this from the recipient's end; a sender using expired or incorrect SMTP AUTH credentials, or attempting to connect without the security level the server currently requires, triggers it from the sending side.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250-mx.example.com
250 STARTTLS
STARTTLS
454 4.7.5 TLS not available due to temporary reason - handshake failure

Or, in the authentication variant:

AUTH LOGIN
334 VXNlcm5hbWU6
[credentials sent]
454 4.7.5 Temporary authentication failure

How the big three word it

Diagnose it

$ openssl s_client -starttls smtp -connect mx.example.com:25 -brief
$ openssl x509 -in cert.pem -noout -dates

Check the TLS certificate validity on the server you're connecting to (if you control it), and confirm the credentials and OAuth tokens your sending system is using are current and not recently rotated or expired.

Fix it, in order

1. Check credential and token expiry first — this is the single most common sender-side cause, especially for OAuth-based sending (Gmail, Microsoft 365 APIs) where tokens expire and need silent refresh.
2. Verify your TLS certificate chain if you're running your own outbound or inbound mail server — an expired or misconfigured certificate produces exactly this condition.
3. Let the retry queue work if the cause isn't immediately identifiable — many occurrences are transient server-side throttling that clears within minutes.
4. Re-authenticate the sending account if token refresh appears to have failed silently — forcing a fresh OAuth flow often resolves persistent occurrences.

A cause worth distinguishing: 454 versus 530/535 authentication failures

It's worth separating 454 4.7.5 from two codes it's sometimes confused with. 530 5.7.0 ("must issue a STARTTLS command first") and 535 5.7.8 ("authentication credentials invalid") are both also real, RFC-defined codes dealing with authentication and TLS, but they describe permanent conditions — a credential that is simply wrong, or a security requirement your client isn't attempting to meet at all — rather than a transient failure. If you're seeing 535 rather than 454, re-entering the same credentials and waiting won't help the way it might for a genuine 454 4.7.5; you need to fix the credential itself.

An additional diagnostic command

$ openssl s_client -connect smtp.gmail.com:587 -starttls smtp -crlf 2>&1 | grep -A3 "AUTH"

Listing the authentication mechanisms the server actually advertises for your connection confirms whether your sending system is attempting a mechanism (such as plain LOGIN over an unencrypted channel) that the server will only accept after STARTTLS — a configuration mismatch that can surface as this same code.

How long to expect this to clear

A genuinely transient 454 4.7.5 — server-side throttling, a brief certificate rotation window, a backend auth service blip — typically clears within minutes to a couple of hours, and your MTA's normal retry backoff will carry the message through that window without intervention. If it recurs continuously across every attempt for more than a few hours against the same provider, stop assuming it's transient: that pattern almost always means a credential or token refresh process is actually broken, and no amount of additional waiting will resolve it.

What not to do

• Don't assume this is a permanent block. 454 is explicitly a temporary-reason code by definition in its originating RFC.
• Don't disable TLS or downgrade security to work around it. That trades a transient deferral for a real security and deliverability problem, since most receiving servers now require TLS.
• Don't ignore repeated occurrences. A recurring 454 4.7.5 against the same provider, especially alongside authentication, usually means a token refresh or certificate renewal process is broken, not that the condition will simply resolve on its own.

MailPilot verifies authentication status — SPF, DKIM, DMARC, and OAuth connection health for connected mailboxes — continuously, so a credential or token problem surfaces before it produces a wave of these deferrals.