SMTP 454 TLS Not Available Due to Temporary Reason

A 454 reply to the STARTTLS command means the server tried to start TLS and could not. RFC 3207 defines the text as "TLS not available due to temporary reason". Despite the word "temporary", on your own server it is almost always a persistent configuration fault, such as a missing key file, a bad certificate or a permissions problem.

C: STARTTLS
S: 454 4.7.0 TLS not available due to temporary reason

postfix/smtpd[7712]: warning: cannot get RSA private key from file "/etc/ssl/private/mail.key": disk quota exceeded
postfix/smtpd[7712]: warning: TLS library problem: error:0A080009:SSL routines::PEM lib

Mail clients often show this as "TLS negotiation failed", or mail apps refuse to connect because TLS is required.

Causes, most likely first

1. Certificate or key file missing, renamed or unreadable (path wrong, permissions, a certificate renewal that moved files).
2. Certificate and private key do not match after a partial renewal.
3. Expired or broken certificate chain, with the intermediate missing.
4. Out of memory or file descriptors during the TLS handshake setup.
5. Remote server problem, when the 454 is returned by a destination you send to.

Step 1: reproduce it with OpenSSL

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

For submission port 587 use the same command with :587. Look at the beginning of the output. If you see the certificate chain and Verify return code, TLS works. If the handshake aborts or you see 454, the server-side TLS setup is failing. Use the Port Checker to confirm the port is reachable first.

Step 2: check the certificate with outside tools

The SSL Checker validates dates, hostname and chain for HTTPS; for mail, run the same hostname on 465 or inspect with OpenSSL. The SSL Chain Debugger shows a missing intermediate and the TLS Version Checker shows which protocol versions your host accepts. A mismatch between what you serve and what the sender requires (for example, only TLS 1.0 enabled) also breaks negotiation, although that usually shows as a handshake error rather than 454.

Step 3: fix the server side (Postfix)

Find the TLS settings:

postconf smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_chain_files

Then test each file:

sudo ls -l /etc/letsencrypt/live/mail.example.com/
sudo openssl x509 -in /etc/letsencrypt/live/mail.example.com/fullchain.pem -noout -dates -subject
  # key matches cert if both digests are identical
sudo openssl x509 -in fullchain.pem -noout -pubkey | openssl sha256
sudo openssl pkey -in privkey.pem -pubout | openssl sha256

Postfix reads these files as root when it starts the master process, so permissions are rarely the issue for Postfix, but for Dovecot, Exim and others the service user must be able to read the key. After a certificate renewal, reload the service. Postfix and Dovecot will keep serving the old, now-expired certificate until reloaded:

sudo systemctl reload postfix dovecot

If you use Let's Encrypt, add a renewal hook. See Let's Encrypt renewal failures and how to renew an SSL certificate and automate it.

Step 4: Exim and others

Exim logs TLS errors in its main log with TLS error on connection. Confirm tls_certificate and tls_privatekey paths and ownership. In Exim, an unreadable key causes STARTTLS to be refused. Sendmail needs CERT_FILE and KEY_FILE defined correctly. For hosted mail (Microsoft 365, Google Workspace) you cannot fix the certificate; open a provider ticket.

Step 5: if the remote server returns 454

When your server logs 454 from a remote host, Postfix with smtp_tls_security_level = may falls back to plaintext after a failed STARTTLS in many setups, while encrypt or MTA-STS-enforced policies refuse to fall back and defer the message. Check if the recipient publishes an MTA-STS policy; see MTA-STS and TLS-RPT. If their TLS stays broken, the message will wait in your queue until they fix it. Tell their admin and send the log line.

How to verify

Run the OpenSSL command again and confirm a normal certificate and 250 replies after STARTTLS. Then send a test message and verify TLS in the received headers (with ESMTPS). For ongoing protection, add an Uptime Monitor alert for certificate expiry, and track the mail host in the Email DNS Checker.

Next steps

• Read SMTP 530 must issue a STARTTLS command first for the opposite problem.
• Study SSL/TLS certificate errors explained.
• Check email bounce codes explained.
• Review Let's Encrypt renewal failures.

FAQ

Is 454 TLS not available the same as a certificate error?

Not exactly. It means the server could not begin TLS. A bad certificate is one common cause, but so are unreadable key files and resource problems.

Why is it called temporary if it keeps happening?

The code class is just "try again later". A permanent config fault returns the same temporary code until you fix it.

Do I need to restart or reload after renewing?

Yes. Mail daemons load certificates at start or reload, so a renewed file on disk is not used until the daemon is reloaded.

Does Gmail use 454 for something else?

Yes. Gmail documents 454 4.7.0 for "Too many login attempts, please try again later" during authentication.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.