SMTP 454: TLS or authentication temporarily failed
454TLS not available or temporary authentication failureTemporary: the sender retries
454 4.7.0 TLS not available due to local problem
What it means
Two extensions define 454. RFC 3207 uses "454 TLS not available due to temporary reason" as the answer to STARTTLS when the server cannot start encryption right now. RFC 4954 uses "454 4.7.0 Temporary authentication failure" when AUTH could not be completed because of a problem on the server, such as an unreachable password backend.
Both are temporary, so a well behaved client retries. What happens next depends on the sender’s policy. A server that only does opportunistic TLS may fall back to plain text delivery, while one bound by MTA-STS, DANE, or a "TLS required" rule keeps deferring until TLS works again.
Postfix also uses 454 4.7.1 for "Relay access denied" style replies in some configurations, so read the text. Compare with 530, which says authentication is required, and 538, which says encryption is required before this AUTH mechanism.
Likely causes
- The receiving server’s TLS certificate or key file is missing, unreadable, or failed to load after a renewal.
- The server ran out of entropy or hit a TLS library error during the handshake setup.
- The authentication backend (LDAP, SQL, or a SASL daemon) behind the submission server is down or timing out.
- A load balancer or proxy in front of the mail server breaks the STARTTLS upgrade.
How to fix it
- Look at the command just before the 454. After STARTTLS it is a TLS problem; after AUTH it is an authentication backend problem.
- For TLS, check that the certificate and key paths in the MTA configuration exist, are readable by the mail user, and match each other. Restart or reload the service after renewing.
- For AUTH, check the SASL or Dovecot auth service logs and confirm the user database is reachable.
- If you are the sender and the receiver publishes MTA-STS in enforce mode, expect delivery to stay deferred until they fix TLS; tell their admin with the time and host.
Checks that apply
- SMTP Diagnostics Runs STARTTLS against the server and reports whether the handshake completes and which certificate it presents.
- MTA-STS Check Shows whether the domain enforces MTA-STS, which decides whether senders fall back to plain text or keep deferring on TLS errors.
- TLS-RPT Check Confirms a TLS-RPT address exists so senders can report the failed handshakes to the domain owner.
FAQ
- Will mail be sent unencrypted after a 454?
- Sometimes. Opportunistic senders may retry without TLS; senders that must use TLS because of MTA-STS or DANE will keep the message queued instead.
- Is 454 a bounce?
- Not by itself. It is temporary; it only becomes a bounce if the problem lasts past the sender’s queue lifetime.