TLS and STARTTLS failures

Where the encryption upgrade happens

A mail server may advertise STARTTLS in its EHLO response. The client can then upgrade the existing connection to TLS encryption under RFC 3207. The SMTP handshake explanation shows this step in the command sequence.

Emvero uses opportunistic TLS. It attempts encryption when the server offers STARTTLS and can continue without encryption when there is no offer. An absent offer therefore has a different meaning from an attempted upgrade that fails.

What the failure tells you

SMTP_STARTTLS_FAILED records an upgrade that could not finish. Emvero stops before MAIL FROM and RCPT TO, and does not retry the same conversation in plaintext. The server has not heard the recipient, so the failure supplies no evidence of mailbox existence.

The reason-code vocabulary includes SMTP_TLS_CERTIFICATE_FAILED. The current probe does not validate certificate chains or hostnames, however, and does not emit this code from those checks. An expired, self-signed or mismatched certificate is not automatically rejected. Verification cannot certify the destination’s identity or certificate health.

A command-and-reply failure after a successful TLS upgrade is a separate condition, covered by SMTP protocol errors. Read the reported cause before treating an interrupted connection as a certificate failure.

Handling an inconclusive check

When no other evidence determines the decision, a completed inconclusive check returns unknown with allow_with_email_confirmation. If it is pending, retrieve the same check after retry_after_ms. The verification result guide explains both workflows.

A later attempt may add evidence, without guaranteeing a conclusion. When mailbox access matters, your application can send confirmation; Emvero’s probe sends no email. Unknown versus undeliverable explains how to handle the unresolved result.