Why this is a 4xx
The code is temporary, and it means it literally: the sending server does not bounce the mail but queues it and retries later. While the problem persists, mail piles up — the recipient only notices a delay, the sender sees it immediately in the queue.
The most common causes on your own server
- Certificate renewed, service not reloaded. By far the most common case. Renewal writes new files while the running process keeps working with the old material. The renewal needs a hook that reloads the service — without it the problem only shows up after expiry.
- File not readable. After renewal the private key belongs to root with permissions the unprivileged process can no longer read. STARTTLS is advertised from the configuration; the material is missing at runtime.
- Key and certificate do not match. After a migration or a manual copy one path points at an old pair and the other at a new one.
- Wrong file format or an incomplete chain. The PEM message
no start linein the logs is the unambiguous signature: the file does not contain what was expected — a DER-encoded certificate, say, or a file with text prepended. - Resources exhausted. Rare but real: without free file descriptors or memory no TLS context can be built.
Checking
If that fails while EHLO still reports 250-STARTTLS, the contradiction is confirmed. Then compare certificate and key directly:
If the two checksums differ, the files do not belong together. The mail server's own log names the concrete library message and is the most reliable source here.
Why MTA-STS or DANE make it dangerous
Without those mechanisms a sending server falls back to unencrypted delivery on TLS problems — the mail arrives, unprotected but delivered. With mode=enforce in the MTA-STS policy or a published TLSA record that very fallback is forbidden. Mail then stops entirely until the certificate is correct again. Anyone using these mechanisms therefore needs monitoring of the remaining validity and a reload hook in the renewal.