Check a domain's MTA-STS and TLS-RPT setup: validates the _mta-sts and _smtp._tls TXT records, checks the policy file (version, mode, mx, max_age) and matches every live MX against the policy's mx lines. Free, runs in your browser.
Enter a domain and click Check MTA-STS.
Browsers usually can't read another site's mta-sts.txt (see below), so run this in a terminal and paste the output here. You can also paste a policy you are about to publish. If a domain is entered above, its live MX hosts are compared with the mx lines.
curl -s https://mta-sts.example.com/.well-known/mta-sts.txt
_mta-sts and _smtp._tls TXT records, the A/AAAA records of the mta-sts policy host and, if ticked, the default._bimi TXT record. Lookups use Cloudflare's public DNS-over-HTTPS resolver, with Google's as a fallback.https://mta-sts.<domain>/.well-known/mta-sts.txt. That usually fails in a browser because of CORS, so the result shows the exact curl command to run. Paste its output into Validate a policy file.version: STSv1 (Google asks for it on the first line), mode of testing, enforce or none, at least one mx line unless the mode is none, and a whole-number max_age no higher than 31557600. Each live MX host must match an mx line, either exactly or through a wildcard that covers only the leftmost label.Content-Type header and the mta-sts certificate when the browser can't read the file, and what senders have cached. Look up the certificates issued for your MX and mta-sts hostnames with the SSL Certificate Checker.Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).
Build the policy file and _mta-sts record with the MTA-STS Policy Generator, the _smtp._tls record with the TLS-RPT Record Generator and a BIMI record with the BIMI Record Generator. The MTA-STS and TLS-RPT setup guide walks through hosting, Microsoft 365 and Google Workspace mx values and the switch to enforce, and the BIMI setup guide covers DMARC, SVG Tiny PS and VMC vs CMC. Check SPF, DKIM, DMARC and MX together with the Email Deliverability Checker.
Browsers only let a page read a response from another site if that site sends an Access-Control-Allow-Origin (CORS) header. Mail servers don't need it, so most MTA-STS policy hosts don't send it and the browser blocks the read. Run curl -s https://mta-sts.yourdomain/.well-known/mta-sts.txt in a terminal and paste the output into the policy box; the page then validates it and compares the mx lines with your live MX records.
Exactly one TXT record at _mta-sts.yourdomain that begins with v=STSv1; and has an id of 1 to 32 letters and digits, for example v=STSv1; id=20261017000000Z. Records that don't begin with v=STSv1; are ignored, and if more than one remains, senders act as if there is no policy. A record split into several strings is read as the strings joined with no spaces.
A wildcard replaces only the leftmost label. mx: *.example.com matches mail.example.com but not example.com or a.b.example.com. Every MX host of the domain should match an mx line; in enforce mode, senders that support MTA-STS won't deliver to an MX that matches none.
One TXT record at _smtp._tls.yourdomain that begins with v=TLSRPTv1; and has a rua= tag with one or more mailto: or https: destinations separated by commas, for example v=TLSRPTv1; rua=mailto:tlsrpt@example.com. If more than one record begins with v=TLSRPTv1;, senders treat the domain as having no TLS reporting.
No, testing is the right way to start. Senders report failures through TLS-RPT but still deliver the mail. After about two weeks of clean reports, change the file to mode: enforce and publish a new id in the _mta-sts record so senders fetch the new policy.
Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.