Skip to content
Aback Tools Logo

MTA-STS Checker

Check MTA-STS (SMTP MTA Strict Transport Security) records for any domain. Enter a domain name to validate its DNS TXT record and policy file, ensuring your email delivery is protected against TLS downgrade attacks. Completely free, no signup required.

MTA-STS Checker

Check MTA-STS (SMTP MTA Strict Transport Security) records for any domain. Validates the DNS TXT record and policy file to ensure email delivery security.

Features

DNS TXT Record Lookup

Queries the _mta-sts subdomain TXT record via Cloudflare DNS-over-HTTPS to check for the existence and validity of the MTA-STS policy ID.

Policy File Validation

Fetches and validates the MTA-STS policy file from https://mta-sts.<domain>/.well-known/mta-sts.txt. Checks version, mode, MX rules, and max_age fields for correctness.

Security Status Assessment

Provides a clear security status: Fully Configured, Partially Configured, or Not Configured. Includes actionable recommendations for improving email security.

Error & Issue Detection

Identifies common MTA-STS misconfigurations including invalid TXT record format, policy file errors, missing MX patterns, and incorrect mode settings.

Who Needs MTA-STS?

Email Security Audit

Security professionals can audit client or organisational domains to verify MTA-STS is properly configured, ensuring email delivery is protected against TLS downgrade and man-in-the-middle attacks.

Postmaster & Sysadmin Troubleshooting

System administrators setting up email infrastructure can verify MTA-STS records are correctly deployed before rolling out the policy to enforce mode, preventing accidental email loss.

Compliance & Best Practices

Organisations requiring compliance with modern email standards (BIP 2026-01, Google/Yahoo sender requirements) can validate MTA-STS is in place alongside SPF, DKIM, DMARC, and BIMI.

About MTA-STS

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) is a standard (RFC 8461) that enables domain owners to declare that email servers sending mail to their domain must use TLS encryption. It prevents TLS downgrade attacks and provides a mechanism for domain owners to enforce encrypted email delivery.

How MTA-STS Works

MTA-STS works through two components: a DNS TXT record at _mta-sts.<domain> containing a policy ID, and a policy file hosted at https://mta-sts.<domain>/.well-known/mta-sts.txt. Sending mail servers first check the DNS record, then fetch and cache the policy file, which tells them whether to enforce TLS, test without enforcement, or skip checking.

MTA-STS Policy Modes Explained

The policy file has three modes: enforce - sending servers MUST use TLS or reject the message; testing - sending servers will attempt TLS but deliver even if it fails (useful for monitoring); none - no policy enforcement, for deactivating MTA-STS. The enforce and testing modes require at least one MX pattern and a max_age value.

MTA-STS vs. TLS-RPT

MTA-STS works alongside TLS-RPT (TLS Reporting, RFC 8460), which provides a reporting mechanism for senders to report TLS connection failures. While MTA-STS enforces TLS, TLS-RPT gives domain owners visibility into delivery issues. Many major providers including Google, Microsoft, and Yahoo now require or strongly recommend MTA-STS.

Frequently Asked Questions

MTA-STS (SMTP MTA Strict Transport Security) is a security standard that ensures email is always sent over encrypted TLS connections to your domain. Without MTA-STS, a malicious actor could perform a TLS downgrade attack and intercept unencrypted email. Major email providers like Google and Yahoo now require MTA-STS for bulk senders.
The checker performs two steps. First, it queries the DNS TXT record for _mta-sts.&lt;yourdomain&gt; using Cloudflare DNS-over-HTTPS. Second, it fetches the policy file from https://mta-sts.&lt;yourdomain&gt;/.well-known/mta-sts.txt. It then validates both the DNS record format and the policy file content, providing a clear pass/fail assessment.
The TXT record for _mta-sts.&lt;yourdomain&gt; should contain: v=STSv1; id=20250101000000; The id value should be a unique identifier (typically a timestamp) that changes whenever you update your policy file. This allows sending MTAs to know when to re-fetch the policy.
The policy file at https://mta-sts.&lt;yourdomain&gt;/.well-known/mta-sts.txt must contain: version: STSv1 (required), mode: enforce/testing/none (required), mx: &lt;pattern&gt; (one or more required), and max_age: &lt;seconds&gt; (required). Lines starting with # are comments. Each field should be on its own line.
It is strongly recommended to start with mode: testing and monitor TLS-RPT reports for any issues before switching to enforce. Testing mode allows sending servers to attempt TLS but still deliver messages if TLS fails. After confirming everything works (typically 2-4 weeks), switch to mode: enforce.
If configured in enforce mode with errors, legitimate email to your domain could be rejected by compliant sending servers. Common issues include: invalid TXT record format, inaccessible policy file (server must support HTTPS), missing MX patterns, or incorrect max_age values. Always test thoroughly before setting mode to enforce.
Yes, the MTA-STS Checker is completely free with no signup required. All DNS queries are performed via Cloudflare DNS-over-HTTPS, and policy files are fetched directly from the target domain. Your data is never stored or shared.