MTA-STS Checker

What is MTA-STS?

MTA Strict Transport Security (MTA-STS) is a security standard that enables mail servers to declare their ability to receive TLS-secured connections and allows sending servers to verify that policy. Without MTA-STS, even if your mail server supports encryption, attackers can intercept or downgrade connections to plaintext through man-in-the-middle attacks.

MTA-STS solves this by publishing a policy that tells senders: "Only deliver mail to my domain over an encrypted connection, and verify my certificate is valid."

How MTA-STS Works

MTA-STS uses two components working together:

1. DNS TXT record – A record at _mta-sts.yourdomain.com signals that your domain supports MTA-STS and includes a policy version identifier.

2. Policy file – A text file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt containing your actual policy details.

When a sending server wants to deliver mail to your domain, it:

1. Checks for the MTA-STS DNS record to confirm you support the standard
2. Fetches your policy file over HTTPS (the HTTPS requirement ensures the policy itself can't be tampered with)
3. Caches the policy for the duration you specify
4. Enforces the policy when delivering mail to your servers

The Policy File

Your MTA-STS policy file defines how sending servers should handle mail delivery. It contains:

• version – Always STSv1 for the current specification
• mode – Your enforcement level: testing, enforce, or none
• mx – The mail server hostnames that are valid for your domain
• max_age – How long senders should cache your policy (in seconds)

A typical policy file looks like:

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
max_age: 604800

Testing vs Enforce Mode

MTA-STS offers two active modes for deployment:

• testing – Senders will attempt TLS connections and report failures via TLS-RPT, but will still deliver mail even if the policy can't be satisfied. Use this mode when first deploying to identify issues without risking mail delivery.

• enforce – Senders must establish a secure connection matching your policy or reject delivery entirely. Only enable this once you've verified your mail servers are correctly configured and you're not seeing policy failures in your TLS-RPT reports.

Start with testing mode, monitor your TLS-RPT reports for at least a few weeks, then switch to enforce once you're confident in your configuration.

What MailHealth Checks

Our MTA-STS checker validates your configuration by examining:

• DNS record presence – Confirms the _mta-sts TXT record exists and contains a valid version identifier
• Policy file accessibility – Verifies the policy file is reachable over HTTPS at the correct location
• Policy syntax – Ensures all required fields are present and properly formatted
• MX alignment – Checks that the MX hosts in your policy match your actual DNS MX records
• Certificate validity – Confirms your mail servers have valid TLS certificates
• Mode appropriateness – Advises on whether your current mode matches your deployment stage

Implementing MTA-STS alongside DANE or as a standalone measure significantly improves your email transport security. Combined with TLS-RPT for monitoring, it provides both protection against downgrade attacks and visibility into connection security across the mail ecosystem.