Free MTA-STS checker
Free MTA-STS checker and policy lookup
Run a free MTA-STS checker to validate the DNS discovery record and the live .well-known policy file for any domain. Use it before transport-security rollouts, after DNS or CDN changes, and during mail-security reviews when SMTP TLS posture matters.
Primary use
Transport policy check
Validate both MTA-STS discovery and the HTTPS policy file from one page.
Critical dependency
.well-known file
Catch missing or broken policy hosting before transport expectations rely on it.
Operational fit
Post-change review
Use it after DNS, CDN, or web-server changes that could affect MTA-STS visibility.
Output
DNS + policy
See the DNS record, file presence, and policy body together in one troubleshooting view.
Intent-led preview
MTA-STS checker and policy lookup
Main action
MTA-STS checker
What this page returns
Validate discovery
Confirm the _mta-sts record is published where receivers expect to find it.
Check the policy file
Verify the HTTPS policy document is actually reachable and returns the expected content.
Reduce rollout risk
Catch CDN, redirect, or hosting mistakes before transport policy assumptions break mail delivery.
Primary use
Transport policy check
Validate both MTA-STS discovery and the HTTPS policy file from one page.
Critical dependency
.well-known file
Catch missing or broken policy hosting before transport expectations rely on it.
Operational fit
Post-change review
Use it after DNS, CDN, or web-server changes that could affect MTA-STS visibility.
Intent overview
What teams usually need from this tool page
The strongest tool pages answer the immediate question, make the next move obvious, and connect the free check to the broader MailSlurp workflow behind it.
Primary outcome
Validate discovery
Confirm the _mta-sts record is published where receivers expect to find it.
Workflow signal
Check the policy file
Verify the HTTPS policy document is actually reachable and returns the expected content.
Workflow signal
Reduce rollout risk
Catch CDN, redirect, or hosting mistakes before transport policy assumptions break mail delivery.
Run a free lookup
Check the live MTA-STS record and policy file
Enter the root domain. This checker validates DNS discovery, the expected policy-file URL, and the live body returned by the .well-known endpoint.
Product workflow
Take mta-sts checker and policy lookup beyond a one-off run
Use the free tool for the fast answer. Use the product workflow when the check needs history, owners, automation, and a place in your release or sender-health process.
Saved history
Keep every important run in one shared workflow
Use mta-sts checker and policy lookup as a repeatable checkpoint instead of relying on screenshots, scattered notes, or one person's memory.
Automation
Turn one-off checks into release and migration gates
Trigger the same verification from CI, internal tooling, or launch checklists so DNS, deliverability, and QA decisions stay consistent.
Ownership
Route failures to the right team before they become incidents
Move from ad hoc triage into shared operational visibility with alerting, escalation paths, and clearer accountability.
Next step
Move from a fast answer into a repeatable MailSlurp workflow
The free check is built for speed. The product path is where you save runs, automate verification, and give the right owner enough context to act before the next launch or incident review.
Recommended actions
Best fit
Use this when transport policy is part of the change
This page is strongest after DNS or web changes, before transport-policy rollout, and during security reviews when SMTP TLS posture needs a quick validation path.
- Check MTA-STS after DNS or web-hosting changes
- Validate policy hosting before a stricter rollout
- Give security and messaging owners one shared transport view
Upgrade path
Pair transport checks with sender-domain monitoring
Transport policy is only one part of production mail posture. Teams usually pair it with MX, DMARC, SPF, and DKIM review when reliability and trust need named ownership.
- Review mail routing and sender auth alongside transport policy
- Use domain-level monitoring before major launch windows
- Keep security and deliverability posture in one operational flow
What this returns
A useful MTA-STS checker should answer both discovery and policy-hosting questions
The valuable output is not just whether a TXT record exists. It is whether receivers can discover the policy, retrieve the policy file, and see content that matches the intended transport rollout.
DNS
_mta-sts record
Confirm transport policy discovery is published at the expected DNS name.
HTTPS
Policy file
Check that the .well-known policy file is reachable and present.
Body
Live content
Review the current file body instead of assuming the server is returning the intended policy.
Warnings
Review notes
Catch issues that deserve follow-up before transport assumptions are relied on in production.
Operational use
Best used after DNS or hosting changes and before stricter transport expectations
Teams usually reach for an MTA-STS lookup because they are changing policy or verifying that transport security is still intact after infrastructure work.
After CDN or web changes
Re-run the checker after redirects, caching, or hosting changes so the policy file is still discoverable where receivers expect it.
Before transport rollout
Validate discovery and file content before tightening policy so rollout errors are caught before they affect mail transport.
During security review
Give security and messaging owners a shared reference point when auditing SMTP TLS posture across domains.
FAQ
Questions teams ask before they operationalize this workflow
What does an MTA-STS checker validate?
An MTA-STS checker verifies the DNS policy record and the HTTPS well-known policy file so you can confirm transport security settings are both published and reachable.
Why do I need both the DNS record and the policy file?
Receivers need the DNS record to discover MTA-STS and the policy file to understand the actual mode and expected MX hosts. Missing either piece weakens the setup.
When should teams run an MTA-STS lookup?
Run it after DNS or CDN changes, before enforcing transport expectations, and during mail-security reviews when SMTP TLS posture needs verification.
What if the policy file is missing?
That usually means the HTTPS path is not published correctly, a CDN rule is stripping the response, or the file location is different from the expected .well-known path.