MTA-STS Checker
Validate a domain's MTA-STS configuration — check the DNS TXT record, verify the policy file is reachable over HTTPS, inspect mode and MX patterns, and get a plain-English security assessment with actionable recommendations.
What is MTA-STS?
MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard defined in RFC 8461 that lets domain owners declare a policy requiring sending mail servers to authenticate TLS when delivering email to their domain. Without MTA-STS, SMTP uses opportunistic TLS — encryption is attempted but can be silently downgraded to plaintext if an attacker is positioned between the sender and receiver. This type of attack, called a TLS downgrade or SMTP STARTTLS stripping attack, is undetectable by the mail sender and allows an attacker to read or modify email in transit.
MTA-STS prevents this by requiring senders to verify the receiving mail server's TLS certificate against published MX patterns before delivering email. If the certificate is invalid, expired, or the connection cannot be made over authenticated TLS, the message is not delivered — the sender refuses to deliver to an unauthenticated connection.
For email admins and MSPs: MTA-STS complements SPF, DKIM, and DMARC but protects a different layer. While DMARC prevents spoofing, MTA-STS protects the SMTP transport channel itself. A domain with MTA-STS enforce mode, DMARC reject, and TLS-RPT reporting has a hardened outbound and inbound email security posture. This tool lets you verify MTA-STS in seconds before an audit or onboarding call.
How MTA-STS works
MTA-STS uses two components that must both be correctly configured for the standard to provide protection. When a sending mail server prepares to deliver email to your domain, it performs these steps:
Step 1 — DNS TXT record discovery
The sender queries _mta-sts.yourdomain.com for a TXT record. If found with a valid v=STSv1 value and an id= field, the sender knows to look for a policy file. The id value is used to detect policy changes so the sender can invalidate a cached policy.
_mta-sts.example.com. TXT "v=STSv1; id=20250601T120000"
Step 2 — Policy file fetch
The sender fetches the policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS. The HTTPS requirement is deliberate — the policy file itself must be protected by TLS so an attacker cannot modify it to disable enforcement. The policy is cached for max_age seconds.
version: STSv1 mode: enforce mx: mail.example.com mx: *.example.com max_age: 604800
Step 3 — Policy enforcement
With the policy cached, the sender connects to your MX server and starts a TLS handshake. In enforce mode, the sender validates that the certificate is trusted by a public CA, has not expired, and that the MX hostname matches one of the mx: patterns in the policy. If any check fails, delivery is aborted and the sender retries (potentially triggering a TLS-RPT report).
MX pattern matching
MX patterns in the policy can be exact hostnames or wildcard patterns beginning with *.. For example, *.example.com matches mail.example.com and smtp.example.com but not example.com itself. Wildcards only match a single label — *.example.com does not match sub.mail.example.com.
MTA-STS policy modes
The mode field controls whether senders must enforce the policy or just report failures.
Choose your mode carefully — switching to enforce without first validating in testing mode can interrupt email delivery.
| Mode | Enforcement | When to use | Score impact |
|---|---|---|---|
enforce |
Full enforcement | When all MX servers have valid TLS certificates and MX patterns are correct. Senders reject non-compliant delivery. | Maximum — 30 pts |
testing |
Report only | During initial deployment. Senders report failures via TLS-RPT but still deliver mail. Use to detect issues before enforcing. | Partial — 15 pts |
none |
Disabled | To withdraw a previously published policy. Signals to senders that enforcement is suspended. Same protection as no MTA-STS. | Zero — 0 pts |
MTA-STS and TLS-RPT
MTA-STS works best alongside TLS-RPT (TLS Reporting, RFC 8460). TLS-RPT instructs
sending mail servers to send daily reports about TLS connection issues to a designated
address. These reports are critical during the testing phase — they reveal
whether any legitimate senders are experiencing certificate failures before you switch
to enforce mode and potentially interrupt delivery.
To publish a TLS-RPT record, add a TXT record at _smtp._tls.yourdomain.com:
v=TLSRPTv1; rua=mailto:[email protected]
Major email providers (Google, Microsoft, Yahoo) send TLS-RPT reports. Services such as Report URI, Postmark, and DMARC Analyzer can aggregate and visualize these reports, making it practical to monitor TLS delivery health across all senders.
Where MTA-STS fits in the email security stack
A fully hardened email configuration requires multiple standards working together. MTA-STS is one layer in a layered defence:
Outbound email authentication
- SPF — Specifies which servers are authorised to send email on behalf of your domain. Prevents simple spoofing.
- DKIM — Cryptographically signs outbound messages so receivers can verify they are authentic and unmodified.
- DMARC — Ties SPF and DKIM together. Specifies what to do with mail that fails authentication (reject, quarantine, report).
Inbound delivery channel protection
- MTA-STS (this tool) — Requires senders to authenticate TLS when delivering email to your MX servers. Prevents TLS downgrade attacks.
- TLS-RPT — Collects reports from senders about TLS delivery failures. Gives visibility into MTA-STS enforcement.
- DNSSEC — Protects the integrity of DNS records that senders query (MX, _mta-sts TXT). Prevents DNS spoofing from undermining MTA-STS discovery.
Implementation order: Start with SPF, DKIM, and DMARC (p=none → quarantine → reject). Once DMARC is in enforce mode, add MTA-STS in testing mode with TLS-RPT reporting, monitor for 2–4 weeks, then switch MTA-STS to enforce mode. This staged approach avoids delivery disruptions.
MTA-STS protects transport — not message content
MTA-STS is a transport security standard. It protects the SMTP connection between sending and receiving mail servers — ensuring that connection is encrypted and that the receiving server is who it claims to be. It does not encrypt the content of messages stored in mailboxes, and it does not prevent the receiving email provider from reading messages they store.
What MTA-STS protects
- SMTP delivery channel — Requires authenticated TLS between the sending and receiving mail server during the delivery handoff.
- TLS downgrade attacks — Prevents a network attacker from stripping STARTTLS and forcing plaintext delivery.
- Delivery to the wrong server — Certificate validation ensures the connection is made to the actual mail server, not an impostor.
Example: Microsoft 365 sending to Gmail — MTA-STS ensures that delivery hop is over verified TLS.
What MTA-STS does not protect
- Message content at rest — Once delivered, messages are stored and readable by the receiving mail provider. MTA-STS has no bearing on this.
- End-to-end encryption — Only PGP or S/MIME provide end-to-end encrypted message content that the mail provider cannot read.
- Sender authentication — MTA-STS does not verify that the sender is who they claim to be. That is the role of SPF, DKIM, and DMARC.
End-to-end encryption (PGP/S-MIME) protects message content. MTA-STS and PGP/S-MIME are complementary, not alternatives.
Practical implication: A domain without MTA-STS is not necessarily transmitting email in plaintext — most mail servers negotiate opportunistic TLS regardless. What MTA-STS adds is the requirement that TLS be authenticated and undowngradeable. The absence of MTA-STS means a delivery-path attacker could potentially intercept or modify the SMTP session; it does not mean email is routinely sent unencrypted.
Frequently asked questions
What is MTA-STS and why does it matter?
MTA-STS is an email security standard that requires sending mail servers to authenticate TLS when delivering email to your domain. Without it, SMTP uses opportunistic TLS — encryption is attempted but can be stripped by a network attacker, exposing email content and enabling message tampering. MTA-STS closes this gap by requiring that the receiving mail server present a valid, trusted TLS certificate matching the published MX patterns. In enforce mode, senders refuse to deliver to any server that fails this check.
How do I publish an MTA-STS policy?
MTA-STS requires three steps. First, create a policy file and serve it at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS with a valid TLS certificate. The policy file contains version, mode, mx entries, and max_age. Second, add a DNS TXT record at _mta-sts.yourdomain.com with the value v=STSv1; id=YYYYMMDD. Third, ensure the mta-sts subdomain has a valid HTTPS certificate — wildcard certificates covering *.yourdomain.com work. Cloudflare Pages, GitHub Pages, and Netlify can all serve the policy file with automatic TLS.
What should I set max_age to?
During initial setup and testing, use a short max_age like 300 seconds (5 minutes) so senders quickly pick up any changes you make. Once the configuration is confirmed correct and you switch to enforce mode, increase max_age to at least 86400 seconds (1 day) and ideally 604800 seconds (7 days) or 2592000 seconds (30 days). A longer max_age provides a grace period if your policy server becomes temporarily unavailable — senders continue using the cached policy rather than failing delivery.
Why does the policy file need HTTPS?
The policy file must be served over HTTPS because its integrity depends on TLS protection. If HTTP were permitted, an attacker who can intercept traffic between the sending server and your policy server could modify the policy to change the mode to "none" or remove MX patterns, effectively disabling MTA-STS protection. By requiring HTTPS with a valid trusted certificate, the policy file itself is authenticated and tamper-evident. The mta-sts subdomain needs its own valid TLS certificate — a wildcard certificate covering *.yourdomain.com satisfies this requirement.
Does MTA-STS affect outbound email I send?
MTA-STS affects how sending mail servers deliver email to your domain (inbound delivery). It does not directly affect email you send outbound, unless your sending mail server honours MTA-STS policies for destination domains. Most modern mail transfer agents (Google Workspace, Microsoft 365, Postfix with MTA-STS support) respect MTA-STS policies when sending email and authenticate TLS for destinations that publish enforce mode policies. This means your outbound email to MTA-STS-protected domains is also protected from downgrade attacks.
What happens if my MX server's TLS certificate expires?
If your MX server's TLS certificate expires while you have MTA-STS in enforce mode, sending mail servers that honour the policy will refuse to deliver email to your domain. This can cause complete email delivery failure for your domain from major providers like Google and Microsoft. Always use auto-renewing TLS certificates (Let's Encrypt with certbot or acme.sh, or managed certificates from your mail provider) for your MX servers. Monitor certificate expiry alongside MTA-STS configuration.
How does the id field in the TXT record work?
The id field in the _mta-sts TXT record is a version identifier for the policy. When a sending server has cached your MTA-STS policy, it periodically checks the TXT record. If the id value has changed, the sender re-fetches the policy file to get the updated version. This mechanism allows senders to detect policy changes quickly without polling the policy file on every delivery. Update the id value whenever you change the policy file — a timestamp format like 20250601T120000 works well and makes it easy to track when changes were made.
Does MTA-STS replace DANE TLSA records?
MTA-STS and DANE (DNS-based Authentication of Named Entities) are different approaches to the same problem. DANE uses TLSA DNS records protected by DNSSEC to pin TLS certificates for mail servers, while MTA-STS uses an HTTPS-served policy file. Both protect SMTP delivery channels from TLS downgrade attacks. MTA-STS is easier to deploy because it does not require DNSSEC on your domain, and major providers like Google and Microsoft support MTA-STS but not DANE. DANE requires DNSSEC and is primarily used by security-focused organisations and European infrastructure. MTA-STS is the more practical choice for most domains.
What does this tool check?
This tool performs two checks from the Cloudflare edge: it queries the DNS TXT record at _mta-sts.yourdomain.com using Cloudflare's DNS-over-HTTPS resolver, and it fetches the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt directly over HTTPS. It validates TXT record syntax (v=STSv1, id format), policy file reachability (HTTP status, TLS success), policy content (version, mode, MX patterns, max_age), generates a security score from 0–100, and provides plain-English findings and actionable recommendations.