Patchkit

Free tool

MTA-STS Checker

Check what senders need before they'll require validated TLS to your domain: the _mta-sts record, the policy file, the MX hosts it must cover and the TLS-RPT record that reports failures.

By Ahmet Karaca · Updated · Checked against RFC 8461 (MTA-STS) and RFC 8460 (SMTP TLS Reporting) on

What the checker verifies

MTA-STS (SMTP MTA Strict Transport Security) has two parts that a sender needs together: a TXT record that announces a policy and a policy file served over HTTPS. TLS-RPT is its companion record for reports. The checker reads all three for the domain you enter, the way a sending server would, and compares the policy with your MX records.

  • The TXT record at _mta-sts.yourdomain.com: that exactly one record starts with v=STSv1 and that it carries an id= of 1 to 32 letters and digits.
  • The policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt: that the host exists, its certificate is valid for that name, the server answers 200 without a redirect, the file is served as text/plain and stays under the 64 KB that RFC 8461 suggests.
  • The policy fields: version: STSv1, a mode of enforce, testing or none, a max_age from 0 to 31557600 seconds (365.25 days), and at least one mx line unless the mode is none.
  • That every MX host of your domain matches an mx pattern, with wildcards matching exactly one label as RFC 8461 §4.1 defines.
  • The TLS-RPT record at _smtp._tls.yourdomain.com: one record starting with v=TLSRPTv1 and an rua= list of mailto: or https: addresses.

Testing vs enforce

The mode line decides what a sender does when TLS to one of your MX hosts fails, or when the host isn't in the policy. In testing, senders that support TLS-RPT report the failure and may deliver anyway. In enforce, they must not deliver to that host: they try another MX host that passes, or keep the message and retry later. none tells senders to treat the domain as if it had no policy, and is meant for removing MTA-STS cleanly.

That is why the checker grades the same problem differently by mode. An MX host outside the policy is a warning in testing, because mail still flows, and a problem in enforce, because senders that apply the policy stop delivering to it. The green "enforced" summary appears only when the policy is in enforce mode, parses without errors and covers every MX host.

A rollout checklist

  1. List the hosts that receive your mail with the MX lookup, and make sure each one offers STARTTLS with a valid certificate for its own hostname.
  2. Publish the _smtp._tls record so reports start arriving.
  3. Serve the policy file with mode: testing and an mx line for every MX host, then publish the _mta-sts record.
  4. Run this checker until it reports no problems, then read the TLS-RPT reports for a while.
  5. When the failure counts are zero or explained, change the file to mode: enforce, then change the id in the TXT record. Update the file first, so a sender that sees the new id never caches the old file.

What it doesn't check

  • STARTTLS and certificates on the MX hosts themselves. We don't open connections to port 25.
  • Whether senders still hold an older policy in their cache. They keep it until its max_age runs out or they see a new id.
  • DNSSEC and DANE (RFC 7672), a different way to secure SMTP TLS.

For the reasoning behind each rule, sample records and how to read a TLS-RPT report, see MTA-STS and TLS-RPT explained.

Related tools and guides

Frequently asked questions

+What does MTA-STS protect against?

Mail servers upgrade to TLS with STARTTLS only when both sides offer it, and they usually deliver without TLS when that fails. An attacker on the path can strip the STARTTLS offer or pose as your MX host. MTA-STS lets you tell senders that support it to require TLS with a valid certificate, and only to the MX hosts you list.

+Should I start in testing or enforce mode?

Start in testing. Senders that support TLS-RPT report each failure but may still deliver, so a missing mx line or a bad certificate costs you a report entry instead of lost mail. Switch to enforce once the reports show no failures you can't explain, and change the id in the TXT record when you do.

+Why is one of my MX hosts marked not covered?

Its name matches no mx: line in the policy. A wildcard such as *.example.com covers exactly one extra label: mail.example.com, but not example.com or a.b.example.com. In enforce mode, senders won't deliver to a host that isn't covered, so add a matching line before you change your MX records.

+Do I need TLS-RPT as well?

MTA-STS works without it, but you won't hear about failures. RFC 8461 promises testing-mode reports only when the domain also publishes TLS-RPT, so without the _smtp._tls record testing mode tells you nothing. The record takes one line: v=TLSRPTv1 and an rua= address.

+Why doesn't the checker test STARTTLS on my mail servers?

Checking STARTTLS means opening a connection to port 25 on each MX host, and outbound port 25 isn't reliable from our hosting platform. Rather than guess, the result lists it under Not checked. Your TLS-RPT reports show how real senders' TLS sessions to those hosts went.

+How long should max_age be?

RFC 8461 caps it at 31557600 seconds and expects it to "typically be in the range of weeks or greater". The checker warns below 7 days, except in mode none, where the RFC suggests a short value while you remove the policy.

We use Google Analytics cookies only if you accept. Privacy policy