How to identify TLS or MTA-STS blocking?

Your emails are bouncing to a specific domain and the error message mentions something about TLS, a handshake failure, or a policy mismatch. Sound familiar? This is one of those delivery failures that looks like a reputation problem but is actually a technical one. The fix is different, so diagnosing it correctly matters.

Here's what's happening at a high level. When your server sends email to another server, they negotiate an encrypted connection first. That negotiation is called a TLS handshake. If it fails, the mail doesn't move. MTA-STS is a published policy that tells senders "you must use TLS when delivering to us, or we'll reject your message entirely." Both can produce similar symptoms from your side.

Start with your SMTP logs

This is always step one. Your mail server records exactly what happened during a connection attempt. The phrases you're looking for are things like TLS handshake failed, certificate verify failed, no shared cipher, SSL routines, or connection timed out paired with a TLS reference. If you see those, you've confirmed the block is encryption-related, not reputation-related.

The error message usually tells you which domain triggered it and sometimes which step in the handshake broke. Pay attention to both.

The most common TLS culprits

Once you've confirmed it's a TLS issue, there are a few likely causes. An expired or invalid certificate on your server is the most common one. Your sending server presents a certificate to the receiving server during the handshake. If it's expired, self-signed without trust, or issued to the wrong domain name, the receiving server rejects it.

And a protocol version mismatch is the next most common. Most servers today require TLS 1.2 or TLS 1.3. If your server is still configured to offer only older versions (TLS 1.0, TLS 1.1, or the ancient SSLv3), modern receiving servers will refuse the connection. This tends to appear suddenly after a receiving server upgrades their requirements, not after anything changes on your end (which makes it confusing).

A cipher suite incompatibility is the same idea but at a more granular level. Your server and the receiving server need to agree on at least one encryption method. If your server only offers weak or deprecated ciphers, the handshake fails before any mail is exchanged.

Checking for MTA-STS specifically

MTA-STS is a published DNS policy that works differently. If the receiving domain has an MTA-STS policy in enforcement mode, your server fetches that policy and learns it must connect over a valid, trusted TLS connection or not deliver at all. This protects against downgrade attacks.

To check whether a receiving domain uses MTA-STS, look up their DNS for a TXT record at _mta-sts.theirdomain.com. If it exists, fetch their policy file at https://mta-sts.theirdomain.com/.well-known/mta-sts.txt. If the mode says enforce, any TLS failure on your side will result in a hard rejection. No retry, no fallback to unencrypted delivery. The mail just doesn't go through.

In your logs, MTA-STS rejections sometimes appear as a policy fetch failure or a TLS requirement not satisfied message, depending on your mail server software. The domain-specific pattern is the giveaway: it fails to that one domain consistently, while everything else delivers fine.

Quick diagnosis checklist

• Check SMTP logs for TLS error phrases (see above)
• Verify your sending server's certificate is valid, trusted, and not expired
• Confirm your server supports TLS 1.2 and TLS 1.3
• Look up the receiving domain's MTA-STS policy to see if enforce mode is active
• Test your sending server's TLS configuration with an external tool to see what it actually presents to the world

You can check your sending domain's related configuration with our MTA-STS Checker and Email Header Analyzer. If you're staring at a log entry you can't parse, the SOS hotline is free and we'll help you read it.