MTA-STS checker.
Enter your domain. We check the TXT record at _mta-sts.your-domain and the HTTPS-served policy file at https://mta-sts.your-domain/.well-known/mta-sts.txt. Both halves are required for the policy to be active.
Pins TLS on the wire between mail servers.
When another mail server tries to deliver to you, MTA-STS tells it which MX hosts to accept and that the connection has to be encrypted. Without it, an attacker on the path can quietly downgrade to plaintext.
Two halves, both required
A TXT record at _mta-sts.your-domain announces the policy exists. The policy itself lives at https://mta-sts.your-domain/.well-known/mta-sts.txt served with a valid TLS certificate.
Testing first, enforce later
mode: testing publishes the policy but does not break delivery on failure — receivers send TLS-RPT reports instead. After two to four weeks of clean reports, switch to mode: enforce.
Refreshed on cadence
max_age is how often sending servers refetch the policy. Common values are 604800 (one week) or 2592000 (30 days). Lower values let you change the policy faster; higher values are easier on your HTTPS endpoint.
Pairs with TLS-RPT
TLS-RPT is the sibling DNS record that tells receivers where to mail aggregate TLS-error reports. Run them together: MTA-STS publishes the rule, TLS-RPT tells you when it failed.
MTA-STS is one of about thirty external checks.
AttackEdge Monitoring re-runs MTA-STS, TLS, DMARC, SPF, DKIM and the rest on a recurring schedule. Plain-English findings, IT-ready fixes, monthly PDF.
Setup in 60 seconds · Cancel anytime
MTA-STS, in plain English.
- MTA-STS (RFC 8461) tells other mail servers they must use TLS when delivering mail to your domain, and which MX hosts to trust. Without it, an attacker on a transit network can downgrade the connection to plaintext and read or modify mail in flight.