MTA-STS Lookup – Complete Guide to MTA-STS Records and Policies

Most mail between servers is encrypted with STARTTLS, but only opportunistically: if an attacker strips the STARTTLS offer or presents a fake certificate, the sending server usually falls back and delivers anyway. MTA-STS closes that gap for inbound mail by publishing, over HTTPS, which MX hosts you use and that they must be reached with verified TLS.

The setup has more moving parts than other email DNS records: a TXT record, a separate HTTPS host with a valid certificate, a policy file with exact syntax, and MX patterns that must match reality. The MTA-STS Lookup checks all of them in one go: it reads the _mta-sts TXT record, fetches the policy file the way a sending server would, parses it and compares its mx patterns with your actual MX records.

What is MTA-STS?

In simple terms

MTA-STS (Mail Transfer Agent Strict Transport Security) is a promise you publish: "my mail servers are these, and they always offer proper TLS". Sending servers that understand it remember this promise and refuse to hand over mail to your domain if a connection cannot be secured. It is the email counterpart to HSTS for websites.

Technical background

MTA-STS is defined in RFC 8461 and consists of two parts:

1. The TXT record at _mta-sts.<domain>:
   text

    v=STSv1; id=20261017

   id is 1–32 alphanumeric characters. Senders use it to detect that the policy has changed.

2. The policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, served with Content-Type: text/plain and a certificate valid for mta-sts.<domain>:
   text

    version: STSv1
    mode: enforce
    mx: mail.example.com
    mx: *.mx.example.net
    max_age: 604800

mode is enforce (refuse delivery without verified TLS), testing (deliver anyway but report failures through TLS-RPT) or none (policy withdrawn). Each mx line is an exact host name or a wildcard that covers exactly one leftmost label. max_age is how long senders may cache the policy, in seconds.

A sender that supports MTA-STS looks up the TXT record, fetches the policy over HTTPS without following redirects, caches it, and then for each delivery checks that the MX host matches a pattern and that the SMTP server presents a valid certificate for that name after STARTTLS. MTA-STS uses the web PKI, unlike DANE, which uses DNSSEC-signed TLSA records.

Why use MTA-STS Lookup?

• Verify a new deployment before telling anyone it is live.
• Catch policy file errors: wrong content type, HTTP errors, redirects, missing version, invalid mode or max_age.
• Find MX drift: after a provider migration, MX hosts often no longer match the policy's mx lines, which in enforce mode stops mail from compliant senders.
• Check the id record: a malformed id or two v=STSv1 records break discovery.
• Confirm the mode you think you deployed (testing vs enforce).

Who should use it?

• Mail administrators deploying MTA-STS or migrating MX hosts.
• Security teams auditing transport encryption for a domain.
• Organizations that must meet transport-security requirements for inbound mail.
• Consultants verifying a client's mail setup alongside SPF, DKIM and DMARC.

How MTA-STS Lookup works

The check runs on the NetTools.tech server:

1. The TXT records at _mta-sts.<domain> are queried through public resolvers (Cloudflare 1.1.1.1 and Google 8.8.8.8), never internal DNS.
2. The domain's MX records are resolved.
3. Only if a record starting with v=STSv1 exists, the policy is fetched from https://mta-sts.<domain>/.well-known/mta-sts.txt. The request uses HTTPS with certificate validation, follows no redirects (as RFC 8461 requires), is limited to 64 KB and 8 seconds, and goes only to a public IP address.
4. The response must be HTTP 200 with Content-Type: text/plain; otherwise the status or content type is reported as a policy file error.
5. The policy is parsed line by line. version: STSv1, a valid mode, a numeric max_age and, unless mode is none, at least one mx line are required.
6. Every MX host is compared with the mx patterns, with wildcards matching exactly one label.

The whole operation has an 18-second time limit, and the API applies per-client rate limits.

How to use the NetTools.tech MTA-STS Lookup

1. Open MTA-STS Lookup.
2. Enter the Domain, for example example.com (the domain in your email addresses, not mta-sts.example.com).
3. Press Run MTA-STS Lookup. You can also run /mta-sts example.com in the terminal.
4. Read the TXT and policy details, then the findings list from top to bottom.
5. Use Copy to keep a text version of the result for a ticket or change log.

Understanding the results

Example: testing mode with a provider migration

A lookup for example.com shows:

TXT          v=STSv1; id=20260901
Policy       https://mta-sts.example.com/.well-known/mta-sts.txt (HTTP 200)
Mode         testing
max_age      604800 s
mx patterns  mail.example.com
Actual MX    mail.example.com, mx2.example.net

Findings:

• Info: mode testing — failures are reported (TLS-RPT) but mail is still delivered.
• Warning: MX host not covered by the policy: mx2.example.net.

The backup MX at the new provider was added to DNS but not to the policy. Add mx: mx2.example.net (or mx: *.example.net if all provider hosts share that parent), publish the file, change the id in the TXT record (for example to id=20261017) and run the lookup again. In enforce mode the same mismatch would be an error, because compliant senders would refuse to deliver to mx2.example.net. To compare with what a sender sees:

dig +short TXT _mta-sts.example.com
curl -sS --max-redirs 0 -D - https://mta-sts.example.com/.well-known/mta-sts.txt

Common use cases

• Initial rollout: check record and policy in testing mode, then again after switching to enforce.
• MX changes: run the lookup before and after changing mail providers or adding backup MX hosts.
• Certificate renewals on the mta-sts web host: a failed fetch shows up immediately.
• Audits: document which domains publish MTA-STS and in which mode.
• Health checks: the Email Health Check includes MTA-STS in its overall report.

Troubleshooting

"Policy file: HTTP 301 (redirects are not allowed for MTA-STS policies)"

The web server redirects, often from a catch-all rule that sends every host to www. Serve the file directly at https://mta-sts.<domain>/.well-known/mta-sts.txt.

"Content-Type must be text/plain"

Static hosts sometimes serve .txt files under /.well-known/ as application/octet-stream. Set the content type explicitly for that path.

The policy cannot be fetched

Check that mta-sts.<domain> resolves to a public address, that port 443 is open, and that its certificate is valid for exactly that name. A wildcard certificate for *.example.com covers it; a certificate only for example.com does not. The SSL Certificate Checker can check the certificate separately.

Senders keep using an old policy

You changed the file but not the id in the TXT record. Senders re-fetch only when the id changes or their cached copy expires after max_age.

The lookup passes but TLS-RPT reports failures

MTA-STS Lookup checks the policy, not the TLS on each MX host. Test each MX with the SMTP Test to see whether STARTTLS is offered and the certificate matches the host name.

Common mistakes

• Starting directly in mode: enforce without TLS-RPT reporting.
• Forgetting to update the policy when MX hosts change.
• Editing the policy without changing id.
• Using a wildcard such as *.example.com and expecting it to match a.b.example.com (wildcards cover one label only).
• Serving the policy from a CDN or host that redirects, or with the wrong content type.
• Setting a very short max_age, which removes most of the protection between fetches.

Limitations

• The lookup checks the published record and policy, not whether each MX host actually offers valid TLS; use SMTP Test for that.
• DNS answers come from the public resolvers used by the NetTools.tech server and can be cached; a recent change may not be visible yet.
• The policy is fetched from the NetTools.tech server's network. A web host that behaves differently per region or blocks some networks may give other senders a different result.
• Sender behavior varies: not every sending server supports MTA-STS, and caching means senders may act on an older policy for up to max_age.
• DANE (TLSA records) is a separate mechanism and is not checked here.

Security & privacy

You enter only a public domain name. Internal names such as .local or .internal are rejected, DNS queries go to public resolvers, and the policy fetch only connects to public IP addresses on HTTPS. Nothing is sent to your mail servers, and no email is sent. MTA-STS records and policies are public by design, so the result reveals nothing that senders cannot already see. No credentials are needed or requested.

Related tools

• TLS Reporting (TLS-RPT) – check where TLS failure reports are delivered (guide).
• MX Lookup – see the MX hosts your policy must cover (guide).
• SMTP Test – test STARTTLS and the certificate on each MX host (guide).
• SSL Certificate Checker – check the certificate of the mta-sts web host (guide).
• Email Health Check – MTA-STS together with MX, SPF, DKIM and DMARC (guide).

Summary

MTA-STS tells sending servers to require verified TLS when delivering to your MX hosts, using a _mta-sts TXT record and an HTTPS policy file. The NetTools.tech MTA-STS Lookup reads the record, fetches the policy without redirects like a real sender, validates its syntax and checks that every MX host is covered. Pair it with TLS-RPT and the SMTP Test to confirm that the MX hosts actually meet the policy.