Free MTA-STS Checker

Verify your domain's MTA-STS policy, MX coverage and TLS-RPT reporting — and catch the misconfigurations that leave inbound email open to downgrade attacks.

Check a domain

Enter the domain you receive email on — we check its MTA-STS announcement, policy file, MX coverage and TLS-RPT record.

Privacy: we query public DNS (_mta-sts and _smtp._tls TXT, plus MX records) and fetch only https://mta-sts.<your-domain>/.well-known/mta-sts.txt over HTTPS. Checks run on demand and results are not stored.

How the MTA-STS check works

Read the DNS announcement

We look up the TXT record at _mta-sts.<domain> and validate that exactly one v=STSv1 record with an id tag exists — this is how senders discover your policy.

Fetch the policy over HTTPS

We retrieve the policy from the fixed RFC 8461 location, https://mta-sts.<domain>/.well-known/mta-sts.txt, and parse its version, mode, mx patterns and max_age fields.

Match MX hosts against the policy

Your live MX records are compared against every policy mx pattern, with exact and wildcard matching, so uncovered mail servers are flagged before senders refuse them.

Check TLS-RPT reporting

We read _smtp._tls.<domain> for a v=TLSRPTv1 record so you know whether senders can report TLS failures back to you.

What this tool does and does not tell you

  • This validates your published MTA-STS and TLS-RPT configuration. It does not open an SMTP connection or perform a STARTTLS delivery test, and it does not verify the TLS certificates on your MX hosts.
  • A passing result means the configuration is consistent — it is not a guarantee that every sender supports MTA-STS or that mail will always be encrypted in transit.
  • Whether a policy id is stale can only be detected against a previously known id; this stateless checker cannot tell when your policy last changed.
  • DNS or HTTPS timeouts are shown as unknown and are never counted as passing. Re-run the check if your DNS provider or policy host was briefly unreachable.
  • Wildcard mx patterns such as *.example.com match subdomains only — never the bare domain itself — exactly as RFC 8461 defines.

Related free tools

DMARC Record Checker

Validate your DMARC policy, alignment modes and reporting addresses against RFC 9989.

Open tool

SPF Record Checker

Parse and recursively analyze your SPF record, including lookup limits and include chains.

Open tool

DNS Record Checker

Look up A, AAAA, MX, TXT, NS, CAA and more record types for any domain in one place.

Open tool

Frequently Asked Questions

What is MTA-STS?

MTA-STS (RFC 8461) lets a domain publish a policy telling sending mail servers that inbound email must be delivered over TLS with valid certificates. It closes the downgrade and interception gaps of opportunistic STARTTLS, which by default can be stripped or redirected by an attacker on the network path.

What do the enforce, testing and none policy modes mean?

In "enforce" mode, senders must deliver over TLS to MX hosts matching the policy, or fail delivery. "testing" mode asks senders to report failures via TLS-RPT but still deliver, so you can validate safely. "none" disables the policy. The usual rollout is testing first, then enforce once reports look clean.

What is TLS-RPT and do I need it?

TLS-RPT (RFC 8460) is a companion reporting mechanism. A TXT record at _smtp._tls.<domain> tells senders where to email daily reports about TLS negotiation successes and failures. It is optional, but without it you have no visibility into whether your MTA-STS policy is causing delivery problems.

Does this tool send a test email to my domain?

No. The checker validates your published configuration only: the _mta-sts TXT record, the HTTPS policy file at mta-sts.<domain>, your live MX records compared against the policy patterns, and the _smtp._tls TLS-RPT record. It never opens an SMTP connection and does not perform a STARTTLS delivery test, so certificate validity on your MX hosts is not verified here.

Why must my MX records match the policy?

In enforce mode, a sending server refuses to deliver to any MX host that does not match an mx pattern in your policy. If you add or change MX providers without updating the policy — or update the policy without bumping the id in the DNS record — legitimate mail can be rejected by strict senders.

How do I set up MTA-STS from scratch?

Host a plain-text policy at https://mta-sts.<domain>/.well-known/mta-sts.txt with version, mode, mx and max_age lines, then publish one TXT record at _mta-sts.<domain> containing v=STSv1 and an id you change whenever the policy changes. Add a TLS-RPT record so you can watch for problems, start in testing mode, and move to enforce when confident.

Increase Your Sales Right Now

Automate Sales Outreach & Get Booked!

Start Free Trial

(14 Day Free Trial, No CC Required)