STARTTLS

STARTTLS is negotiated per connection. MTA-STS publishes whether sending servers must refuse delivery when TLS cannot be validated to the recipient MX.

TLS-RPT collects failure reports for inbound TLS problems, complementing MTA-STS enforcement with telemetry.

Google's sender guidelines state that SMTP to Gmail must use TLS. The 530 5.7.0 row on Google's SMTP error list names STARTTLS when a sender attempts plaintext delivery where TLS is required.

MTA-STS on the receiving domain is documented on the What is MTA-STS page on this site. STARTTLS is the wire upgrade; MTA-STS is the published requirement to use it.

RFC 3207 negotiates TLS after EHLO; the server presents a certificate the client may validate against the MX hostname or policy from MTA-STS.

A successful STARTTLS handshake does not prove the sender is authorized. SPF, DKIM, and DMARC still apply after the message is transferred.

Without MTA-STS or DANE, many paths use opportunistic TLS where clients upgrade when offered but may continue in cleartext if negotiation fails.

RFC 8461 MTA-STS can require TLS to recipient MX hosts. TLS-RPT at _smtp._tls collects reports when TLS fails on inbound delivery attempts.

RFC 3207 defines the STARTTLS extension itself. Certificate name mismatches after a successful upgrade are a TLS layer problem distinct from SMTP reply codes.