What this analysis does
The analyzer combines the _mta-sts policy identifier, the HTTPS policy file and the _smtp._tls reporting record into one transport-security view.
SMTP negotiates TLS opportunistically, which means an active attacker can strip the upgrade and force a plaintext session. MTA-STS lets a domain declare that senders must use authenticated TLS, and TLS-RPT provides the telemetry to see when that expectation is not met.
Two parts must agree
MTA-STS is published in two places that are easy to get out of step. A DNS TXT record announces the policy and carries an identifier, and a policy file served over HTTPS at a well-known location on the mta-sts subdomain carries the actual contents. A sender fetches the file only when the DNS record indicates it should.
The identifier in the DNS record is what signals a change. Updating the policy file without changing that identifier means conforming senders continue using their cached copy, so a corrected policy can appear to have no effect for as long as the previous cache lifetime.
- The DNS record announces; the HTTPS file defines.
- Changing the policy without changing the identifier leaves senders on the cached copy.
- The policy file must be served from the mta-sts subdomain over valid HTTPS.
Every published MX must match the policy
The policy file lists the mail exchangers a sender should expect. Any published MX that does not match a listed pattern will be refused by a conforming sender in enforce mode, which turns a documentation oversight into rejected mail.
This is the failure that most often follows a provider change. MX records are updated, the MTA-STS policy is not, and mail from senders honouring the policy stops while mail from senders that ignore it continues. The partial nature of the failure makes it slow to diagnose.
Deploy through testing mode with reporting
The mode field supports a testing value that asks senders to report failures without refusing delivery. Publishing TLS-RPT first, then running testing mode long enough to observe a full sending cycle, surfaces mismatches before they can block mail.
Only move to enforce once reports show no unexpected failures. The sequence — reporting, testing, enforce — costs a few weeks and removes essentially all of the risk from a change that is otherwise difficult to reverse quickly because of policy caching.
Analyze the resulting TLS reportsRead the transport security guide
Example: an exchanger missing from the policy
Evidence supplied
A domain in enforce mode publishing three MX records, where the policy file lists only two.
How to read the result
The analysis reports the unmatched exchanger as a critical finding, because conforming senders in enforce mode will refuse delivery to that host while continuing to deliver to the two that match.
Known limits
- The policy file is retrieved only when DNS resolves to public addresses and the standard HTTPS endpoint responds correctly.
- Sender support for MTA-STS is not universal, so a valid policy does not protect every path.
- Policy caching means recent changes may not yet be visible to all senders.
Common questions
Does MTA-STS replace DANE?
No. They are independent mechanisms with different trust models. DANE relies on DNSSEC, while MTA-STS relies on the web PKI. Some domains publish both.
What does testing mode achieve?
Senders report failures through TLS-RPT without refusing delivery, which lets a policy be validated against real traffic before it can block mail.
Why did mail stop after an MX change?
Most often because the MTA-STS policy file was not updated to include the new exchanger, so conforming senders in enforce mode refuse it.