MTA-STS Lookup
MTA Strict Transport Security TXT record + policy file.
Enter a value above to run MTA-STS Lookup
e.g. example.com
Quick answer
MTA-STS Lookup checks the _mta-sts.<domain> TXT record and fetches the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, which tells sending servers to require TLS when delivering mail to you. Look at the policy mode: enforce rejects insecure connections, testing only reports them, and none disables the policy.
MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain tell sending mail servers that inbound mail must be delivered over TLS to specific, authenticated hosts. This tool fetches both parts of the setup: the TXT record at _mta-sts.<domain> that advertises the policy and its version ID, and the policy file served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt. It shows the mode, the listed MX hosts, and the max_age lifetime so you can confirm the two halves agree and that enforcement is actually in effect.
How it works
There are two moving pieces. First, the DNS TXT record at _mta-sts.<domain> holds v=STSv1 and an id value; sending servers use that id to detect policy changes. Second, the policy itself lives in a plain-text file fetched over HTTPS from mta-sts.<domain>/.well-known/mta-sts.txt. The file lists version, mode, one or more mx patterns, and max_age. The HTTPS certificate on the policy host must be valid, because a broken fetch means senders keep using their cached policy.
How to read the results
Check that the TXT id and the file are both present and reachable. In the policy, mode=enforce means senders reject delivery if TLS or the MX identity fails; mode=testing means failures are only reported, not blocked; mode=none disables the policy. The mx lines must match your real MX records, wildcards included. max_age is the cache lifetime in seconds (commonly 604800 or more). If the TXT exists but the HTTPS file 404s or has a bad certificate, MTA-STS is not being enforced.
Common problems & fixes
The most frequent mistake is publishing the TXT record but never serving the policy file, or serving it with an expired or mismatched HTTPS certificate. Another is an mx list that omits a real MX host, which silently blocks that route under enforce. Forgetting to bump the id after editing the file means senders keep the old cached copy. Start with mode=testing plus a TLS-RPT record, review the reports, then switch to enforce once every listed MX validates cleanly.
Frequently asked questions
- What is the difference between MTA-STS and DANE?
- Both force TLS on inbound SMTP, but they anchor trust differently. DANE uses DNSSEC-signed TLSA records to pin certificates and needs a signed zone. MTA-STS relies on the web PKI and an HTTPS-hosted policy file, so it works without DNSSEC. Many domains run both; senders that support either will get encrypted, authenticated delivery.
- Why do I need both a TXT record and a policy file?
- The TXT record is only a lightweight pointer: it carries the id so senders can cheaply notice when your policy changes without downloading the file every time. The actual rules, the mode and the allowed MX hosts, live in the HTTPS policy file. If either half is missing or unreachable, senders cannot apply your policy and fall back to opportunistic TLS.
- Should I start with mode enforce or testing?
- Start with testing. In testing mode, senders report TLS or MX validation failures through TLS-RPT but still deliver mail, so a misconfigured MX list or certificate cannot bounce legitimate messages. Collect reports for a couple of weeks, confirm every MX host validates, then change mode to enforce and bump the id so senders refresh the policy.