MTA-STS checker
Enter your domain. We read the MTA-STS record, fetch the policy file over HTTPS, and confirm every mail server it should cover is listed.
What MTA-STS protects
Mail between servers is encrypted with STARTTLS, but plain STARTTLS is opportunistic. If someone on the path strips the offer, the sending server falls back to plain text and delivers anyway. Nobody sees it happen.
MTA-STS (RFC 8461) closes that gap. You publish a policy that says: my mail servers always offer TLS, their certificates are valid for these names, and you should refuse to deliver otherwise. Gmail and Microsoft 365 both honor it when they send to you.
The policy lives on a web server, not in DNS, because DNS answers can be forged on the path too. An HTTPS file with a valid certificate is much harder to fake.
| Part | Where it lives | What it says |
|---|---|---|
| TXT record | _mta-sts.example.com | v=STSv1; id=20260924 (a policy exists, and its version) |
| Policy file | https://mta-sts.example.com/.well-known/mta-sts.txt | version, mode, mx lines, max_age |
| TLS-RPT record | _smtp._tls.example.com | v=TLSRPTv1; rua=mailto:reports@example.com |
Record formats from RFC 8461 (MTA-STS) and RFC 8460 (TLS-RPT).
A policy file that works
Here's the shape for a domain on Google Workspace. Serve it as text/plain, with a valid certificate for mta-sts.example.com, and no redirect:
version: STSv1
mode: enforce
mx: smtp.google.com
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800A wildcard like *.aspmx.l.google.com matches exactly one label, so it covers alt1.aspmx.l.google.com but not the bare name. That's why the aspmx name appears twice. Run your domain through our MX lookup to list every host you need to cover.
Secure transport and a clean list work together
MTA-STS decides how your mail travels. Your list decides where it goes. A strict policy protects every message you send to a real mailbox, and every send to a dead one still comes back as a hard bounce against your domain.
ZapBounce checks each address with its own SMTP check on port 25, closing before any message is sent. You get a verdict for every address, catch-all domains are labelled, and unknown results are never billed. 1,000 checks cost $5 on the pricing page, and your credits never expire.
Questions people ask
What does an MTA-STS checker test?
It reads the _mta-sts TXT record, fetches the policy file from https://mta-sts.yourdomain/.well-known/mta-sts.txt, checks the mode and max_age, and matches every live MX host against the policy's mx lines. It also reads the TLS-RPT record at _smtp._tls so you know where failure reports go.
Why does my MTA-STS policy fail to load?
The usual causes are a missing DNS record for the mta-sts subdomain, an HTTPS certificate that does not cover mta-sts.yourdomain, or a redirect. RFC 8461 forbids senders from following redirects, so the file must answer HTTP 200 at that exact URL.
Should MTA-STS be in testing or enforce mode?
Start in testing for one to two weeks with TLS-RPT turned on, read the reports, then switch to enforce. Testing only reports failures; enforce is the mode that makes senders refuse an unencrypted or unverified connection.
What is a good max_age for MTA-STS?
Senders cache the policy for max_age seconds, up to 31,557,600 (one year). A day (86,400) suits testing. Once the policy is stable, 604,800 (a week) or longer is common, since a longer cache protects mail for longer between fetches.
Do I need TLS-RPT with MTA-STS?
It's optional but you want it. TLS-RPT is a TXT record at _smtp._tls that tells senders where to send daily reports of failed secure connections. Without it, a broken certificate or a missing MX line fails silently.
Encrypted delivery, to addresses that exist
Verify your list before the next send. 100 free checks every month with no card, and unknowns are never billed.