5.7.321

Enhanced Status Code 5.7.321: STARTTLS Not Supported by Destination

Permanent failure High severity Security
What it means

Enhanced Status Code 5.7.321 means “STARTTLS Not Supported by Destination.” The destination mail server does not offer STARTTLS, and your policy requires encryption, so the message was not sent in the clear. The fix belongs to the receiving domain.

At a glance
Code5.7.321
Bounce typeHard (permanent)
SeverityHigh
CategorySecurity
What to doSuppress the address; do not retry
What it looks like in your mail logs 
550 5.7.321 starttls-not-supported: Destination mail server must support TLS to receive mail

What does 5.7.321 mean?

Microsoft returns 5.7.321 with the text starttls-not-supported, meaning the destination mail server must support TLS to receive mail and does not. Exchange Online sends 4.7.321 first while it retries, and escalates to 5.7.321 once the retry window expires.

This is enforcement rather than preference. Where a destination publishes an MTA-STS policy, or where the sender has configured a policy requiring TLS for that domain, there is no fallback to cleartext. A receiving server that fails to advertise STARTTLS therefore cannot be reached at all, rather than being reached insecurely. That is the intended behaviour and the reason MTA-STS exists.

The important operational point is that this is almost never fixable by the sender. If the destination does not offer STARTTLS, no configuration change at your end will produce a compliant connection, and disabling your own TLS requirement to work around it defeats the protection. The correct action is to contact the receiving organisation, and meanwhile to recognise that the recipient address itself is perfectly valid.

How 5.7.321 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.321 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.321 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.7.321 is✓ this code

What each provider means by 5.7.321

A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.

Exchange Online The destination mail server does not support STARTTLS Reference

Common causes of 5.7.321

  • The destination mail server does not advertise STARTTLS on connection
  • The destination published an MTA-STS policy its own servers do not satisfy
  • A firewall or middlebox is stripping the STARTTLS advertisement in transit
  • The destination server has TLS misconfigured and fails to offer it
  • An old or unmaintained mail server at the destination predates TLS being expected
  • The destination MX changed to a host without TLS configured

How to fix 5.7.321

  • Do not suppress the recipient, since the address is valid and the fault is at their end
  • Contact the receiving organisation, as only they can enable STARTTLS
  • Confirm with openssl s_client -starttls smtp whether the destination advertises it at all
  • Check whether their MTA-STS policy is stricter than their servers can satisfy
  • Do not disable your own TLS requirement as a workaround, which removes the protection
  • Check for a middlebox on your side stripping STARTTLS if other senders reach them fine

Frequently asked questions

What does 5.7.321 mean?
It means the destination mail server does not support STARTTLS and your side requires TLS, so the message could not be delivered without sending it unencrypted. Microsoft uses the text starttls-not-supported. Exchange Online defers with 4.7.321 first and escalates to the permanent form once retries are exhausted.
Can I fix this myself?
Almost never. If the destination does not offer STARTTLS, no configuration on your side produces an encrypted connection. The only real fix is at the receiving organisation. Disabling your own TLS requirement would work around it but removes exactly the protection the requirement exists to provide.
Should I suppress the recipient?
No. The address is valid and the failure is about transport security at their end, not about the mailbox. Suppressing would discard a good address over somebody else's server configuration, and would leave you unable to reach them once they fix it.
How do I confirm the destination lacks STARTTLS?
Connect with openssl s_client -starttls smtp -connect their-mx:25 and see whether the negotiation succeeds. If their EHLO response does not list STARTTLS at all, they genuinely do not offer it. If it does list it and your connection still fails, something in the path may be stripping it.
Why is this becoming more common?
Because more domains publish MTA-STS policies and more senders enforce them. Conditions that used to result in a quiet downgrade to cleartext now result in a visible delivery failure. The volume of these errors is a sign of encryption being enforced rather than of anything getting worse.

Related bounce codes

5.7.5 Cryptographic Failure 4.7.5 Cryptographic Failure - Temporary 5.7.30 REQUIRETLS Support Required 5.4.8 MTA-STS Validation Failed 5.7.4 Security Features Not Supported

Sources & further reading

How SMTP DANE works · Microsoft reference for DANE, TLSA records and the 5.7.32x codes Exchange Online NDR reference · Microsoft list of SMTP errors returned by Exchange Online
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes