Read the domain's _mta-sts record, fetch the policy file it announces, and see what it really does: enforcing or only testing, how long senders cache it, and whether it covers every mail server the domain uses. Free, no sign-up.
Mail servers encrypt with STARTTLS opportunistically: if anything goes wrong (an expired certificate, a stripped capability, someone tampering with the connection) the sender falls back to plain text and delivers anyway. MTA-STS (RFC 8461) closes that gap by publishing which servers may receive the domain's mail and telling senders to refuse anything else.
It comes in two halves. A DNS record at _mta-sts says a policy exists and carries a version id. The policy itself is a text file served over HTTPS from the mta-sts subdomain, behind a certificate that must validate. The DNS half alone protects nothing, which is why this checker never reports a pass until the policy has been read.
v=STSv1; id=The DNS record. Change the id every time you edit the policy, or senders keep their cached copy.
mode:enforce refuses unverified delivery. testing only reports, which in practice protects nothing. none withdraws.
mx:One line per allowed host. In enforce mode, an MX host not covered here stops receiving mail from enforcing senders.
max_age:How long senders cache the policy, in seconds. Use weeks (604800 is 7 days, or more): caching is what defeats an attacker who blocks the fetch.
The policy host must serve a valid certificate for mta-sts.yourdomain, as text/plain, without redirects.
Publish it alongside MTA-STS so you hear about TLS failures before switching to enforce.
Publish TLS-RPT first, then a policy in testing mode listing every MX host, with a short max_age. Read the TLS reports for a week or two. When they are clean, switch to enforce, raise max_age to weeks, and change the id.
Add the new hosts to the policy's mx: lines and change the id before moving MX records. Senders still holding the old cached policy will otherwise refuse to deliver to the new hosts.
Usually a missing mta-sts subdomain, a certificate that does not cover it, a redirect, or the file served at the wrong path. Senders treat all of these as "no policy".
Yes. Gmail, Microsoft and most large providers honour MTA-STS when sending to you, and Gmail publishes its own policy.
Point an MCP client (Claude, Cursor, any agent) at https://powerline.ai/mcp and call check_record, or hit the JSON endpoint directly. No key, no account.
curl "https://powerline.ai/api/tools/mta-sts?domain=example.com"
Validate the _smtp._tls record against RFC 8460 and see where TLS failure reports are sent.
SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI and blacklists in one run, scored out of 100 with a fix list.
Read the DMARC policy, alignment and reporting tags, and check that report addresses will accept reports.
Validate the SPF record, follow every include, and count DNS lookups against the limit of 10.
See how your HTML email actually renders in real Gmail, Outlook.com and Yahoo Mail accounts. Free screenshots.