What Is MTA-STS?

MTA-STS has two parts. A DNS TXT record at _mta-sts.yourdomain.com carries a version and an id, as in v=STSv1; id=20260810120000Z, and the id changes whenever the policy changes so senders know to fetch it again. The policy itself is a plain text file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

The HTTPS fetch is what makes the policy trustworthy, because the sending server validates the certificate for the mta-sts host and a policy cannot be forged by tampering with DNS alone. The file lists the version, the mode, one mx pattern for every host allowed to receive your mail, and a max_age in seconds telling senders how long to cache it, up to a maximum of 31557600.

The mode field takes one of three values. In enforce, a sending server must not deliver to a host that fails the mx match, fails certificate validation, or does not offer STARTTLS. In testing, delivery proceeds as though there were no failure, and a sender that also implements TLS-RPT reports the failure instead.

That gives the safe rollout order. Publish testing first, read the TLS reports until no legitimate sender is failing, then switch the mode to enforce and change the id in the DNS record so senders pick up the new policy.

Publishing a policy protects mail coming in, not mail going out. It tells other servers how to connect to your mail hosts, so it hardens inbound delivery and does nothing for the reputation of your outbound campaigns.

The outbound half is whether your own sending path honours the policies other domains publish. Gmail was the first large provider to support MTA-STS and TLS reporting, and Exchange Online now validates MTA-STS on outbound connectors, so a policy you publish is increasingly likely to be read and obeyed.