MTA-STS checker

Fetches your MTA-STS policy, compares it with your live MX hosts and gives you the record and policy file to publish.

Next

Email me this report
Every check, your policy against the live MX, the record and file to publish, and a saved link that stays live for 90 days.
Full report as HTMLRecord and policy file, copy-paste readySaved link for 90 days
One email with the report. No sequence, no sales call.
Ken sets up the domains it sends from.
SPF, DKIM and DMARC from day one, checked every day while it warms and sends.
Start free - 1,000 credits, no card

What the MTA-STS checker does

MTA-STS, defined in RFC 8461, tells other mail servers to deliver to you only over TLS with a valid certificate, and only to the MX hosts you list. It has two parts: a TXT record at _mta-sts.yourdomain.com with v=STSv1 and an id, and a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

The checker reads both, validates the policy syntax, and compares the mx lines in the policy with your live MX records. A policy that doesn't match your MX can block your own inbound mail once it's in enforce mode.

How to read the policy

  • version is always STSv1.
  • mode is enforce, testing or none. Testing reports failures without blocking. Enforce makes senders refuse to deliver when TLS or the MX match fails.
  • mx has one line per allowed MX host. A wildcard like *.mail.example.com matches one label.
  • max_age is how long senders cache the policy, in seconds, up to 31557600, about a year.

Senders fetch the policy again when the id in the TXT record changes or their cached copy expires, so change the id every time you edit the file. The file must be served over HTTPS with a valid certificate for mta-sts.yourdomain.com, as text/plain.

How to roll it out

Start in testing mode with a TLS-RPT record, so you get reports. Watch them for at least a week. When no sender reports TLS failures for your MX hosts, switch to enforce, raise max_age to a week or more, and change the id.

On Google Workspace or Microsoft 365 the MX hosts already have valid certificates. The work is hosting the policy file on the mta-sts subdomain over HTTPS.

Does MTA-STS matter for cold email?

It protects mail coming in to your domain, not the mail you send. Receivers don't look at your MTA-STS policy when they filter your outbound messages, which is why it carries little weight in a cold email grade.

It's worth having on your main domain, where customers and partners send you mail. On a sending domain that only receives replies, it's optional.

Questions

What is MTA-STS?
A standard from RFC 8461 that makes mail servers sending to your domain use TLS with a valid certificate and deliver only to the MX hosts you list. It stops an attacker from downgrading the connection to plain text or redirecting your mail to their own server.
Do Gmail or Yahoo require MTA-STS?
No. Their sender rules cover SPF, DKIM, DMARC, unsubscribe, spam rate, reverse DNS and TLS on your outgoing connections. MTA-STS is about mail sent to you.
Why does my MTA-STS policy fail?
Common causes: the policy file isn't reachable over HTTPS, the certificate on mta-sts.yourdomain.com is invalid, the file isn't served as text/plain, the mx lines don't match your real MX hosts, or the id in the TXT record didn't change after you edited the file.
What is the difference between testing and enforce mode?
In testing mode senders deliver as usual and report TLS problems to your TLS-RPT address. In enforce mode they refuse to deliver when TLS or the MX match fails. Always start with testing.
How do I remove an MTA-STS policy?
Don't just delete it, because senders keep the cached policy until max_age runs out. Publish mode: none with a short max_age, such as one day, and a new id first, wait until the old max_age has passed, then remove the record and the file.

More in Deliverability

30 tools.