Skip to content
free tool · no signup · no logs

MTA-STS
policy validated.

Enter your domain. We pull the _mta-sts DNS TXT record, fetch the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, parse both, and tell you exactly what works, what's broken, and how to promote from testing to enforce mode safely.

# DNS resolution and HTTPS fetch happen client-simulated for this preview. The result is rendered in your browser only.

# Awaiting input…

what we check

Five validation layers, one verdict.

layer 1

DNS record presence

The TXT record at _mta-sts.<domain> must exist with v=STSv1 and a policy id. Missing or malformed records mean MTA-STS isn't deployed.

layer 2

Policy file fetch

The policy file at /.well-known/mta-sts.txt on the mta-sts subdomain must serve over HTTPS with valid TLS and correct content-type.

layer 3

Policy parse

We parse version, mode, mx: entries, and max_age. Bad syntax or missing required fields fail the check.

layer 4

MX coverage

Every MX host returned by your domain's MX records must match one of the mx: entries in the policy (wildcards allowed). Mismatches mean enforce mode would break your inbound mail.

layer 5

TLS-RPT companion

We check for the optional _smtp._tls TXT record. Without TLS-RPT, you have no visibility into actual TLS connection outcomes. We recommend it for any production MTA-STS deployment.

verdict

Promotion readiness

We tell you whether your current configuration is safe to promote from mode: testing to mode: enforce, or what needs fixing first.

Want the actual implementation, not just the audit?

MTA-STS deployment is one of the included items in any of our SMTP plans. Authentication baseline (SPF, DKIM, DMARC, MTA-STS, TLS-RPT) is set up and documented before first send.

Discuss on Telegram → Read MTA-STS reference
how to read the validator output

MTA-STS has three components; all three must work together.

MTA-STS protects inbound mail to your domain by telling sending servers which MX hosts they should accept and requiring TLS during delivery. The validator checks the three components: the DNS TXT record advertising MTA-STS is in use, the HTTPS-served policy file describing the enforcement details, and the alignment between policy declarations and your actual MX records.

DNS record at _mta-sts.yourdomain.com

A TXT record at _mta-sts.yourdomain.com containing two tags: v=STSv1 declaring the version, and id= containing a unique identifier (typically a timestamp or version string). The id changes when your policy changes; sending servers cache the policy and re-fetch only when id changes. If the validator flags missing DNS record, MTA-STS isn't operational regardless of whether the policy file exists.

HTTPS policy file at mta-sts.yourdomain.com

A text file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Contains the policy mode (none, testing, enforce), MX patterns allowed, and max-age in seconds. Must be served with valid HTTPS certificate (the certificate is what gives MTA-STS its security guarantees; without HTTPS, the policy file could be tampered with).

MX alignment with policy declarations

The MX records declared in the policy file must match your actual MX records. If your policy says only mail.yourdomain.com is allowed but your DNS MX points to backup.yourdomain.com, sending servers will reject delivery to the unlisted MX. Common mismatch: backup MX records present in DNS but not listed in policy. Either update policy to include all legitimate MX hosts, or ensure backup MX hosts are decommissioned.

Policy mode: testing vs enforce

Three modes: none (inactive), testing (failures are reported via TLS-RPT but do not block delivery), enforce (failures block delivery). Most operations should start at testing with TLS-RPT reporting configured, run for 14-30 days reviewing reports, then transition to enforce once reports show no legitimate senders failing.

common findings and fixes

Where MTA-STS deployments commonly break.

FAIL

Policy file not served (404 or DNS not resolving)

mta-sts.yourdomain.com subdomain doesn't exist or returns 404 for the policy path. Fix: configure DNS A or CNAME record pointing to the host serving the policy, ensure the path /.well-known/mta-sts.txt returns 200 OK with the policy content. Common deployment pattern: use same host as your main website with appropriate path routing.

FAIL

Policy file served over HTTP, not HTTPS

HTTP-served policy files are rejected; the security model requires HTTPS to prevent tampering. Common cause: deployment on a host without HTTPS configured, or HTTPS misconfigured (expired certificate, wrong hostname in certificate). Fix: ensure HTTPS with valid certificate covering mta-sts.yourdomain.com.

WARN

id= tag in DNS doesn't match policy file change date

The id= tag should change whenever the policy file changes. If you updated the policy but didn't update id=, sending servers will continue using cached old policy until cache expires. Fix: update id= in DNS whenever you update the policy file. Common pattern: use ISO 8601 date as the id value.

FAIL

MX patterns in policy don't match actual MX records

Policy declares only specific MX hosts but your DNS MX records include other hosts. Sending servers in enforce mode will refuse delivery to MX hosts not in policy. Fix: align policy MX list with DNS MX records, or remove unused MX records from DNS.

WARN

Mode set to enforce without prior testing period

Direct transition from none to enforce without intermediate testing phase. Risky because legitimate senders with TLS issues will fail silently. Fix: set mode to testing with TLS-RPT reporting configured, run for 14-30 days, review reports, then transition to enforce once confident.

WARN

max-age set very short (under 86400 seconds / 24 hours)

Short max-age means sending servers re-fetch policy often, defeating the caching purpose and adding load to your policy server. Conversely, very long max-age (over 7 days) makes policy changes propagate slowly. Industry recommendation: 86400-604800 seconds (1-7 days). Most operations use 86400.

deployment timeline

Step-by-step MTA-STS rollout that produces zero downtime.

MTA-STS deployment can break inbound mail if done in the wrong order. The pattern below has produced zero-downtime rollouts across all the deployments we have completed for customers and on our own infrastructure. The total calendar time runs 4-6 weeks from start to enforce mode.

Week 1: DNS preparation. Verify all MX hostnames resolve correctly and that the certificate chain on each MX is valid and trusted by mainstream receivers (test with openssl s_client against ports 25 and 587 from multiple network locations). Confirm STARTTLS works on every MX hostname. Document any MX that fails these baseline checks; they need to be fixed before MTA-STS publication can happen safely.

Week 2: Policy file deployment. Deploy the policy file at mta-sts.yourdomain.com under /.well-known/mta-sts.txt with mode: testing. Set max_age to a short value initially (1-7 days) so that policy updates propagate quickly during the testing phase. Verify HTTPS serving works correctly from multiple geographic locations. Verify the certificate covers the mta-sts subdomain.

Week 2-3: DNS record publication. Publish the MTA-STS DNS record at _mta-sts.yourdomain.com with TXT content v=STSv1; id=YYYYMMDD000000. The id value must change every time the policy file changes; receivers cache the policy until id changes. Publish a TLS-RPT DNS record at _smtp._tls.yourdomain.com with TXT content v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com for receiving aggregate reports.

Week 3-4: Aggregate report monitoring. Receivers will begin sending TLS-RPT aggregate reports within 24-72 hours of testing-mode publication. Use the TLS-RPT parser on this site to inspect reports as they arrive. Identify any failure categories (STARTTLS unsupported, certificate validation failures, MX policy mismatches, STS policy fetch errors) and address them. Failures during testing mode do not block mail delivery; the goal is to identify and fix issues before transitioning to enforce mode.

Week 4-6: Transition to enforce. Once aggregate reports show clean operation for at least 14 consecutive days with no significant failure categories, update the policy file to mode: enforce and increment the id value in the DNS record. Continue monitoring TLS-RPT reports for the first 2-4 weeks after enforcement to catch any regression. Increase max_age to 604800 (one week) once stable; longer max_age values reduce receiver lookup load but slow propagation of any future policy changes.

2026 receiver adoption

What MTA-STS support looks like across major receivers.

MTA-STS adoption on the sending side (receivers respecting published policies of their outbound destinations) is near-universal among major mailbox providers as of 2026. Gmail, Microsoft 365, Yahoo, AOL, ProtonMail, Fastmail, and all major commercial ESPs honour published MTA-STS policies in enforce mode. Most enterprise email gateways (Mimecast, Proofpoint, Barracuda, Cisco IronPort) also honour MTA-STS by default in current versions.

On the receiving side (domains publishing MTA-STS policies for their own inbound), adoption is more uneven. Major consumer providers all publish policies. Mid-size businesses are mixed; the largest cohort published policies through 2024-2025 driven by security audit requirements and the Gmail-and-Yahoo sender requirements that surfaced TLS handling as a measurable property. Small businesses and personal domains often do not publish policies, which is operationally fine but represents a gap that domain hygiene audits flag.

The structural value of publishing an MTA-STS policy in 2026 is no longer about preventing rare downgrade attacks; it is about signaling domain hygiene to receivers and security scanners. Domains without MTA-STS get downgraded in some reputation models. The structural cost of publishing one is low (one DNS record, one HTTPS policy file, one TLS-RPT recipient mailbox) and the deployment can be made safe through the testing-mode workflow above. We recommend publishing for any domain that handles business email regardless of volume.

questions we get about MTA-STS

Frequently asked.

Does MTA-STS protect outbound mail or inbound?

Inbound. MTA-STS publishes your inbound delivery requirements; sending servers fetch your policy and comply when sending mail to you. The protection applies to mail being delivered to your domain. For outbound protection, your sending infrastructure needs to consult other domains' MTA-STS policies when delivering mail, which most modern MTAs do automatically.

Is MTA-STS required by Gmail/Yahoo new sender requirements?

Not directly required, but recommended. Gmail's February 2024 sender requirements emphasize TLS, authentication, and unsubscribe handling; MTA-STS supports the TLS pillar by ensuring TLS is used consistently for inbound mail. Bulk senders (5K+ daily) benefit from MTA-STS publication; smaller volumes are not penalized for absence.

What's the difference between MTA-STS and DANE?

Both authenticate inbound mail TLS but differently. DANE (DNS-Based Authentication of Named Entities) uses DNSSEC-signed TLSA records to bind certificates to DNS. MTA-STS uses HTTPS-served policy files. DANE requires DNSSEC, which adoption remains limited; MTA-STS doesn't, which is why MTA-STS adoption is broader. They can coexist; sending servers prefer DANE when both are present.

What happens if I deploy MTA-STS wrong?

In testing mode, mail still flows; failures are reported via TLS-RPT but don't block delivery. In enforce mode, misconfiguration blocks legitimate inbound mail. This is why the recommended pattern is to start at testing, validate via TLS-RPT reports for 14-30 days, then transition to enforce only when confident.

Should I deploy MTA-STS even if I don't have many inbound senders?

Yes, MTA-STS protects your domain reputation. Domains without MTA-STS are sometimes flagged as less serious about email security; modern receivers and security scanners increasingly check for MTA-STS as part of domain hygiene assessment. Deployment overhead is small once configured.

Can MTA-STS be hosted on a CDN?

Yes. The policy file is static text served over HTTPS, making CDN hosting a natural fit. Cloudflare, Fastly, CloudFront all work. Ensure the CDN is configured with valid certificate covering mta-sts.yourdomain.com and the path /.well-known/mta-sts.txt returns the policy content with appropriate Content-Type.