Free diagnostic

MTA-STS checker for SMTP transport policy.

Check the MTA-STS DNS signal and HTTPS policy using bounded, redirect-free public-network requests with private-address protection.

Run MTA-STS check Read MTA-STS guide

Validate both publication surfaces

MTA-STS requires a DNS TXT signal and a policy served over HTTPS from the fixed mta-sts hostname. This tool checks both without following redirects or contacting private network addresses.

Start in testing mode and use TLS-RPT to observe failures.
Bump the DNS policy id when the HTTPS policy changes.
Match policy MX patterns to the domain's real receiving infrastructure.

Publication is not transport telemetry

A fetchable policy does not prove that every SMTP connection negotiated TLS successfully. Pair MTA-STS with TLS-RPT guidance and ongoing domain monitoring.

Fundamentals

What is MTA-STS?

MTA-STS (MTA Strict Transport Security, RFC 8461) lets a domain declare that senders must use TLS, with a verified certificate, when delivering its inbound email rather than falling back to cleartext. SMTP's usual upgrade, STARTTLS, is opportunistic: an attacker between two servers can strip it, and both sides often deliver in plain text anyway. An enforcing policy removes that fallback — a supporting sender refuses to deliver rather than deliver without valid TLS. The mechanism has two publication surfaces: a DNS TXT record at _mta-sts.example.com starting v=STSv1 and carrying an id tag senders compare against their cache, and the policy itself — a plain-text file served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt with a version, a mode (none, testing, or enforce), one or more mx patterns naming legitimate receiving hosts, and a max_age controlling sender-side caching. Serving it over HTTPS means forging it requires compromising both DNS and a valid certificate. MTA-STS produces no telemetry about what happened on the wire. TLS-RPT (RFC 8460), a record at _smtp._tls, fills that gap by telling senders where to email aggregate JSON reports of TLS negotiation outcomes. Publish the report address, run MTA-STS in testing mode while reports confirm your MX hosts, then move to enforce — the MTA-STS and TLS-RPT guide walks through the sequence.

Reading the output

How to read your results

This tool runs a live DNS lookup and, if a signal is published, a bounded HTTPS fetch of the policy — no SMTP connection, no login, no retention of the submitted domain. The fetch connects only to public IP addresses, validates the TLS certificate for the mta-sts hostname, refuses redirects, and caps the response at 64 KB.

Status: "pass" means the DNS signal exists and the policy fetched and parsed cleanly. "Warning" means the _mta-sts TXT record is published but the policy could not be fetched or parsed — senders treat the domain as having no usable policy. "Fail" means no v=STSv1 TXT record exists at all.
txtRecords: the exact v=STSv1 records returned by DNS. Read the id tag here — it is the cache token senders compare against their cached copy, and it must change every time you edit the policy file.
policy: the parsed fields — version (must be STSv1), mode (none, testing, or enforce), max_age in seconds, and the mx patterns in order. Each mx pattern is an exact hostname or a wildcard like *.example.com matching one left-most label.
fetchError: when status is "warning", this names the failure — non-public addresses, a redirect, a non-200 status, a non-plain-text response, an oversized or malformed policy, a missing version, an invalid mode, or an invalid max_age.
Limitations: every run restates that the check validates publication and fetchability, not live SMTP transport, and that TLS-RPT reports are needed to observe real delivery failures.
References: a link to RFC 8461, the standard being validated.

Troubleshooting

Common MTA-STS errors and how to fix them

Most MTA-STS failures trace to a handful of publication mistakes, each visible in fetchError or the parsed policy output.

Mode confusion: none tells senders to ignore the policy; testing applies it but keeps delivering (with TLS-RPT reports) on failure; enforce refuses delivery when TLS cannot be established or the MX host is not covered by an mx pattern. Testing forever protects nothing; enforce without report data risks dropped mail.
Stale cached policy: senders cache the policy for max_age and refresh early only when the DNS id changes. Edit the policy without bumping the id and senders enforce the old version for the full max_age. Change the id on every edit — a date or counter works.
mx patterns not matching real MX hosts: in enforce mode a sender matches your published MX exchanges against the policy's mx list; a mismatch is treated as an attack and delivery is refused. Wildcards match exactly one left-most label, so *.example.com covers mail1.example.com but not example.com — list both if you use both. Cross-check with an MX lookup.
Invalid HTTPS certificate on the policy host: the certificate on port 443 of mta-sts.yourdomain must be publicly trusted and valid for that exact hostname. Expired, self-signed, or wrong-hostname certificates all fail the fetch.
max_age too short or too long: very short values leave senders with an expired cache and nothing to apply when the policy host is briefly unreachable; RFC 8461 advises preferring values as long as is practical because short caches weaken protection. Very long values, however, keep a mistaken enforce policy dropping your mail for weeks after you fix it. The RFC's own examples use one week and fifteen days.
Policy behind a redirect: the policy must be served with a 200 status from the well-known URL itself. This tool — like enforcing senders — refuses redirect chains, so a 301 to another hostname or a CMS landing page fails the fetch. Serve the file directly.

Providers

Per-provider MTA-STS notes

MTA-STS only bites where the sending side honors it, so provider support determines what an enforce policy actually buys. Support is widening but not universal.

Gmail: Google was the first major mailbox provider to adopt the standard and supports MTA-STS on outbound delivery to domains publishing enforcing policies, as well as publishing policies for its own domains. An enforce policy genuinely changes how Gmail treats a failed TLS negotiation with your MX.
Microsoft 365 / Outlook: Microsoft announced MTA-STS support for Exchange Online, starting with validating sending domains' policies on inbound mail and extending toward outbound delivery. Rollout has been staged — verify the current state in Microsoft's documentation rather than assuming parity with Gmail.
Yahoo: Yahoo publishes far less public detail about MTA-STS handling than Google or Microsoft. Treat its enforcement as unverified and rely on TLS-RPT data to see what its senders negotiate with your MX hosts.
DANE as the alternative: DANE for SMTP (RFC 7672) reaches a similar guarantee by pinning certificate information in DNSSEC-signed TLSA records, with no HTTPS host to maintain — but it requires DNSSEC on your zone and MX hostnames, which many providers still do not support. The mechanisms are independent; some operators publish both.

Comparison

WillItInbox vs MXToolbox vs dmarcian

All three can tell you something about a domain's transport security, but they are built around different jobs. MXToolbox is a broad DNS toolbox with ad-supported free lookups and paid monitoring from $129 per month. dmarcian is a DMARC-focused reporting suite. WillItInbox runs this check free with no login — an SSRF-safe public-network fetch that retains nothing you submit — with optional domain monitoring for drift alerts instead of one-off evidence.

Capability	WillItInbox	MXToolbox	dmarcian
MTA-STS check	Free, no login, live DNS + HTTPS fetch	Free, one-off, ad-supported lookup	DMARC-focused suite
Fetch safety model	Public addresses only, no redirects	Varies by tool	Varies by tool
Adjacent checks (MX, SPF, DMARC)	Free tools in one place	Separate free lookups	DMARC reporting platform
Login required	No for public checks	No for free lookups	Account-oriented platform
Ads	None	Ads on free tier	None
Monitoring beyond one-off checks	Optional domain monitoring for drift	Paid plans from $129/mo	Reporting platform
Submitted-domain retention	None for public checks	Varies by product	Varies by product

Live diagnostic

Check current evidence

This anonymous tool is rate limited and does not retain submitted input. It reports observable evidence without promising delivery, authentication alignment, or inbox placement.

No SMTP mailbox probing, account lookup, or tenant data is used.

Enter an input to see current evidence, limitations, official references, and the relevant next step.

MTA-STS and TLS-RPT

Implement policy and reporting together.

Monitor transport policy

Track MTA-STS, TLS, MX, and adjacent domain evidence over time.

MX lookup

Inspect the policy's MX dependencies.

Domain monitoring

Track transport-policy drift.

Developers use case

See how this workflow applies to teams running developer testing, sdks, webhooks, and ci/cd.

Deliverability Qa CI/CD Willitinbox API guide

Read the supporting guide for practical context around developer testing, sdks, webhooks, and ci/cd.

Validation API example

Review request and response patterns for single validation, bulk verification, suppression, and webhook flows.

API docs

Use the REST API reference when validation, bulk jobs, webhooks, reports, or usage need to run from your own systems.

Webhook docs

Verify signed callbacks for bulk jobs, reports, sandbox events, delivery logs, and operational automation.

SDK docs

Use the Node and Python clients for validation, sandbox capture, report access, and webhook verification.

Pricing

Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.

FAQ

What is the difference between testing and enforce mode?

Testing mode asks senders to apply your policy but keep delivering when it would fail, reporting failures via TLS-RPT — delivery is unchanged. Enforce mode asks senders to refuse delivery when TLS cannot be established with a valid certificate or the MX host is not covered by your mx patterns. The intended path is testing with reports first, then enforce once reports confirm your infrastructure is covered.

Do I need MTA-STS if I already use TLS?

Yes, if you want TLS mandatory rather than opportunistic. STARTTLS can be stripped by a network attacker because servers commonly fall back to cleartext when the upgrade fails, and certificates are often not validated. MTA-STS publishes your requirement in advance so a supporting sender refuses to deliver instead of falling back. Your TLS configuration still has to be correct — MTA-STS makes it enforceable, not optional.

What is TLS-RPT and do I need it?

TLS-RPT (RFC 8460) is a DNS record at _smtp._tls.yourdomain that tells senders where to email aggregate JSON reports about TLS negotiation successes and failures with your MX hosts. MTA-STS publishes your requirement but produces no feedback, so without TLS-RPT you cannot see whether enforce mode would drop legitimate mail. Publish it before or alongside MTA-STS, especially while in testing mode.

Why does my policy fetch fail?

The common causes, all reported in this tool's fetchError field: the mta-sts hostname does not resolve to public addresses; the endpoint redirects instead of serving the policy; the HTTP status is not 200; the response is not plain text; the certificate is expired, self-signed, or for a different name; or the file is malformed — missing version STSv1, an invalid mode, or a non-numeric max_age. Serve the file directly at the well-known URL with a valid certificate.

Does MTA-STS affect sending or receiving?

Receiving. Your policy tells other people's sending servers how they must connect when delivering mail to your domain. It does nothing for your own outbound mail — for that, the recipient's policy matters. This is why enforce-mode mistakes hurt: a policy that excludes your real MX hosts tells supporting senders to stop delivering your inbound mail.

Is MTA-STS the same as DANE?

No. Both aim to prevent downgrade and interception attacks on SMTP, but they work differently. MTA-STS publishes a policy over HTTPS and needs no DNSSEC; DANE pins certificate information in DNSSEC-signed TLSA records and needs no HTTPS host. DANE fails where DNSSEC is not deployed, and MTA-STS fails where the policy host or its certificate is broken. They are independent, and some domains publish both.