MTA-STS Checker

Verify Mail Transfer Agent Strict Transport Security (MTA-STS) to ensure emails are always delivered over encrypted, mutually authenticated connections.

Beta Feature

MTA-STS enforces TLS encryption for incoming SMTP connections. Policy mode enforcement testing and MX validation are planned for the next update.

Our MTA-STS Checker retrieves both halves of an MTA-STS deployment — the DNS TXT record at _mta-sts.yourdomain.com and the policy file served at mta-sts.yourdomain.com — and reports the enforcement mode, the authorised MX hosts and the policy lifetime.

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) tells other mail servers that your domain requires TLS encryption for inbound mail, and which MX hosts are legitimate. It is defined in RFC 8461.

SMTP encryption normally uses opportunistic STARTTLS, which has a fundamental weakness: an attacker positioned on the network can simply strip the STARTTLS advertisement from the connection, and the sending server silently falls back to plaintext. There is no way for the sender to know it should have been encrypted.

MTA-STS closes that gap. A sending server fetches your policy over HTTPS, caches it, and from then on refuses to deliver mail unless the connection is encrypted and the receiving certificate matches a host named in your policy.

Declares that inbound mail to your domain must use TLS
Prevents STARTTLS downgrade and man-in-the-middle attacks
Requires a DNS TXT record and an HTTPS-hosted policy file together
Policy is fetched over HTTPS, which is what makes it tamper-resistant
Supported by Google, Microsoft, Yahoo and other major providers

Why MTA-STS Matters

Without MTA-STS, an attacker who can intercept traffic between a sending server and yours can strip the encryption negotiation and read every message in plaintext. Neither side receives any warning, because opportunistic TLS is designed to degrade silently rather than fail.

The same attack also enables MX redirection: forge a DNS response, point mail at a server you control, and inbound mail is delivered to the attacker. MTA-STS blocks this too, because the cached policy names exactly which MX hosts are valid and the certificate must match one of them.

Blocks STARTTLS stripping, where encryption is silently removed in transit
Prevents delivery to forged MX hosts through DNS spoofing
Guarantees inbound mail is encrypted rather than merely eligible for encryption
Increasingly expected in security questionnaires and compliance frameworks
Pairs with TLS-RPT to provide visibility into failures

How This MTA-STS Checker Works

The tool checks both required components — the DNS record and the HTTPS policy file — and reports on each.

Validates the domain input against format and SSRF safety checks
Queries DNS for a TXT record at _mta-sts.yourdomain.com
Fetches the policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
Parses the mode, max_age and every mx line in the policy
Reports whether the policy is in enforce, testing or none mode

How to Use the MTA-STS Checker

Enter your domain name in the input field
Run the check to retrieve both the DNS record and the policy file
Confirm the DNS record is present with a valid id value
Confirm the policy file is reachable over HTTPS
Check the mode — enforce is the goal, testing is a safe intermediate step

Understanding Your MTA-STS Results

MTA-STS has two parts. Here is what each field means:

Field / Value	Meaning
`DNS record`	The TXT record at _mta-sts.yourdomain.com, containing v=STSv1 and an id value. Sending servers watch the id and refetch the policy whenever it changes.
`mode: enforce`	Full protection. Sending servers refuse to deliver unless TLS succeeds and the certificate matches a listed MX host.
`mode: testing`	Failures are reported through TLS-RPT but mail is still delivered. The correct starting point for a new deployment.
`mode: none`	Effectively disables the policy. Used to withdraw MTA-STS cleanly, since simply deleting the record leaves cached policies in force.
`max_age`	How long, in seconds, sending servers cache the policy. Start low at around 86400 (one day) and increase to 604800 (one week) or more once stable.
`mx`	Each authorised mail host. Wildcards such as *.example.com are permitted. Every MX host in your DNS must be listed, or mail from enforcing senders will fail.

Common Problems & How to Fix Them

Both halves are required. Sending servers that find the DNS record will try to fetch the policy over HTTPS, and a failure means the policy is ignored entirely.

Serve the file at exactly https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid certificate for that hostname, Content-Type text/plain, and no redirects. The subdomain needs its own A or CNAME record and its own valid certificate.

In enforce mode, any MX host missing from the policy is treated as unauthorised and mail routed to it is rejected by enforcing senders.

List every hostname that appears in your MX records. If your provider uses many hosts under one domain, a wildcard such as *.protection.outlook.com is permitted and is usually the safer choice.

Sending servers cache the policy for max_age seconds and only refetch when the id in the DNS TXT record changes.

Update the id value every time you edit the policy file. A timestamp such as 20260929120000 works well because it always increases and is self-documenting.

A mismatch between your policy and your actual mail setup is now blocking delivery — usually an unlisted MX host or a certificate that does not match the hostname.

Switch the policy back to testing mode immediately to restore delivery, then use TLS-RPT reports to identify exactly which host or certificate is at fault before returning to enforce.

Enforcing senders verify that the certificate presented by your mail server matches a hostname listed in the policy. A certificate issued for a different name fails the check even though TLS itself succeeded.

Ensure each mail server presents a certificate whose subject or SAN covers the MX hostname it is reached by.

Best Practices

Start in testing mode and only move to enforce once TLS-RPT reports are clean
Set up TLS-RPT before MTA-STS so you have visibility from the first day
List every MX host, or use a wildcard covering your provider hosts
Update the DNS id value on every policy change
Begin with max_age of 86400 and increase once the deployment is proven
Monitor the policy URL for availability, since an outage weakens protection as caches expire
Use mode: none rather than deleting records if you need to withdraw MTA-STS

Security Recommendations

Do not stop at testing mode — it reports failures but provides no actual protection
Keep the certificate on the mta-sts subdomain valid and monitored, as an expiry silently disables policy fetching
Verify your MX hostnames and certificates align before enabling enforce, since a mismatch blocks legitimate mail
Pair MTA-STS with TLS-RPT so downgrade attempts become visible rather than silent
Consider DANE alongside MTA-STS if your DNS is DNSSEC-signed, as the two are complementary
Review the policy after any mail provider migration, since a stale MX list will reject your own new servers

Frequently Asked Questions

MTA-STS is a standard that lets a domain declare it requires TLS encryption for inbound mail and specify which MX hosts are legitimate. It prevents attackers from stripping STARTTLS or redirecting mail to a forged server.

The DNS record announces that a policy exists and carries a version id. The policy itself is served over HTTPS, which is what makes it tamper-resistant — an attacker who can forge DNS still cannot forge a valid TLS certificate for your mta-sts subdomain.

In testing mode, failures are reported through TLS-RPT but mail is delivered anyway. In enforce mode, sending servers refuse to deliver when TLS fails or the certificate does not match. Start in testing and move to enforce once reports are clean.

No. It protects mail sent to your domain. Whether your outbound mail is protected depends on whether the recipient domain publishes its own MTA-STS policy and whether your sending server honours it.

Both enforce TLS for SMTP. DANE publishes certificate constraints in DNS and requires DNSSEC to be trustworthy. MTA-STS uses HTTPS and the existing web PKI instead, so it works without DNSSEC. Many large providers chose MTA-STS for that reason, and the two can be deployed together.

Edit the policy file, then change the id value in the DNS TXT record. Sending servers only refetch when the id changes, so a policy edit alone has no effect until the id is updated.

It can, if enforce mode is enabled while your policy does not match your real mail setup — an unlisted MX host or a mismatched certificate will cause enforcing senders to reject mail. This is exactly why testing mode exists. Stay in it until TLS-RPT reports are clean.