BETA

MTA-STS Checker

Verify MTA-STS DNS record, validate policy file, and check TLS enforcement mode

πŸ”§ Related Tools

ANALYSIS TOOLS
DIAGNOSTIC TOOLS
BUILDER TOOLS

MTA-STS Checker

Verify your MTA-STS DNS record and policy file. MTA-STS enforces TLS encryption for inbound email delivery to your domain.

Frequently Asked Questions

Common questions about MTA-STS and email transport encryption.

MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism that allows mail server operators to declare their ability to receive TLS-secured SMTP connections and to specify whether sending servers should refuse to deliver email to MX hosts that do not offer TLS. It works through two components: a DNS TXT record at _mta-sts.{yourdomain} that signals the policy exists, and a policy file hosted at https://mta-sts.{yourdomain}/.well-known/mta-sts.txt that contains the actual policy including the MX patterns and mode. Unlike STARTTLS alone, MTA-STS prevents downgrade attacks by requiring that the receiving server presents a valid certificate.

MTA-STS has three modes: enforce, testing, and none. In enforce mode, sending mail servers must establish a TLS connection with a valid certificate to your MX hosts β€” if they cannot, they will refuse to deliver the email and the message will be deferred or bounced. This gives you strong protection against man-in-the-middle attacks on inbound email. In testing mode, the policy is applied but failures are only reported (via TLS-RPT) rather than causing delivery failures β€” this is ideal for gradual rollout. In none mode the policy effectively does nothing and exists only to signal that the domain has considered MTA-STS. You should move from testing to enforce only after reviewing TLS-RPT reports and confirming all legitimate senders can connect successfully.

This error means the mx: patterns listed in your MTA-STS policy file at https://mta-sts.{yourdomain}/.well-known/mta-sts.txt do not match the actual MX hostnames returned by DNS for your domain. For example, if your MX record points to mail.example.com but your policy file lists mx: smtp.example.com, inbound senders using MTA-STS will reject delivery. To fix this, update the mx: lines in your policy file to match each of your actual MX hostnames β€” you can use wildcards like mx: *.example.com to cover multiple hosts under the same parent domain. After updating the policy file, you must also increment the id= value in your DNS TXT record at _mta-sts.{yourdomain} so that caching mail servers know to fetch the updated policy.

DNS propagation for the _mta-sts TXT record typically takes between a few minutes and 48 hours depending on the TTL (time-to-live) set on the record and your DNS provider's update speed. However, MTA-STS policies are cached by receiving mail servers for the duration specified by the max_age field in your policy file β€” commonly set to 86400 (1 day) or 604800 (7 days). This means that even after you update your DNS record and policy file, remote servers that have already cached your old policy will continue using it until the cache expires. To speed up rollout during initial setup or after a change, set a lower max_age first, wait for the shorter cache to expire, then increase it once the new policy is confirmed working.

Data Collection: This MTA-STS Checker processes data to provide results. When you enter a domain name and submit it for checking, the domain name is used to perform a DNS TXT lookup at _mta-sts.{domain} and to fetch the policy file at https://mta-sts.{domain}/.well-known/mta-sts.txt. No domain names or results are stored. We do not store, log, or share the domain names or data you submit beyond what is necessary to return your results.

Data Usage: Your input is used solely to generate results. No data is saved, analysed for profiling, or shared with third parties. Each new check operates independently.

DNS Lookups: To check your domain, we perform DNS queries via Google's DNS-over-HTTPS (dns.google). These queries are subject to Google's Privacy Policy. Only the domain name is transmitted β€” no personally identifiable information.

Bot Protection (Cloudflare Turnstile): When you submit a form or run a domain check, we use Cloudflare Turnstile to verify that the request is from a human and not an automated bot. Turnstile may collect limited technical data (e.g. browser attributes) as part of this check. No personally identifiable information is shared with Cloudflare beyond what is technically necessary. Cloudflare's privacy policy applies: cloudflare.com/privacypolicy.

Analytics (Google Analytics 4): We use Google Analytics 4 to understand how visitors use this site (pages visited, tools used). IP addresses are anonymised before being sent to Google. We do not share the domain names you check with Google Analytics. Google's privacy policy applies: policies.google.com/privacy. You can opt out via tools.google.com/dlpage/gaoptout.

Contact: For privacy enquiries or questions, please contact us at [email protected] or visit osh.co.za/contact.