MTA-STS

MTA-STS has two halves, and this check reads the first: a TXT record at _mta-sts.<domain> carrying v=STSv1 and an id. The record does not contain the policy. It announces that one exists, and gives senders a cheap way to notice when it changes.

The id is the whole of that mechanism. A sender caches your policy for as long as its max_age allows, and re-reads this record — one small DNS lookup — to decide whether the cached copy is still current. If the id has changed it refetches the policy over HTTPS; if not, it does not. A record without an id leaves senders no way to tell a refreshed policy from a stale one, and some ignore the record entirely, which is why it is graded as a warning.

What MTA-STS is for: SMTP TLS is opportunistic, so an attacker on the path can strip the STARTTLS offer out of the greeting and watch the sender deliver in plaintext with neither end noticing. A policy tells senders in advance that TLS is required and which hosts may accept mail, so the stripped offer becomes a refusal to deliver rather than a silent downgrade.

The record alone protects nothing. Everything senders enforce comes from the policy file it points at, fetched over HTTPS and graded by the policy check.

Publish the record and the policy file together and treat them as one change. A record pointing at a policy that is not there is worse than neither, because senders that fetch and fail fall back to opportunistic TLS having spent the request.

Change the id every time the policy changes, and use something that reads as a version — a UTC timestamp such as 20260823120000 is the common convention. Senders compare it for inequality rather than order, but a person reading it later will want the order.

Keep the record's TTL modest. It is the upper bound on how long a sender can go without noticing a policy change, and it costs one small DNS answer to keep it short.