MTA-STS protects inbound email in transit by forcing sending servers to use authenticated TLS — closing the door on STARTTLS downgrade and man-in-the-middle attacks. This free MTA-STS test checks your _mta-sts DNS record, your HTTPS policy file (mode, mx and max_age), whether the policy matches your real MX hosts, and your TLS-RPT reporting record. Check your domain → Need to publish a policy? The free MTA-STS generator builds the DNS record and the policy file.
MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain tell sending mail servers that inbound SMTP must use TLS with a valid certificate. Without it, opportunistic STARTTLS can be silently stripped by an on-path attacker, downgrading the connection to plaintext. This test confirms that the mechanism is published correctly and cannot be bypassed.
MTA-STS has two parts, and both have to line up: a short DNS TXT record that advertises the policy, and an HTTPS-hosted policy file that carries the actual rules. Our scanner fetches both, parses every field, and checks that they are internally consistent with your real MX hosts.
The first thing we resolve is the TXT record at _mta-sts.<your-domain>. It must carry two tags: v=STSv1 and an id= value. The id is a short, unique string (up to 32 alphanumeric characters per RFC 8461 §3.1) that senders cache; whenever you change the policy file you must also change the id so receivers know to refetch it.
_mta-sts.example.com. IN TXT "v=STSv1; id=20260703T120000;"A missing id is flagged, because without it sending servers cannot tell that the policy has been updated.
The policy itself lives at https://mta-sts.<your-domain>/.well-known/mta-sts.txt, served over HTTPS with a valid certificate. We fetch it and validate every field:
STSv1.enforce, testing or none. Only enforce actually rejects delivery over an untrusted connection; testing merely reports failures, and none withdraws the policy.*.example.net is allowed.version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
max_age: 604800A policy only helps if its mx lines actually match the hosts in your DNS MX records. We compare the two: if a real MX host is not covered by any mx pattern, mail to that host would fail under enforce, so the mismatch is flagged before it can block legitimate delivery.
Finally, we check for TLS-RPT (SMTP TLS Reporting, RFC 8460): a TXT record at _smtp._tls.<your-domain> beginning with v=TLSRPTv1 and carrying a rua= destination. It asks sending servers to send you daily reports of TLS delivery failures — the only way you find out that MTA-STS (or DANE) is silently blocking mail. A minimal record looks like v=TLSRPTv1; rua=mailto:tls-reports@example.com.
Both force TLS on inbound SMTP, but they anchor trust differently. MTA-STS relies on the public web PKI (a valid HTTPS certificate) and a policy published over HTTPS, so it works without DNSSEC. DANE (TLSA records) pins the certificate in DNS and is only trustworthy with DNSSEC. Many domains publish both; our scanner checks each mechanism independently.
Start with mode: testing together with TLS-RPT. In testing mode senders still deliver over any connection but report failures, so you can confirm your policy and MX list are correct without risking lost mail. Once the reports are clean, switch to mode: enforce — the only mode that actually blocks downgraded, untrusted connections.
No, MTA-STS enforces TLS on its own. But TLS-RPT is strongly recommended: it is the only feedback channel that tells you when a sending server could not deliver because of a certificate or TLS problem. Without it, a broken policy can silently block mail. Our test warns if the _smtp._tls record is missing.
RFC 8461 — MTA-STS ↗ · RFC 8460 — SMTP TLS Reporting ↗ · Mailhardener: MTA-STS ↗