Setting up MTA-STS for Microsoft 365

MTA-STS for Microsoft 365: DNS TXT plus a self-hosted policy file with *.mail.protection.outlook.com.

Last updated: July 2026

In short: After this guide your domain enforces encrypted delivery for incoming mail to your Exchange Online mailboxes — via a DNS record and a policy file served over HTTPS.

⚠️ Delivery risk: a faulty MTA-STS policy in enforce mode can make other servers stop delivering mail to your domain — and max_age keeps the mistake cached for days. Always start with mode: testing and review TLS-RPT reports before enforcing.

Prerequisites

A Microsoft 365 tenant whose MX points to Exchange Online (*.mail.protection.outlook.com)
Access to your domain's DNS management (at the domain host)
A place where you can host the policy file over HTTPS (Microsoft recommends Azure)

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) tells other mail servers: "Deliver mail to my domain only over a valid, encrypted TLS connection." Microsoft distinguishes two scenarios — this is about the inbound protection, which "covers the protection of domains that are hosted in Exchange Online with MTA-STS".

As with Google Workspace, MTA-STS consists of two parts: a DNS TXT record under _mta-sts and a policy file at https://mta-sts.your-domain/.well-known/mta-sts.txt.

The starting point at Microsoft 365

A central point from Microsoft's docs: Exchange Online doesn't host the policy file for you. Verbatim: "MTA-STS policy files aren't something that Exchange Online can host on behalf of customers." So you have to provide the file yourself — Microsoft names Azure as a convenient option ("Azure services can readily be used for policy hosting").

The MX values in the policy are the same for all Exchange Online customers: *.mail.protection.outlook.com.

Step-by-step guide

1. Create the policy file

The file mta-sts.txt looks like this for Exchange Online — start in testing mode (Microsoft's own doc example goes straight to enforce; testing first is safer):

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800

version: STSv1 must be on the first line. For comparison you can look at Microsoft's own reference policy at any time: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

Afterwards, analyze the TLS-RPT reports — you only switch to mode: enforce in step 4.

2. Serve the policy file over HTTPS

Host the file at https://mta-sts.your-domain/.well-known/mta-sts.txt — with a valid certificate that includes your domain. Microsoft provides ready-made configuration flows for hosting via Azure; but in principle any HTTPS web server that serves the subdomain mta-sts.your-domain with a trusted certificate works.

3. Create the DNS TXT record

At the domain host you create the _mta-sts record. Example:

v=STSv1; id=20250710T120000

The id signals to senders that they should (re-)fetch the policy. Important: "After MTA-STS policies are updated, you must update the ID" — otherwise senders keep using the cached old policy until its max_age expires.

Also add TLS-RPT (_smtp._tls), so you get reports on TLS delivery.

4. Check and tighten to enforce

When the reports show that all legitimate senders deliver cleanly over TLS, you set the policy file to mode: enforce and update the id in DNS.

Verify the result

Check your configuration with the free Kuveris scanner — it checks the _mta-sts record, fetches the policy file, and shows it together with TLS-RPT and your TLS status. By the way, Microsoft itself publishes v=STSv1; id=20190225000000Z for microsoft.com.

Common mistakes

Expected Microsoft to host the policy. Exchange Online doesn't — you have to provide the policy file yourself over HTTPS (e.g. via Azure).

Wrong MX in the policy. For Exchange Online, mx: *.mail.protection.outlook.com must be in the policy — not your own domain.

Forgot the id after a change. Without a new id, senders stay on the old, cached policy.

Straight to enforce without a test. It's safer to do testing first, check TLS-RPT reports, then enforce.