Check a domain’s MTA-STS TXT record, its policy file, and its TLS-RPT record in one pass. Validated against RFC 8461 and RFC 8460. Powered by Google Public DNS.
What Is MTA-STS?
MTA-STS (RFC 8461) lets a domain require TLS encryption for inbound mail. It uses two parts: a DNS TXT record at _mta-sts and a policy file hosted over HTTPS. In enforce mode, supporting senders refuse to deliver mail over unencrypted connections.
SMTP predates modern encryption. Mail servers negotiate TLS through STARTTLS, but that upgrade is opportunistic. An attacker sitting between two servers can strip the STARTTLS offer. Both servers then fall back to plaintext without either side noticing. MTA-STS closes that hole. It gives your domain a way to declare, in advance, that mail to you must travel over verified TLS.
The mechanism has two published pieces. First, a TXT record at _mta-sts.yourdomain.com containing a version tag and a policy id. Second, a plain-text policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The policy names your legitimate MX hosts, sets a mode, and sets a cache lifetime. Sending servers fetch the policy over HTTPS, which anchors trust in the certificate authority system rather than in DNS alone.
What Is TLS-RPT?
TLS-RPT (RFC 8460) is the reporting companion to MTA-STS. A single TXT record at _smtp._tls tells sending servers where to deliver daily JSON summaries of TLS successes and failures. It enforces nothing on its own — it is pure visibility.
Reports arrive once per UTC day from each cooperating sender. Google is usually the first provider to send them. Each report counts successful TLS sessions and itemizes failures with a named cause. Causes include a missing STARTTLS offer, an expired certificate, or an invalid MTA-STS policy. That feedback is how you roll out MTA-STS safely. You watch the reports in testing mode, fix what they surface, and only then switch to enforce.
The record itself is short. A typical value looks like v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com. The rua tag accepts a comma-separated list of destinations. Each destination is either a mailto: address or an https: endpoint that accepts POSTed reports.
How This Checker Works
The tool runs three checks. It queries the _mta-sts TXT record and the _smtp._tls TXT record through Google Public DNS. It then attempts to fetch the HTTPS policy file. Each part is validated against the syntax rules in RFC 8461 and RFC 8460.
The two DNS checks always work. The policy file fetch is different. Browsers only let one site read a file from another site when that server grants cross-origin permission. Most MTA-STS policy hosts do not send those headers, so the browser blocks the read. When that happens, the tool says so plainly and gives you a direct link to open the policy file yourself. A blocked fetch here does not mean your policy is broken. Mail servers are not browsers, and they fetch the file without that restriction.
How to Read Your Results
Each line is flagged PASS, WARN, FAIL, or INFO. PASS means the item meets the RFC syntax rules. WARN flags something legal but risky or unusual. FAIL marks a violation that causes senders to ignore your policy. INFO lines add context without judging.
The most common FAIL conditions are worth knowing in advance:
- Multiple records at the same name. If more than one TXT record at
_mta-stsstarts withv=STSv1, senders must treat the domain as having no policy. The same rule applies to TLS-RPT records. Delete the extras. - Missing or malformed id. The id must be 1 to 32 letters or digits. Senders use it to detect policy changes, so a broken id breaks cache refresh.
- Bad mode value. The policy mode must be exactly
enforce,testing, ornone. Anything else invalidates the policy. - max_age out of range. The value is plain seconds, from 0 up to 31557600 (one year). A missing or non-numeric value fails.
- No mx lines. Every policy needs at least one
mx:entry unless the mode isnone.
A missing TLS-RPT record is flagged as a warning, not a failure. TLS-RPT is optional. Skipping it just means nobody tells you when TLS delivery to your domain fails, which defeats much of the point.
Common MTA-STS Problems and Fixes
Most MTA-STS failures trace back to four causes. The policy file was never published. The certificate does not cover the mta-sts subdomain. The id was never updated after a policy edit. Or the MX hostnames do not match the policy’s mx patterns.
The policy file returns a 404
The TXT record only announces that a policy exists. The policy itself must be served at the exact path /.well-known/mta-sts.txt on the mta-sts subdomain. A common mistake is publishing the TXT record first and forgetting the file, or hosting it at the wrong path. Senders that cannot fetch the file cannot apply your policy.
The certificate does not match
The policy host needs a valid certificate for mta-sts.yourdomain.com specifically. A certificate for the bare domain or for www does not cover it unless it is a wildcard. Certificate mismatches show up in TLS-RPT reports as policy fetch errors.
Edits that never take effect
Senders cache your policy for up to max_age seconds. They only re-fetch early when the TXT record’s id changes. Edit the policy file without changing the id, and senders keep applying the old policy until their cache expires. Change the id — a timestamp works well — every time you touch the file.
MX hostnames that do not match
Each mx: line must match the hostnames your MX records actually point to. Patterns match exactly, or with a single leading *. wildcard covering one label. Migrate mail providers and update MX records without updating the policy, and enforce mode starts rejecting your own mail.
Related Tools and Guides
MTA-STS secures the transport layer. Pair this check with sender authentication and routing checks to cover the full delivery path. The tools below each cover one piece of that picture, from MX routing to SPF, DKIM, and DMARC policy.
Verify the sender authentication trio with the Email Auth Checker, which reads SPF, DKIM, and DMARC in one pass. Confirm your mail routing with the MX Record Lookup — its results are what your mx lines must match. Inspect the raw records behind any of these checks with the TXT Record Lookup. Run a full-domain pass, including DNSSEC and CAA, with the DNS Health Checker. Check the certificate on your policy host with the SSL Certificate Checker. Setting up authentication from scratch? Follow How to Set Up SPF and DMARC Without Breaking Email. Browse everything at the networking tools hub.
Frequently Asked Questions
These answers cover the questions people ask most when deploying MTA-STS and TLS-RPT. They explain how the two relate to SPF, DKIM, and DMARC. They also cover blocked policy fetches, which mode to start in, the id tag, and DANE.
Do I need MTA-STS if I already use SPF, DKIM, and DMARC?
Yes, they solve different problems. SPF, DKIM, and DMARC verify who sent a message. MTA-STS protects the connection the message travels over. It stops downgrade and man-in-the-middle attacks on server-to-server mail delivery. The two layers work best together.
Why can this tool not always read my policy file?
Browsers block cross-origin reads unless the server sends permission headers. Most MTA-STS policy hosts do not send them. The DNS checks always work. When the policy fetch is blocked, use the direct link the tool gives you to open the file yourself.
Should I start in testing mode or enforce mode?
Start in testing mode with TLS-RPT reporting enabled. Watch the daily reports for a few weeks. Move to enforce mode once reports show no legitimate delivery failures. Jumping straight to enforce can silently block mail from misconfigured senders.
What does the id value in the TXT record do?
The id value signals policy changes to sending servers. Senders cache your policy file for up to max_age seconds. They only fetch a fresh copy when the id changes. Update the id every time you edit the policy file, or senders will keep using the old version.
How is MTA-STS different from DANE?
Both enforce TLS for mail delivery. DANE anchors trust in DNSSEC-signed TLSA records. MTA-STS anchors trust in the public certificate authority system over HTTPS. DANE requires DNSSEC on your domain. MTA-STS does not, which makes it easier to deploy. Large providers support both.
References
This tool validates records against the two governing standards: RFC 8461 for MTA-STS and RFC 8460 for TLS reporting. Google’s Workspace documentation shows a major provider’s deployment guidance for both mechanisms.
- IETF — RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) — rfc-editor.org
- IETF — RFC 8460: SMTP TLS Reporting — rfc-editor.org
- Google Workspace Admin Help — About MTA-STS and TLS Reporting — support.google.com