How to Set Up MTA-STS for Microsoft 365: Step-by-Step
MTA-STS turns email transport encryption from a voluntary nicety into a binding rule. Publishing it for a domain hosted on Microsoft 365 sounds like a five-minute DNS task, and then most administrators hit the same wall: Exchange Online does not serve the policy file. The DNS part is trivial, but the policy itself has to live somewhere Microsoft will not host for you. That single friction point is what this guide solves, concretely, for Microsoft 365 and Exchange Online.
If you only want to understand what MTA-STS is and how the protocol works, start with the MTA-STS basics. This article is the hands-on setup walkthrough for the most common high-intent case: a domain whose mail flows through mail.protection.outlook.com.
The core friction: Microsoft 365 cannot serve the policy
TL;DR: To enable MTA-STS for Microsoft 365 you publish a _mta-sts TXT record, then serve a static mta-sts.txt policy file over HTTPS from an mta-sts subdomain with a valid certificate. Exchange Online evaluates inbound policies but will not host your own policy file, so you host it yourself, for example on an Azure Static Web App, or you let a managed service do it. List your mail.protection.outlook.com hosts in the policy, start in testing, enable TLS-RPT, verify, then switch to enforce.
MTA-STS has two halves. One half lives in DNS and is easy. The other half is a web resource: a static file served over HTTPS from a dedicated subdomain, protected by a valid TLS certificate. A sending server fetches that file before delivering to your domain and refuses to fall back to plain text if the destination does not match.
Microsoft 365 happily acts on the receiving side. When another domain publishes an MTA-STS policy, Exchange Online reads it and reports on it. But for your own domain, Microsoft does not give you a web endpoint at mta-sts.your-domain.com. There is no toggle in the admin center that publishes the policy file for you. So the question is never whether to host the policy, only where.
What you need before you start
Three building blocks make up a working MTA-STS deployment on Microsoft 365:
| Building block | What it is | Who provides it on M365 |
|---|
_mta-sts TXT record | Signals a policy exists and carries a version string | You, in your DNS zone |
mta-sts.txt policy file | Static file listing allowed hosts, mode and validity | You host it; Exchange Online does not |
| HTTPS subdomain plus certificate | Serves the file at mta-sts.your-domain.com over TLS | You, via a static host or a managed service |
_smtp._tls TXT record (TLS-RPT) | Requests TLS reports so you can verify safely | You, in your DNS zone |
You will also need to know your MX target. For a standard Microsoft 365 tenant that is a host under mail.protection.outlook.com, for example your-domain-com.mail.protection.outlook.com. The policy must name that host so the TLS check matches what senders actually connect to.
Step by step: MTA-STS on Microsoft 365
Step 1: Publish the _mta-sts TXT record
Create a TXT record at _mta-sts.your-domain.com with a value such as v=STSv1; id=20260630120000. The id is a free-form version string; many teams use a timestamp. Whenever you change the policy file later, you bump this id so sending servers know to refetch.
Step 2: Host the policy file (the part EXO will not do)
Create the file mta-sts.txt and serve it at https://mta-sts.your-domain.com/.well-known/mta-sts.txt. A minimal Microsoft 365 policy looks like this:
version: STSv1
mode: testing
mx: your-domain-com.mail.protection.outlook.com
max_age: 604800
Because Exchange Online will not host this, you have two practical paths:
- A managed service that provisions the subdomain, the certificate and the file for you, and keeps them valid. This is what Conbool MailGuard does, and it is covered below.
- A static HTTPS host you run yourself, such as an Azure Static Web App, an object-storage bucket with a CDN in front, or any small web host. The constraint is that it must present a valid certificate for
mta-sts.your-domain.com and serve the file under /.well-known/.
The mx lines in the policy must match the hosts your MX record points to. For a single Microsoft 365 tenant that is usually one mail.protection.outlook.com host. If you route inbound mail through a gateway in front of Microsoft 365, list the gateway hosts instead, since those are the servers external senders actually reach. A mismatch here is the single most common cause of failed deliveries once you reach enforce.
Step 4: Start in testing mode
Keep mode: testing in the policy. In this mode senders evaluate the policy and report problems, but they still deliver even when the TLS check would have failed. This is the safety net that lets you observe real traffic without risking mail flow.
Step 5: Enable TLS-RPT to collect reports
Add a TXT record at _smtp._tls.your-domain.com such as v=TLSRPTv1; rua=mailto:tlsrpt@your-domain.com. With TLS-RPT enabled, sending servers deliver daily summaries of how many connections were encrypted and why any failed. Testing mode without reporting is half-blind, so treat these two steps as one.
Step 6: Verify
Confirm that _mta-sts resolves, that the policy file loads over HTTPS with a trusted certificate, and that the mx hosts match your MX record. A quick way to sanity-check transport posture for your domain is the free transport security check. Let testing run for several days and read the TLS reports until they are clean and stable.
Step 7: Switch to enforce
Change the policy file to mode: enforce, then bump the id in the _mta-sts TXT record so senders pick up the new version. From now on, a sending server that cannot establish a verified TLS connection to your mail.protection.outlook.com host will refuse to deliver rather than fall back to plain text. That is the protection you were after.
Common pitfalls
A few mistakes account for almost every broken MTA-STS rollout on Microsoft 365:
- CNAME on the mta-sts subdomain. It is tempting to point
mta-sts.your-domain.com at a provider with a CNAME. Many static hosts cannot present a certificate for a CNAME-only target, and the well-known fetch is a plain HTTPS request. Use A or AAAA records, or a host that explicitly supports certificates on your custom subdomain. - An expiring certificate. If the certificate on
mta-sts.your-domain.com lapses, the policy fetch fails and, in enforce, legitimate senders may stop delivering. Automated renewal is not optional here. - A policy that does not match your MX. If the
mx lines do not include the exact mail.protection.outlook.com host that your MX record points to, the TLS check fails for real senders. Whenever you change your mail routing, update the policy first.
How Conbool MailGuard handles it for Microsoft 365
The hard part of MTA-STS on Microsoft 365 is never the protocol, it is owning a permanently valid HTTPS subdomain and a policy file that always tracks your real MX hosts. Conbool MailGuard takes that whole layer off your plate: it provisions and serves the mta-sts subdomain, keeps the certificate valid automatically, generates the policy with the correct mail.protection.outlook.com hosts, and guides the move from testing to enforce while collecting the TLS reports in one place. The full managed offering is described on the MTA-STS page.
Because MailGuard already sits in your mail flow as an email security gateway, the same platform that runs your phishing protection and spam filtering for Microsoft 365 also owns transport security, so there is no separate moving part to maintain.
Frequently asked questions
Why can Exchange Online not host the MTA-STS policy file itself?
Exchange Online and Microsoft 365 evaluate inbound MTA-STS policies and send TLS reports, but they do not serve a policy file for your own domain. MTA-STS requires the policy to live as a static file at https://mta-sts.your-domain.com/.well-known/mta-sts.txt with a valid certificate, and Microsoft does not provide that web endpoint for customer domains. You therefore host it yourself, for example on a static HTTPS host such as an Azure Static Web App, or you delegate it to a managed service like Conbool MailGuard.
Which DNS records and subdomain does MTA-STS on Microsoft 365 require?
You need a TXT record at _mta-sts.your-domain.com that carries the policy version, plus the mta-sts subdomain that serves the policy file over HTTPS. The mta-sts subdomain must resolve through A or AAAA records to the host that serves the file, because the well-known fetch is an HTTPS request and many hosts cannot present a certificate for a CNAME-only target. To collect reports you also add a TXT record at _smtp._tls for TLS-RPT.
How do I run MTA-STS in testing mode before enforce on Microsoft 365?
Set the mode field in the mta-sts.txt policy to testing. In testing mode sending servers evaluate the policy and report failures, but they still deliver mail even when the TLS check would have failed. Combined with TLS-RPT this lets you watch which partners connect cleanly without risking mail flow. Once the reports are stable over a few days, you change the mode field to enforce and publish a new version in the _mta-sts TXT record.
Does MTA-STS also work with Google Workspace?
Yes. Google Workspace evaluates inbound MTA-STS policies and sends TLS reports just as Microsoft 365 does. The setup is the same in principle: publish the _mta-sts TXT record and serve the policy from an HTTPS subdomain. Only the mx host list inside the policy differs, because Google uses its own aspmx hosts rather than the mail.protection.outlook.com hosts used by Exchange Online.
What are the most common mistakes when setting up MTA-STS for Microsoft 365?
The three frequent failures are: using a CNAME on the mta-sts subdomain so the HTTPS certificate cannot be presented, letting the certificate on that subdomain expire, and listing the wrong hosts in the policy so the mx entries do not match your actual MX records. For Microsoft 365 the policy must list the mail.protection.outlook.com hosts that your MX record points to, otherwise the TLS check fails for legitimate senders.
Conclusion
Setting up MTA-STS for Microsoft 365 comes down to one decision Microsoft will not make for you: where the policy file lives. Once you publish the _mta-sts TXT record, serve mta-sts.txt from an HTTPS subdomain with a valid certificate, list your mail.protection.outlook.com hosts, and roll out through testing with TLS-RPT before flipping to enforce, your inbound mail is protected against silent downgrade attacks.
The next step is yours: check your domain with the free transport security check and see how Conbool MailGuard hosts the policy, the subdomain and the certificate so you never have to run them yourself.
Further reading:
