MTA-STS Studio
MTA-STS and TLS-RPT checker
MTA-STS tells sending mail servers to require TLS when they deliver to you — and TLS-RPT tells you when that fails. Check both are published and valid in one step.
What MTA-STS does
By default, SMTP encryption is opportunistic: a sending server will use TLS if offered, but silently falls back to plaintext if it is stripped or a certificate is invalid. MTA-STS lets you publish a policy that says “always use TLS to reach me, with a valid certificate” — closing that downgrade gap for inbound mail.
The two pieces
MTA-STS needs a DNS TXT record at _mta-sts.yourdomain and a policy file served over HTTPS at mta-sts.yourdomain/.well-known/mta-sts.txt. TLS-RPT adds a TXT record at _smtp._tls.yourdomain so senders can email you daily reports about TLS successes and failures.
What we check
Propagation of the _mta-sts TXT record, the policy file over HTTPS with its mode, mx list and max_age, and the TLS-RPT record with its reporting address. We flag testing vs enforce mode and common mistakes like a missing policy file or an mx list that does not match your real MX records.
Frequently asked
Do I need MTA-STS if I already have DKIM and DMARC?
Yes — they solve different problems. DKIM and DMARC authenticate the sender and stop spoofing. MTA-STS protects the message in transit by preventing a passive attacker from stripping TLS during delivery to you.
What is “testing” mode?
MTA-STS supports mode: testing, where senders honour the policy for reporting but still deliver if TLS fails. Start in testing, watch your TLS-RPT reports, then move to mode: enforce once you are confident.
Why does the policy need a separate HTTPS host?
The policy is fetched over HTTPS from mta-sts.yourdomain so its authenticity is protected by your web certificate, not just DNS. The DNS record only signals that a policy exists and when it last changed.