Domain
Policy
Your records
Policy file serve at https://mta-sts.example.com/.well-known/mta-sts.txt
Hosting the policy file
The file must be served over valid HTTPS on the exact host mta-sts.yourdomain with a text/plain content type. If the domain is on Cloudflare, the simplest way is a Worker on that hostname — this one is complete.
Then add a proxied DNS record for mta-sts (A 192.0.2.1 is fine when proxied) and a Worker route for mta-sts.yourdomain/*. On any other host, upload the file as a static asset and make sure the certificate covers the mta-sts subdomain.
How it works
Load the MX set
The tool reads your MX records over DNS-over-HTTPS and pre-fills the mx lines, using the wildcard form for Microsoft 365 and the current single host for Google Workspace.
Pick mode and max_age
Start in testing with a one-week cache. The warnings tell you when a combination makes no sense — enforce with no report address, a one-year cache while still testing.
Publish three things
The _mta-sts TXT record, the policy file on the mta-sts subdomain, and the _smtp._tls record for reports. The worker snippet covers the hosting.
Verify, then enforce
Run the MTA-STS checker. When it passes and a week of TLS-RPT reports shows no failures, switch to enforce and raise max_age.
What MTA-STS actually does
When another server sends mail to your domain, it looks up your MX records and connects. If the connection is intercepted and TLS is stripped, the sender has no way to know — SMTP was designed before encryption existed, and opportunistic STARTTLS falls back to plaintext silently. MTA-STS fixes that by letting you publish, over HTTPS, a signed statement: these are my MX hosts, they always offer TLS with a valid certificate, and if they do not, refuse to deliver. Google, Microsoft and most large receivers honour it when sending to you, and Google and Microsoft both publish policies of their own.
Why the file matters more than the record
The DNS record is just a version marker and an id. The policy lives in a text file at https://mta-sts.yourdomain/.well-known/mta-sts.txt, and that is where every failure I have debugged actually was: a certificate that did not cover the mta-sts subdomain, a redirect to www, a content type of text/html, a CDN adding a byte-order mark. Senders fetch the file, validate the certificate strictly, and if anything is off they treat the domain as having no policy — which is safe but means the whole exercise did nothing. The Cloudflare Worker this tool writes serves the exact bytes with the right headers, and the checker tells you what a sender sees.
The rollout that does not break inbound mail
Publish in testing mode first, with a TLS-RPT address, and read the reports for a week. They are JSON, one per sending domain per day, and any failure they describe would have been a lost email under enforce. Most domains see zero and can switch within a week. The ones that do not are usually running an MX host with an expired or mismatched certificate that has worked for years purely because nobody was checking. Enforce mode with a 30-day cache is a good steady state; once the setup has been stable for months, a year is fine.
The mistakes this tool watches for
Listing a literal Microsoft host instead of the *.mail.protection.outlook.com wildcard, because Microsoft moves tenants between hosts without notice. Enforcing with no report address, so failures are invisible. A wildcard that spans a whole TLD. Changing the MX set without changing the policy id, so senders keep enforcing the old host list against the new one. And retiring a policy by deleting the file rather than publishing mode none — a sender with a cached enforce policy that can no longer fetch it will keep enforcing the stale copy until max_age runs out.
Frequently asked questions
Does MTA-STS affect my cold email deliverability?
Not directly — it protects mail sent to you, not from you. But receivers that check for it treat a domain with MTA-STS, DMARC at reject and TLS-RPT as a domain someone actually runs, and it is one of the few remaining points on a deliverability score you can still pick up in an afternoon.
Where does the policy file have to live?
At https://mta-sts.yourdomain/.well-known/mta-sts.txt — the mta-sts subdomain is fixed by the RFC, and the certificate must be valid for that exact hostname. A redirect elsewhere does not work.
What is the id for?
It is a cache-buster. Senders store your policy for max_age seconds and only refetch the file when they see the id in DNS change. If you edit the file and leave the id alone, nobody notices until the cache expires.
Should I use enforce straight away?
No. Testing mode plus a TLS-RPT address for a week or two first. Enforce refuses delivery when a certificate does not validate, and until you have reports you do not know whether one of your MX hosts has a problem.
Do I need DANE as well?
No. DANE covers the same threat using DNSSEC instead of HTTPS, and hardly any large sender validates it. If the zone is already DNSSEC-signed it is a bonus; MTA-STS is the one that receivers actually use.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.