MTA-STS lets your domain publish a transport-security policy for mail sent to your MX hosts. It is useful, but it has more moving parts than a normal DNS TXT record: DNS, HTTPS hosting, MX hostnames, certificates, policy mode, and optional TLS reports.
Check your MTA-STS and TLS-RPT signals
Run a public DNS scan first, then use this guide to review the policy host, policy file, MX names, and reporting setup.
01$0Free scan
Check the public sender-auth records mailbox providers expect.
02$0Shareable action plan
Keep one URL with evidence, owner steps, and decisions.
03$49$49 fix plan
Add human review, provider context, and verification steps.
Optional. Most first scans can run with just the domain.
Checks Gmail, Yahoo, and Microsoft sender requirementsPublic DNS onlyNo mailbox login needed
Example result72/100Needs attention
Review DMARC policy strength before a high-volume send.
Public DNS evidence
DMARC/SPF/DKIM status and caveats are visible before you pay.
Owner-ready next step
The audit adds provider context and a verification checklist.
Get the exact fix plan for your domain.$49 readiness audit: prioritized owner actions, DNS evidence, and verification checks.
RFC 8461 uses a TXT record at _mta-sts.example.com to advertise the current policy ID. The actual policy is served over HTTPS from https://mta-sts.example.com/.well-known/mta-sts.txt. Supporting senders use the TXT ID to notice when a cached policy may need to be refreshed.
The policy file lists a version, a mode, one or more MX patterns, and a maximum age. If those values do not match your real inbound MX hosts and certificates, enforce mode can create delivery problems for senders that honor the policy.
Start with testing mode
For a first rollout, use testing mode while you review TLS reports and MX behavior:
Replace the MX host with every hostname that actually appears in your MX records. When you change the policy file, rotate the DNS id value so supporting senders know the cached policy is stale.
Add TLS reporting before enforce mode
TLS reporting is separate from MTA-STS, but it is the practical way to see connection problems before you enforce. Google recommends adding reporting first, then MTA-STS. A common reporting record shape is:
Use a mailbox or reporting service that can process daily TLS reports. Reports can show detected policies, traffic statistics, failed connections, and messages that could not be sent.
Pre-enforcement checklist
Confirm every MX hostname in DNS is listed in the policy file.
Confirm each MX supports STARTTLS with a valid public certificate for the MX name.
Serve the policy file over HTTPS from the exact MTA-STS host and path.
Keep testing mode long enough to review TLS reports and backup MX behavior.
Move to mode: enforce only after failed-connection patterns are understood.
MTA-STS setup FAQ
Does MTA-STS protect mail I send out?
MTA-STS is mainly a policy for mail sent to your domain. It tells supporting external senders how to validate TLS when delivering to your MX hosts. Your outbound mail still needs SPF, DKIM, DMARC, TLS support, reputation, and correct provider setup.
Can I publish only the _mta-sts TXT record?
No. The TXT record announces a policy version, but supporting senders fetch the actual policy over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt.
Should I start with enforce mode?
Usually no. Start in testing mode with TLS reporting, confirm every MX host matches the policy and presents a valid certificate, then move to enforce only after review.
Want MTA-STS reviewed with the rest of sender readiness?
SenderReady readiness audits organize public DNS findings, including DMARC, SPF, DKIM, BIMI, MTA-STS, and TLS-RPT, into a cautious review packet. They are diagnostics, not delivery guarantees.