Two parts have to exist together
MTA-STS needs a DNS TXT record at `_mta-sts.<domain>` announcing that a policy exists and its version, and a separate policy file served over HTTPS at `https://mta-sts.<domain>/.well-known/mta-sts.txt` that actually states the enforcement mode and which MX hosts are authorized. The DNS record alone does nothing; a sending server that supports MTA-STS fetches and caches the policy file before it will honor it.
Testing mode exists for a reason
The policy file's `mode` can be `none`, `testing`, or `enforce`. `testing` behaves like `enforce` for the purposes of generating reports (paired with TLS-RPT) but does not actually reject connections that fail to meet the policy — the same staged-rollout instinct DMARC's `t=y` serves, applied to transport security instead of message authentication. Moving straight to `enforce` without first watching what `testing` reports risks losing legitimate mail from senders whose SMTP configuration does not yet meet the policy.
This protects mail coming in, not mail going out
MTA-STS is about how other people's mail servers deliver mail to your domain, the opposite direction from SPF, DKIM, and DMARC, which govern how receivers judge mail claiming to be from your domain. Without MTA-STS, an attacker in a position to intercept SMTP traffic can attempt a downgrade to unencrypted delivery or present a fraudulent certificate, and a sending server with no enforced policy to check against has no way to know that is happening.
Wraps' checker has the scoring formula for this but not the check itself, yet
Wraps' scoring code carries a real, specific bonus for a validated MTA-STS policy — a couple of points for `enforce`, less for `testing` — the same shape as the small bonuses it gives BIMI and DNSSEC. What it doesn't have yet is the check that would feed that bonus: `mtaStsResult`, `tlsRptResult`, and `dnssecResult` are all hardcoded stub values in the checker today, never actually looked up over DNS or fetched over HTTPS, so the bonus is dead code that nothing currently triggers. A domain with a correct, fully enforcing MTA-STS policy and one with no MTA-STS record at all score identically on this dimension right now.
Why it matters
Plain SMTP negotiates TLS opportunistically with STARTTLS, which means a network attacker who can intercept the connection before STARTTLS negotiates can simply strip it and force plaintext delivery, and the receiving side has no standard way to notice. MTA-STS turns that from an invisible downgrade into a policy violation a sender can be required to honor and report on.
How to check it
dig +short TXT _mta-sts.example.comCommon questions
Do I need both the DNS record and the policy file for MTA-STS to work?
Yes. The DNS TXT record only announces that a policy exists; the actual enforcement mode and authorized MX hosts live in the HTTPS-served policy file. A sending server fetches and caches that file — the DNS record alone changes nothing about how mail is delivered.
What does MTA-STS testing mode actually do?
It generates the same TLS-RPT reports enforce mode would, so you can see what would have been rejected, but it does not actually reject any connection. It is the safe way to validate a policy before it can affect real mail delivery.
Does MTA-STS replace SPF, DKIM, or DMARC?
No. Those three govern whether mail claiming to be from your domain is authentic. MTA-STS governs how mail is transported to your domain over SMTP. They solve different problems and are commonly deployed together, not as alternatives.