MTA-STS Checker
Instantly check whether a domain publishes an MTA-STS record enforcing TLS on inbound mail.
Need to monitor this across every client domain you manage? ActiScan does bulk scanning, scoring, and white-labeled reporting for MSPs.
How to Use the MTA-STS Checker
Enter a domain
No http:// prefix – just the domain itself (e.g. company.com).
Click Check
ActiScan looks up the domain's _mta-sts TXT record live, over DNS.
Read the result
A pass/warn status plus a plain-English explanation. This checks the DNS record only – it doesn't fetch your policy file.
What Your Result Means
MTA-STS record foundPassA valid v=STSv1 TXT record exists at _mta-sts.example.com. That confirms the DNS side only – it doesn't confirm your policy file is reachable or correctly formatted, since that file lives on your own HTTPS server, not in DNS. Check it directly at https://mta-sts.example.com/.well-known/mta-sts.txt.
No MTA-STS record foundWarnMTA-STS isn't configured. Inbound mail to this domain can still fall back to a downgraded or unencrypted connection – there's no DNS signal telling senders that TLS is required.
What is an MTA-STS Record?
MTA-STS (RFC 8461) lets a domain tell other mail servers that inbound SMTP connections must use TLS – and to reject the message rather than deliver it over a downgraded or unencrypted connection. Standard opportunistic TLS (STARTTLS) can be silently stripped by an attacker sitting on the network path; MTA-STS closes that gap by making TLS mandatory and giving senders a verified list of the domain's real mail servers before they deliver.
Unlike DMARC or SPF, MTA-STS needs two pieces published together, not one DNS record: a TXT record at _mta-sts.example.com that simply announces a policy exists, and a policy file hosted over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt that lists your mail servers and the enforcement mode. Senders fetch the policy file once and cache it – they only recheck DNS, and refetch the file, when the id in your TXT record changes.
The policy file's mode determines behavior: none disables enforcement, testing reports problems without blocking delivery, and enforce rejects mail that can't negotiate TLS to a listed server. Because a mistake in enforce mode can bounce real mail, the normal rollout is testing first, for a full max_age period, before switching to enforce. MTA-STS is often deployed alongside TLS-RPT, which reports on TLS failures instead of enforcing anything – together they cover both prevention and visibility.
MTA-STS Record & Policy Examples
DNS TXT record
v=STSv1; id=20261024140500Z
Published at _mta-sts.example.com. The id is the only thing senders read from DNS – it just tells caching senders whether the policy file has changed since they last fetched it.
Policy file – testing mode
version: STSv1 mode: testing mx: mail.example.com max_age: 86400
Hosted at https://mta-sts.example.com/.well-known/mta-sts.txt. Testing mode reports problems without blocking delivery – the safe way to roll out.
Policy file – enforce mode
version: STSv1 mode: enforce mx: mail.example.com max_age: 604800
Once you're confident the mx list is complete and stable, switch to enforce – mail that can't negotiate TLS to one of these hosts gets rejected instead of delivered in the clear.
Need to build your own? Use the free MTA-STS generator.
MTA-STS Fields Explained
| Tag | Where | What it does | Example | Required? |
|---|---|---|---|---|
| v | DNS record | Protocol version. Must be the first tag. | v=STSv1 | Required |
| id | DNS record | Arbitrary string identifying the current policy. Must change whenever the policy file's content changes, or caching senders will never notice the update. | id=20261024140500Z | Required |
| version | Policy file | The policy file's own version tag, also STSv1. | version: STSv1 | Required |
| mode | Policy file | Enforcement level: none, testing, or enforce. | mode: enforce | Required |
| mx | Policy file | One line per mail server hostname senders are allowed to deliver to over TLS. Repeat for each MX host. | mx: mail.example.com | Required (at least one) |
| max_age | Policy file | How long, in seconds, a sender may cache this policy before re-checking. | max_age: 604800 | Required |
How to Find Your MTA-STS Record Manually
If you'd rather look it up yourself instead of using the checker above:
DNS record, using nslookup
nslookup -type=TXT _mta-sts.yourdomain.com
DNS record, using dig
dig TXT _mta-sts.yourdomain.com
Policy file, using curl
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
Next Steps After Your Check
Want to know when TLS fails?
MTA-STS enforces TLS; TLS-RPT reports the failures MTA-STS won't tell you about on its own.
TLS-RPT Checker →Want ongoing monitoring?
ActiScan scans on a schedule and alerts you when something changes – across every domain you manage.
Start free →Frequently Asked Questions
Is this MTA-STS checker free?
Yes – check any domain's MTA-STS record for free, no signup required.
Do I need to own the domain I'm checking?
No. MTA-STS DNS records are published in public DNS, so anyone can look one up.
Does this checker also validate my policy file?
No. It looks up the _mta-sts TXT record only, the same as most mail providers' own validators. Your policy file is hosted on your own HTTPS server, not in DNS, so confirm it separately by visiting https://mta-sts.yourdomain.com/.well-known/mta-sts.txt directly.
Why does my domain show "no record" right after I added one?
DNS changes take time to propagate – wait for the record's TTL to expire (often up to a few hours) and check again.
What's the difference between testing and enforce mode?
Both live in the policy file, not the DNS record. testing reports problems without blocking delivery; enforce rejects mail that can't negotiate TLS to a listed server. Start with testing for a full max_age period before switching.