
A concrete walkthrough for enabling MTA-STS on Microsoft 365 and Exchange Online. Learn why EXO cannot serve the policy file, which DNS records and subdomain you need, how to list the mail.protection.outlook.com hosts, how to run testing mode with TLS-RPT and how Conbool MailGuard hosts the policy and certificate for you.
Die neuesten Beiträge aus unserem Blog.

MTA-STS für Microsoft 365 einrichten: Diese Anleitung erklärt, warum Exchange Online die Richtliniendatei nicht selbst bereitstellt, welche DNS-Einträge und HTTPS-Subdomäne nötig sind und wie der…

DANE verankert das TLS-Zertifikat eines Mailservers über DNSSEC im DNS und schützt so vor Downgrade und Zertifikatsfälschung. Dieser Guide erklärt, was DANE und TLSA sind, wie die Zertifikatsbindung…

Ein Directory Harvest Attack, kurz DHA, sammelt über SMTP gültige E-Mail-Adressen für spätere Spam- und Phishing-Wellen. Dieser Guide erklärt, was ein Verzeichnisangriff ist, wie er sich von…
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.
TL;DR: To enable MTA-STS for Microsoft 365 you publish a
_mta-stsTXT record, then serve a staticmta-sts.txtpolicy file over HTTPS from anmta-stssubdomain 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 yourmail.protection.outlook.comhosts in the policy, start intesting, enable TLS-RPT, verify, then switch toenforce.
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.
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.
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.
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:
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.
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.
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.
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.
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.
A few mistakes account for almost every broken MTA-STS rollout on Microsoft 365:
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.mta-sts.your-domain.com lapses, the policy fetch fails and, in enforce, legitimate senders may stop delivering. Automated renewal is not optional here.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.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.
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.
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.
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.
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.
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.
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: