5.7.321: destination server does not offer TLS (DANE)

What it means

This belongs to SMTP DANE, which Exchange Online applies when it sends to a domain that publishes DNSSEC-signed TLSA records. Those records commit the domain to TLS. Here the DNSSEC checks passed, but when Exchange Online connected, the destination server did not respond to STARTTLS, or it responded and the TLS handshake then failed. Without TLS the message cannot go, and Exchange Online will not fall back to an unencrypted connection. Microsoft lists the error as 4.7.321 while retrying and 5.7.321 at the end. The receiving side has to fix its server.

Common causes

• STARTTLS is turned off on the receiving server.
• The TLS handshake fails after STARTTLS, for example because of a protocol or cipher mismatch.

How to fix it

1. 01Tell the recipient's admin and pass on the full error from the report.
2. 02The destination admin should enable STARTTLS on every MX host and confirm that a TLS handshake completes from outside.
3. 03If the domain cannot offer TLS for now, it must remove its TLSA records, since publishing them tells senders that TLS is mandatory.

Sources

What this page rests on, checked on 20 Oct 2026. The explanation is ours; the reply text is the server's.

• Email nondelivery reports and SMTP errors in Exchange Onlinelearn.microsoft.com
• How SMTP DNS-based Authentication of Named Entities (DANE) workslearn.microsoft.com