5.7.321 means Exchange Online tried to deliver to a destination that did not offer STARTTLS on a route where encryption was required. The requirement can come from a connector configured to mandate TLS, from the recipient domain’s MTA-STS policy, or from Microsoft’s own transport rules.
Most common causes
- The destination SMTP service does not advertise STARTTLS
- A gateway or load balancer is terminating SMTP without the expected TLS capability
- The wrong MX target or service endpoint is receiving the connection
- A transport-security policy requires TLS but the destination path cannot negotiate it
What to verify next
- Run Mail Transport Security against the destination domain
- Verify the MX targets and whether each advertises STARTTLS
- Check whether an MTA-STS or connector policy requires encrypted transport
- Inspect recent gateway or certificate configuration changes
Where the TLS requirement comes from
Microsoft encrypts opportunistically by default and delivers in clear text when the destination does not offer TLS. When a connector for the destination domain is set to require TLS, or the destination publishes an MTA-STS policy in enforce mode, delivery without TLS is not allowed and the message is rejected with this code.
The destination in question is the mail exchanger that accepted the connection — which may be a gateway or filtering service in front of the recipient’s actual mail server.
Confirm what the destination offers
Run Mail Transport Security against the recipient domain. It lists the MX hosts, whether STARTTLS is advertised, and whether an MTA-STS policy exists. If a host does not advertise STARTTLS, TLS-mandated routes cannot deliver to it regardless of who sends.
If STARTTLS is offered but negotiation fails, the problem is a certificate or protocol mismatch, which is reported under 5.7.322 or a negotiation failure rather than this code.
- Identify which MX host accepted the connection.
- Check whether that host advertises STARTTLS.
- Determine which side imposed the TLS requirement.
Resolution depends on who controls what
If you are the recipient, enable STARTTLS with a valid certificate on every MX host, or correct your MTA-STS policy if it enforces TLS that your hosts cannot provide. If you are the sender and the requirement is a connector you configured, either fix the destination with its administrator or relax the connector for that domain if the business accepts unencrypted delivery.
Retest after changes with the transport-security check; caching of MTA-STS policies can delay the effect on the sending side.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisMail Transport Security
Inspect MX, TLS, MTA-STS and transport-policy evidence for the destination.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- A gateway in front of the recipient may be the host lacking STARTTLS, not the recipient’s own server.
- MTA-STS policy caching means a corrected policy is not immediately visible to all senders.
Common questions
We did not require TLS. Why rejected?
The recipient domain may publish an MTA-STS policy in enforce mode, which imposes the requirement from their side.
Can we just send unencrypted?
Only if no connector or policy mandates TLS for that route. Consider whether the content should travel in clear text at all.
How do I see the MX host’s TLS support?
Use Mail Transport Security for the recipient domain; it reports STARTTLS and MTA-STS per exchanger.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.