SMTP: When a server requires TLS (STARTTLS) for inbound mail
Why some MTAs refuse plaintext delivery and how to diagnose the typical error path.
Summary
Some SMTP servers demand a successful STARTTLS negotiation before they accept a message. That policy protects local compliance goals but often confuses senders if their MTA cannot upgrade the session.
Why require STARTTLS?
Regulated industries, incident response teams, and shared mail clusters increasingly mandate transport encryption for audits. By advertising STARTTLS and rejecting plaintext alternatives, administrators align with documented security baselines and ensure downstream copies stay encrypted.
Common failure modes
The usual complaints involve outdated cipher lists, mismatched certificates, or middleboxes that strip the STARTTLS banner. Capturing the SMTP transcript with openssl s_client or swaks --tls immediately shows which side aborted the negotiation. If the remote host never offered STARTTLS, expect to see 530 Must issue a STARTTLS command first errors.
Diagnostic checklist
Confirm DNS resolves to the intended MX, test STARTTLS from multiple networks, and review logs for NO_TLS or protocol error markers. Publishing modern TLSA/DANE records narrows the cipher debate because clients either validate the record set or fall back to plaintext delivery elsewhere.
Further reading (German)
Keywords
SMTP, STARTTLS, MTA, transport encryption, diagnostics