Almost every MTA-STS guide stops at "publish a policy file listing your MX hosts." That is the easy part. The part that loses mail is which hostnames go in the list, and that answer is completely different depending on whether you are on Google Workspace or Microsoft 365, and different again if you have a security gateway in front.
This guide gives you the exact policy file for each, the hosting options that do not require running a web server, and the migration sequence that stops a provider change from bouncing your inbound mail.
1. The short version, if you already know what MTA-STS is
MTA-STS is Mail Transfer Agent Strict Transport Security. It publishes a policy telling every server that delivers mail to you: use validated TLS, only deliver to these MX hosts, and if you cannot, refuse to deliver rather than falling back to plaintext. It closes the STARTTLS downgrade hole that has existed since 1999, and it governs mail arriving at your domain, not mail you send.
Three things to publish:
- A TXT record at
_mta-sts.yourdomain.com - A policy file at
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt - A TLS-RPT record, so you can see whether any of it works
Skip to Google Workspace or Microsoft 365 for the exact files.
MTA-STS in enforce mode is the only email mechanism where a configuration error stops mail arriving rather than affecting where it lands. SPF, DKIM and DMARC influence placement. A wrong mx: list means senders refuse delivery outright. Start in testing. Every time.
2. MTA-STS for Google Workspace
Google Workspace uses five MX hosts. All five must be covered by your policy, or you risk bouncing mail during failover when Google routes to the lower-priority hosts.
Some Workspace tenants, older ones especially, and those provisioned through resellers, also use aspmx2.googlemail.com through aspmx5.googlemail.com. Check your own MX records rather than trusting any list, including this one. Run dig MX yourdomain.com +short, or use our DNS Checker, and put every hostname it returns into the file.
The safer form, which also covers hosts you have not seen yet:
Wildcards are legal for the leftmost label only. *.l.google.com matches aspmx.l.google.com and all four alt hosts. This is what we would publish for Workspace, because it survives Google adding a host without telling you.
Google Workspace specifics worth knowing
- Google does not host the policy file for you. Unlike DKIM, which Workspace generates in the admin console, MTA-STS hosting is entirely your problem. See section 4.
- Gmail is a compliant sender. Once you enforce, mail from Gmail users to your domain is subject to your policy. Google was among the first large adopters, which cuts both ways.
- Workspace MX certificates are managed by Google and will validate correctly. You should never see
certificate-expiredfor the MX hosts themselves. If a Workspace domain reports certificate failures, look at themta-stssubdomain instead.
3. MTA-STS for Microsoft 365
Microsoft 365 is simpler in one way and more dangerous in another. Simpler because each tenant normally has a single MX host. More dangerous because that hostname contains your domain name, so it is unique to you and easy to get wrong when copying from a guide.
Note the hyphen. Microsoft replaces the dot in your domain with a hyphen, so acme.com becomes acme-com.mail.protection.outlook.com. Get that wrong and, in enforce mode, nothing arrives.
The wildcard form, which we prefer because it survives tenant migrations and Microsoft's regional routing changes:
Microsoft 365 specifics worth knowing
- Exchange Online Protection honours MTA-STS on outbound. Microsoft is a compliant sender as well as a receiver.
- Multi-geo and hybrid tenants can have more than one MX host. If you run Exchange hybrid, your on-premises host must be listed too, and its certificate must be valid and match its hostname. This is the most common way a Microsoft deployment loses mail.
- Tenant migrations change the hostname. Renaming a tenant, or moving a domain between tenants, changes your MX host. Update the policy and the
idbefore the MX change, not after.
If you have a security gateway in front
Mimecast, Proofpoint, Barracuda and similar products replace your MX records with theirs. Your policy must list the gateway's hosts, not Google's or Microsoft's, because the gateway is what senders actually connect to.
Read your live MX records. Whatever they point at belongs in the file. This sounds obvious and it is still the mistake we see most, because people configure MTA-STS from a guide about their mail platform rather than from their own DNS.
4. Hosting the policy file without running a web server
You need mta-sts.yourdomain.com serving one small text file over HTTPS with a valid certificate. You do not need a web server, and you should not stand one up for this.
Cloudflare Workers
Free tier, automatic certificate, about six lines. Route mta-sts.yourdomain.com/* to a Worker:
Editing the policy becomes a one-line change with no DNS propagation to wait for.
GitHub Pages
Free, and the certificate renews itself. Create a repository, add .well-known/mta-sts.txt, enable Pages, point a CNAME at it from mta-sts.yourdomain.com, and turn on Enforce HTTPS. GitHub Pages ignores directories starting with an underscore, but .well-known starts with a dot, so it serves fine. Add an empty .nojekyll file if you hit anything strange.
Netlify, Vercel, S3 behind CloudFront
All work. The requirements are identical everywhere: HTTPS with a certificate valid for mta-sts.yourdomain.com, and Content-Type: text/plain. Serving the file as text/html causes some senders to reject it.
Not your mail servers. The one on mta-sts.yourdomain.com. If it expires, senders silently stop being able to read your policy, and your protection switches off with nothing to alert you. It fails open, which is merciful, but it also means nobody notices for months.
Use a host with automatic renewal. A manually renewed certificate on this subdomain will eventually lapse, and you will not find out from your monitoring.
5. The DNS records
The id is an opaque string you change every time you edit the policy. Senders cache your policy for max_age seconds and only re-fetch when the id changes. A timestamp is conventional because it is unique and self-documenting.
Forgetting to change the id is the single reason most people conclude MTA-STS is broken. They edit the policy, nothing happens, and they assume nobody supports it. Senders are simply still serving the cached copy, exactly as designed.
6. The rollout sequence that does not lose mail
| Week | Do this | Wait for |
|---|---|---|
| 0 | Publish TLS-RPT only | First reports, 24–48h |
| 1 | Fix whatever the reports surface | Zero failures for 7 days |
| 2 | Publish policy in mode: testing plus the _mta-sts TXT | Zero sts-* failures |
| 4 | Switch to enforce, raise max_age, change the id | Nothing. You are done. |
Four weeks feels slow. It is the difference between switching on enforcement with a month of evidence and switching it on with a hope. The only step that can cost you mail is the last one, and by the time you reach it you have watched the system work.
Once enforcing, raise max_age to 604800 or higher. A longer cache means an attacker who blocks access to your policy file cannot strip your protection quickly.
7. Changing mail providers with MTA-STS live
This is the scenario that bites people, and almost no guide covers it.
You are migrating from Google Workspace to Microsoft 365. You update MX records. Mail stops arriving from every compliant sender, because they are still enforcing your cached policy, which lists Google's hosts. Your new Microsoft host is not in it, so they refuse delivery. This continues until max_age expires, which could be a week.
The correct order:
- Before touching MX: add the new provider's hosts to the policy alongside the old ones, and change the
id. - Wait for
max_ageto elapse so every cached copy has expired. Ifmax_ageis 604800, that is a full week. - Now change your MX records. Both old and new hosts are permitted, so mail flows either way during the cutover.
- Once migration is complete and stable, remove the old hosts and change the
idagain.
If you need to move faster than max_age, drop the policy to mode: testing and change the id first. Testing mode delivers regardless of TLS outcome, so it removes the risk entirely while you migrate. Return to enforce afterwards.
8. Verifying it works
Three checks, in order.
If curl reports a certificate problem, senders will hit the same one and ignore your policy entirely.
Then confirm from the outside. Our Deliverability Score checks MTA-STS, TLS-RPT, SPF, DKIM, DMARC, reverse DNS and blacklists in one pass, so you can see what a sending server sees rather than what your own network sees.
9. Frequently asked questions
How do I set up MTA-STS on Google Workspace?
Publish a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt listing all five Google MX hosts.aspmx.l.google.com and alt1 through alt4, or use the wildcard mx: *.l.google.com. Add a TXT record at _mta-sts.yourdomain.com containing v=STSv1; id= and a timestamp. Google does not host the policy file for you, so you need a static HTTPS host such as Cloudflare Workers or GitHub Pages. Start in mode: testing.
What is the Microsoft 365 MX host for my MTA-STS policy?
It follows the pattern yourdomain-com.mail.protection.outlook.com, with the dot in your domain replaced by a hyphen. Because it is tenant-specific, always read it from your live MX records rather than copying from a guide. The wildcard mx: *.mail.protection.outlook.com is safer and survives tenant or regional changes. Hybrid Exchange deployments must also list their on-premises hosts.
Can I use a wildcard in an MTA-STS policy?
Yes, for the leftmost label only. mx: *.l.google.com is valid and matches every Google MX host. You cannot wildcard in the middle of a hostname. Wildcards are the safer choice for hosted mail platforms, because they survive the provider adding hosts you were never told about.
Where should I host the MTA-STS policy file?
Anywhere that serves static files over HTTPS with an automatically renewing certificate. Cloudflare Workers, GitHub Pages, Netlify, Vercel and S3 behind CloudFront all work and all have free tiers. The requirements are a valid certificate for mta-sts.yourdomain.com and Content-Type: text/plain. Avoid anything with manual certificate renewal, because a lapsed certificate silently disables your policy with no alert.
Why is my MTA-STS policy not updating?
Almost certainly because you edited the policy file but did not change the id value in the _mta-sts TXT record. Senders cache your policy for max_age seconds and only re-fetch when the id changes. Set the id to a new timestamp and senders will pick up the edit on their next check.
How do I change mail providers without MTA-STS bouncing my mail?
Add the new provider's MX hosts to your policy alongside the existing ones and change the id before you touch MX records. Wait for max_age to elapse so every cached copy expires, then switch MX. Remove the old hosts once the migration is stable. If you need to move faster, drop to mode: testing first, it delivers regardless of TLS outcome, removing the risk during the cutover.
Does MTA-STS improve my email deliverability?
Not directly. MTA-STS governs mail arriving at your domain, not mail you send, so it has no effect on whether your campaigns reach the inbox. Its value is privacy and integrity for inbound mail, a concrete control for compliance audits under GDPR Article 32, and a small positive posture signal alongside SPF, DKIM and DMARC. We weight it at two points out of fifteen in our infrastructure score, deliberately low.
The Deliverability Score checks MTA-STS, TLS-RPT, SPF, DKIM, DMARC, PTR and blacklists in one pass, so you see exactly what a sending server sees, before you enforce.