Understand what your scan results mean / STARTTLS
STARTTLS vs implicit TLS: two different ways mail gets encrypted
Both approaches end with an encrypted connection, but they start very differently — and the difference explains why the same misconfiguration doesn't affect them the same way.
Implicit TLS means the connection is encrypted from the very first byte — the client connects on a dedicated port (like 465 for SMTP submission) that's understood to always be TLS, no negotiation required. STARTTLS means the connection starts in plaintext on a shared port (like 25 or 587), and the client explicitly asks to upgrade to TLS mid-conversation before any real content is sent.
STARTTLS exists mainly for backward compatibility: port 25 has carried SMTP since long before TLS existed, so upgrading it in place (rather than requiring a whole new port) let the ecosystem adopt encryption gradually. The tradeoff is exactly the downgrade risk MTA-STS was built to close — because the connection starts unencrypted, an attacker positioned in the network path can interfere with the upgrade request itself.
Implicit TLS doesn't have that specific downgrade risk (there's no unencrypted negotiation phase to interfere with), which is part of why modern mail submission increasingly favors port 465 for client-to-server submission. Port 25, used for server-to-server delivery, is stuck with STARTTLS for practical backward-compatibility reasons that aren't going away soon.
What to do: for server-to-server delivery (port 25, what Korantix's Mail Server check tests), the priority is verifying STARTTLS is actually advertised and the TLS handshake actually completes — not switching ports, which isn't how domain-to-domain delivery works. For client mail submission (587/465), implicit TLS on 465 is generally the safer default when your provider supports it.