Free MTA-STS Checker

Why check your MTA-STS

SMTP transport uses TLS opportunistically: if encryption fails, the connection silently falls back to cleartext. An attacker in a man-in-the-middle position can strip the STARTTLS banner and force your emails over the wire in plaintext.

MTA-STS (RFC 8461) closes this gap. It publishes an HTTPS-served policy backed by public PKI that tells sending MTAs to refuse any connection without valid TLS. It is the missing layer that blocks downgrade attacks and TLS spoofing.

Verifying your configuration before switching to enforce is critical:

• Broken policy → legitimate emails may be blocked
• Incomplete MX patterns → some servers remain vulnerable
• Expired certificate → the policy becomes invalid and sending MTAs revert to opportunistic TLS

Common use cases:

• After publication → confirm DNS, HTTPS policy, and TLS are consistent
• Before mode: enforce → make sure no legitimate MX is excluded
• Security audit → validate protection against TLS downgrade

How to use this checker in 3 steps

Step 1: enter the domain to analyze

Enter the domain exactly as it appears in your email addresses:

• captaindns.com (main domain)
• marketing.captaindns.com (subdomain if you send from a subdomain)

The tool automatically queries _mta-sts.domain, fetches https://mta-sts.domain/.well-known/mta-sts.txt, and compares patterns against MX records.

Step 2: analyze the results

The checker displays:

Step 3: fix the flagged issues

Results are classified by severity:

• Critical → the policy is unusable, sending MTAs ignore it
• Warning → functional but exposes you to risk or partial protection
• Info → best practice, non-blocking

Fix DNS or the policy file, wait for propagation, then re-run the checker.

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) is a mechanism that:

1. Publishes an HTTPS policy declaring which MX hosts support TLS
2. Enforces TLS encryption between sending and receiving MTAs
3. Blocks downgrade attacks that strip STARTTLS

The architecture combines three elements:

Example DNS record:

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Example policy:

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

Difference vs DANE: MTA-STS relies on public PKI (certificate authorities), DANE relies on DNSSEC and TLSA records. Both mechanisms are compatible and can be deployed together.

What the checker verifies

Seven dimensions run in parallel to produce a 0-100 score:

Published DNS record

Policy file fetch

Policy syntax

MX server coverage

All resolved MX hosts for the domain must match at least one pattern:

• Direct match: mx: mail.captaindns.com covers mail.captaindns.com
• Wildcard limited to one label: *.mail.captaindns.com covers eu.mail.captaindns.com but not mail.captaindns.com

TLS certificate validity

The mta-sts.domain subdomain is probed over HTTPS:

• Certificate not expired
• Hostname present in SAN
• Full chain to a recognized CA
• Recent TLS version (1.2 minimum)

DNS and policy consistency

The DNS ID and the served policy ID must match. A mismatch indicates a partial update dangerous for sending MTA caches.

TLS-RPT presence

The checker flags missing _smtp._tls (TLS-RPT, RFC 8460) records. Without TLS-RPT, you'll never know if the policy is causing silent delivery failures.

Common diagnostics and solutions

Policy unreachable (policy_fetch_failed)

Cause: the mta-sts.domain subdomain does not respond, does not serve HTTPS, or returns an HTTP error.

Solutions:

1. Verify that mta-sts.domain resolves in DNS (A or CNAME)
2. Confirm a valid TLS certificate is served (Let's Encrypt, autocert, etc.)
3. Confirm /.well-known/mta-sts.txt returns 200 OK with text/plain

Invalid TLS certificate (cert_invalid)

Cause: expired certificate, self-signed, hostname not covered by SAN, or incomplete chain.

Solutions:

1. Renew the certificate before expiry
2. Include mta-sts.domain in the SAN
3. Serve the complete intermediate chain

Missing DNS record (missing_record)

Cause: no TXT record exists at _mta-sts.domain.

Solution: publish

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Policy disabled (mode_none)

Cause: mode: none indicates MTA-STS is advertised but not effective.

Solution: switch to mode: testing after the initial publication, then mode: enforce once TLS-RPT is clean.

Partial MX coverage (mx_partial_match)

Cause: one or more resolved MX hosts do not match any pattern in the policy.

Solution: list each MX host explicitly or use a broader wildcard that fits your infrastructure.

TLS-RPT missing (tls_rpt_missing)

Cause: no _smtp._tls.domain record is published.

Solution: publish

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Progression from testing to enforce

Phase 1: initial publication in testing mode

version: STSv1
mode: testing
mx: mail.captaindns.com
max_age: 86400

• Sending MTAs report TLS failures via TLS-RPT without blocking delivery
• Keep max_age short (1 to 7 days) to iterate quickly
• Collect TLS-RPT reports for 2 to 4 weeks

Phase 2: stabilization and observation

During this period, check:

• No legitimate MX excluded (TLS-RPT would report mx-mismatch failures)
• No certificate problems on MX hosts (TLS-RPT would report certificate-not-trusted)
• No sending MTA struggling (empty or null reports)

Phase 3: switching to enforce mode

version: STSv1
mode: enforce
mx: mail.captaindns.com
max_age: 604800

• Extend max_age (7 days minimum, up to 1 year)
• Monitor TLS-RPT continuously: failures now become non-delivery
• Prepare a rollback plan (revert to testing quickly if needed)

Common pitfalls:

• max_age too short → sending MTAs re-fetch the policy too often, useless load
• max_age too long → an MX change takes weeks to propagate
• Incomplete MX patterns → legitimate emails are silently rejected

MTA-STS vs DANE

Both mechanisms protect SMTP transport from downgrade attacks but take different approaches.

When to choose MTA-STS: you don't have DNSSEC, or you want a quick rollout with minimal operational overhead.

When to choose DANE: your domain is already DNSSEC-signed and you want the extra guarantee of cryptographic pinning.

Both are compatible and can be deployed in parallel. Sending MTAs pick the one they know how to handle.

Complementary tools and resources

Resources:

• MTA-STS: the complete guide to securing your email transport
• MTA-STS troubleshooting guide
• Moving MTA-STS from testing to enforce
• MTA-STS vs DANE: comparison
• TLS-RPT: the complete guide
• RFC 8461 - SMTP MTA Strict Transport Security
• RFC 8460 - SMTP TLS Reporting