wiredepth
Run a check

Free tool · Mail transport

MTA-STS generator

Generate both artifacts MTA-STS needs in one pass: the DNS TXT record at _mta-sts.<domain> and the policy file served at https://mta-sts.<domain>/.well-known/mta-sts.txt. Pick your authoritative MX hosts and mode; we emit both with the right RFC 8461 syntax.

Use wildcards (*) for provider patterns like *.mail.protection.outlook.com. List every host that legitimately receives mail for this domain - mail from a non-listed MX is rejected in enforce mode.

How long senders cache the policy. RFC 8461 minimum is 86400s (1 day). 7 days is the common pick.

Step 1 - DNS TXT record

Name
_mta-sts.example.com
Type
TXT
Value
v=STSv1; id=20260514

id= is just a version label - bump it (e.g. add a time suffix) whenever the policy file changes so senders invalidate their cache.

Step 2 - policy file

Host this file at:

https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
max_age: 604800

HTTPS requirements: the policy URL must be served over HTTPS with a valid (non-expired, non-self-signed) certificate chained to a public CA. The hostname mta-sts.<domain> needs a CNAME or A record pointing at wherever you host the file.

Rollout cadence: start at testing, pair with a TLS-RPT record so failures get reported, watch for two weeks, then flip to enforce once TLS-RPT shows zero failures. Never go straight from no-policy to enforce in one step.

Verify after publishing: the MTA-STS checker resolves the DNS record, fetches the policy file, and validates both in one shot.

What this tool checks

What MTA-STS does: declares to other mail servers that mail destined for your domain MUST be delivered over TLS to one of a published list of MX hosts. Stops downgrade attacks where a network adversary strips STARTTLS off the SMTP conversation, OR delivers your mail to a man-in-the-middle MX. Receiving servers cache your policy and refuse to deliver to non-matching MX hosts or unencrypted connections for the policy lifetime.

Why two artifacts:the DNS TXT record is the discovery signal - it tells senders "there is a policy, version id X." The actual policy is the file served over HTTPS at the well-known location; that's what receivers fetch, parse, and cache. Splitting it this way means policy changes propagate via TTL of the small DNS record + a fresh HTTPS fetch, not by re-publishing DNS every time you change an MX host.

Pair with TLS-RPT. MTA-STS in enforce mode without TLS-RPT means the first time a sender fails delivery you have no way to know. With TLS-RPT, receivers send daily aggregate reports of TLS failures to your nominated address. Always publish both - generate the TLS-RPT record with /tls-rpt-generator and ship them together.

Frequently asked questions

Where do I host the policy file?

Anywhere that serves HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt. Common options: a static-site host (Cloudflare Pages, Netlify, Vercel) with a CNAME from mta-sts.<domain>, or a path rewrite on your existing web server. The cert needs to be valid (publicly trusted CA, hostname matches), or receivers refuse the fetch.

Can I host the policy file on the same domain as my main site?

No. The spec requires the mta-sts subdomain specifically. This lets you put MTA-STS policy on a CDN distinct from the rest of your infrastructure, and it scopes the cert requirements narrowly.

What happens if my MX changes after I publish?

Senders honour the cached policy for max_age. If the new MX isn't in the cached policy and you're in enforce mode, senders reject delivery. Plan MX changes by: 1) publish a new policy listing BOTH old and new MX hosts AND bump the DNS id= tag; 2) wait at least max_age; 3) confirm via TLS-RPT that everyone's pulled the new policy; 4) cut traffic to the new MX; 5) republish without the old host. Or set a short max_age (1 day) if you expect to change MXes often.

Testing vs enforce mode - what's the practical difference?

In testing mode, receivers do the TLS dance and send TLS-RPT reports of any failures, but still deliver the mail. In enforce mode, TLS or MX-match failures cause the receiver to defer or reject the message entirely. Always start with testing for at least one week per max_age window to verify the policy is correct against real senders.

Is MTA-STS required for DMARC compliance?

No - DMARC and MTA-STS solve different problems. DMARC defends against forged From: addresses; MTA-STS defends against transport-layer downgrade. Most domains should have both, but they are independent.

Related free tools

MTA-STS + TLS-RPT checker

Verify a published MTA-STS record + policy file in one shot.

TLS-RPT generator

Generate the TLS reporting record that pairs with MTA-STS.

TLS health checker

Check cert validity, protocols, ciphers - the foundation MTA-STS relies on.

Unified domain check

One report covering MTA-STS, DMARC, SPF, TLS, BIMI, headers, and more.