Check the MTA-STS and TLS-RPT records that make mail to your domain travel encrypted
Checked from our server in India. Only the address you type is sent to us and to cloudflare-dns.com or dns.google; nothing else leaves your device. Updated on 24 Oct 2026.An MTA-STS checker reads the TXT record at _mta-sts followed by a domain, which tells senders that mail must arrive over encrypted connections, and the TLS-RPT record at _smtp._tls, which asks for daily failure reports. The id must be 1 to 32 letters and digits, changed whenever the policy changes.
Type the domain in Domain and press Check MTA-STS.
Read the _mta-sts and _smtp._tls records, the policy host address and the MX servers.
Read The policy file: whether a sender can use it, its mode and max_age; paste an edited copy into the box to test it.
Check that each MX server shows covered by a pattern from the policy.
Mail between servers is encrypted only if both ends agree to it, and an attacker in the middle can quietly remove the offer. MTA-STS, defined in RFC 8461, lets a domain say "only deliver to me over a verified encrypted connection". It has two parts: a TXT record at _mta-sts. followed by the domain, with v=STSv1 and an id=, and a policy file served over HTTPS from the mta-sts. host.
Type a domain and the page asks a public DNS-over-HTTPS resolver for the MTA-STS record, the TLS-RPT record at _smtp._tls., the address of the mta-sts. host and the domain's MX servers. The records are read against RFC 8461 section 3.1 and RFC 8460 section 3: the version must come first, the id must be 1 to 32 letters and digits, there must be exactly one record of each, and the TLS-RPT rua= must be a mailto: or https: address.
The policy file sits at https://mta-sts. followed by the domain, then /.well-known/mta-sts.txt, and those servers do not send the header that lets a web page on another site read the reply. So our server fetches it once, the way a sending mail server would under RFC 8461 section 3.3: over HTTPS with a certificate valid for the mta-sts host, an answer of 200, and no redirect followed. The result says whether a sender could use the file, then checks it for version, mode and max_age, and matches every MX host against its mx: patterns using the wildcard rule of section 4.1, where * covers exactly one label. If the fetch fails, or you want to try an edited policy first, paste the text into the box and it is checked in the page.
TLS-RPT, RFC 8460, is what tells you when the policy is blocking mail. Publishing MTA-STS without it means failures stay silent.
What it does not do: it does not connect to your mail servers or test their certificates.
The domain you type is sent to the resolver you pick, and to our server, which fetches the policy file. Our server logs the host name you checked, the result and a hashed, daily-rotated version of your IP address, kept for 30 days to stop abuse. The full IP address is not stored. A pasted policy file is checked in the page and never sent.
Browsers let a page read a reply from another site only when that site sends an Access-Control-Allow-Origin header, and mta-sts hosts do not send one. So our server fetches the file once over HTTPS, as a sending mail server would: it needs a valid certificate and a 200 answer, and redirects are not followed. If that fails, paste the file's text into the box and it is checked in the page.
The id= value is a label of 1 to 32 letters and digits that senders use to notice a new policy. Senders cache the policy file, so after editing the file you must change the id, for example to the date and time, or they keep using the old one.
Start in testing: senders then report connection problems through TLS-RPT but still deliver mail. Once the reports show every sender connecting securely to the listed servers, switch the policy file to enforce, change the id, and senders will refuse unprotected delivery.
The TXT record at _smtp._tls asks sending servers to send a daily report of successful and failed encrypted connections to the rua= address. Without it, a broken MTA-STS policy blocks mail silently, because nobody is told which senders gave up.
The domain goes to the public DNS resolver you pick, Cloudflare or Google, for the records, and to our server, which fetches the policy file from the domain's mta-sts host. Our server logs the host name, the result and a hashed, daily-rotated version of your IP address, kept for 30 days to stop abuse. The full IP address is not stored. A pasted policy file is checked in the page and never sent.
Still stuck? Ask about MTA-STS and TLS-RPT Checker and anybody who knows can answer. No account needed.
Also works as: TLS-RPT Checker.
Same job, other tools: DMARC Record Generator – Build a DMARC record step by step, from p=none reporting to p=reject · SPF Record Generator – Write an SPF record for your mail providers and see how many lookups it uses · JSON Validator – Check JSON and see exactly where it breaks.
On the related tools: Find the Sender IP of an Email – Paste the headers of an email to find the IP address of the server that sent it.