MTA-STS Check
MTA-STS Check helps you validate mta strict transport security policy, for email authentication analysis, policy checks, and delivery troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
The MTA-STS checker performs the two lookups a sending server would make: it reads the TXT record at _mta-sts.<domain> and looks for v=STSv1, then fetches https://mta-sts.<domain>/.well-known/mta-sts.txt over HTTPS without following redirects. From the policy file it extracts mode, max_age (shown in days) and every mx: pattern, and grades the result as a pass only when the policy is in enforce mode.
Why It Matters
- →Downgrade protection: Without MTA-STS, an attacker on the network path can strip STARTTLS and read inbound mail in plaintext; enforce mode makes senders refuse that downgrade.
- →MX hijack defense: Spoofed DNS answers pointing your mail to a rogue host fail because the policy lists which MX names are legitimate and requires a valid certificate for them.
- →Compliance evidence: Auditors and cyber-insurance questionnaires increasingly ask whether inbound SMTP enforces TLS, and an enforce policy is a direct, checkable answer.
- →Safe migrations: Testing mode lets you deploy the policy, collect TLS-RPT reports and spot certificate or MX mismatches before any mail is rejected.
- →Provider changes: When you move from one mail host to another, an outdated mx: list in enforce mode can cause senders to defer your mail, so verifying the policy is part of the cutover.
How to Read Results
- WARN 'MTA-STS not configured': Neither the _mta-sts TXT record nor the policy file was found.
- WARN 'DNS record found but policy file is missing or unreachable': The TXT exists but the HTTPS fetch failed, returned a non-2xx status or a redirect; senders treat this as no policy.
- mode: enforce yields PASS; testing or none yields WARN with a suggestion to move to enforce once reports are clean.
- maxAgeDays: max_age converted from seconds to days. RFC 8461 allows up to 31557600 seconds (about 365 days); one to two weeks is typical while you are still changing things.
- mxPatterns: Every mx: line found. Each of your real MX hostnames must match one of these, either exactly or via a leading wildcard such as *.mail.example.net.
- dnsRecord flag: If this is false while a policy was found, senders will never discover the policy, because the TXT record is what triggers the fetch.
Technical Background
SMTP MTA Strict Transport Security, standardized in RFC 8461, lets a receiving domain declare that its inbound mail servers support TLS with certificates that browsers would also trust. It uses two artifacts. The first is a DNS TXT record at _mta-sts.example.com such as v=STSv1; id=20261010T1200;. The id is 1 to 32 alphanumeric characters and acts as a version tag; senders compare it with the id they cached and re-fetch the policy only when it changes. If more than one v=STSv1 record is returned, senders must assume there is no policy.
The second artifact is a plain-text policy served at https://mta-sts.example.com/.well-known/mta-sts.txt. The host must present a publicly trusted certificate valid for the mta-sts name, the response should be text/plain, and HTTP redirects must not be followed. A typical policy reads, one field per line: version: STSv1, mode: enforce, mx: mx1.example.com, mx: *.mail.protection.example.net, max_age: 1209600. Wildcards are allowed only as the left-most label and match a single label.
The mode controls what senders do when validation fails. With enforce, a sending MTA that cannot establish TLS to an MX matching the patterns, or that sees an invalid or mismatched certificate, must not deliver to that host and will retry or bounce. With testing, it delivers anyway but should send a TLS-RPT report (RFC 8460) describing the failure. With none, previously cached policies are cancelled. max_age tells senders how long to keep the policy, which is what protects later connections even when DNS is being tampered with.
The weak point is the first contact: a sender that has never cached your policy can be fooled by an attacker who blocks the TXT lookup, so MTA-STS is trust-on-first-use. DANE for SMTP (RFC 7672) avoids that gap with DNSSEC-signed TLSA records, and both mechanisms can coexist. Large mailbox providers fetch MTA-STS policies, which makes it the practical option for domains whose DNS host does not support DNSSEC.
The safe rollout path is: publish TLS-RPT, publish the policy in testing mode with a short max_age such as 86400, review reports for a couple of weeks, switch to enforce with a longer max_age, and change the id in DNS every time the file changes. Our tool reads the TXT record and policy exactly as described, but it does not cross-check the mx: patterns against your live MX records or inspect the certificates on your MX hosts, so run the MX lookup and an SMTP STARTTLS test as well.
Common Errors and How to Fix Them
- ProblemThe policy file was edited (new MX added) but the id in the _mta-sts TXT record stayed the same, so senders keep the old cached policy and reject the new MX.
- FixChange the id value every time the policy changes, for example to a timestamp like 20261010T1500, and keep the old MX accepting mail until the previous max_age expires.
- Problemmta-sts.example.com has no certificate or uses the wildcard of a different domain, so the policy fetch fails and senders ignore the policy.
- FixIssue a publicly trusted certificate that explicitly covers mta-sts.example.com (or a matching wildcard) and serve the file directly over HTTPS with status 200.
- ProblemThe web server redirects /.well-known/mta-sts.txt to www or to a trailing-slash URL.
- FixRFC 8461 forbids following redirects. Serve the file at the exact path on the mta-sts host and disable any global redirect rules for that virtual host.
- ProblemPolicy set to enforce while one MX presents a self-signed certificate or a hostname not listed in mx: lines.
- FixFix the certificate or add the correct mx: pattern, switch to testing mode with a new id, confirm clean TLS-RPT reports, then return to enforce.
- ProblemRemoving MTA-STS by deleting the TXT record and policy file, which leaves senders with a cached enforce policy for up to max_age.
- FixPublish mode: none with a new id first, wait at least the previous max_age, and only then delete the record and file.
Frequently Asked Questions
What is the difference between MTA-STS testing and enforce mode?
In testing mode, senders validate TLS and certificates against your policy but still deliver mail if checks fail, ideally sending a TLS-RPT report describing the problem. In enforce mode, a failed validation means the sender will not deliver to that MX and will retry later or bounce. Start in testing, review reports, then switch to enforce.
What max_age should I use for MTA-STS?
During rollout, use a short value such as 86400 seconds (one day) so mistakes expire quickly. Once the policy is stable in enforce mode, many operators use 604800 (one week) to 1209600 (two weeks), and some go up to the RFC maximum of 31557600. Longer values offer more protection against first-contact attacks but slow down recovery from errors.
Do I need to change the id every time I edit the policy?
Yes. Senders only re-download the policy when the id in the _mta-sts TXT record differs from the one they cached. If you change the file but not the id, senders keep using the old policy until max_age runs out, which can cause rejected mail after an MX migration. A timestamp such as 20261010T1500 is an easy convention.
Can I host the MTA-STS policy file on a CDN or static site?
Yes, as long as the host mta-sts.yourdomain answers HTTPS with a valid certificate for that exact name, returns status 200 at /.well-known/mta-sts.txt and does not redirect. Many teams use a CNAME to a static hosting service. Check that the platform does not add trailing-slash or www redirects, because senders will not follow them.
Is MTA-STS better than DANE?
They solve the same problem differently. MTA-STS relies on HTTPS and public certificate authorities, works without DNSSEC and is honored by large mailbox providers, but it trusts the first lookup. DANE uses DNSSEC-signed TLSA records and avoids that first-contact gap, but your zone and the sender's resolver must support DNSSEC. Publishing both is common.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/mta-sts
curl -X POST https://epcybertools.com/api/tools/mta-sts \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Discovery record (look for v=STSv1 and the id)
dig +short TXT _mta-sts.example.com
# Fetch the policy exactly as senders do (no redirects)
curl -s --max-redirs 0 https://mta-sts.example.com/.well-known/mta-sts.txt