MTA-STS and TLS-RPT checker

Type a domain: you see whether mail sent to it must arrive encrypted. The checker reads the _mta-sts record, fetches the policy file as a sending server would, compares it with your MX hosts, and reads the TLS-RPT record that tells senders where to report failures.

The DNS lookups go from your browser to public resolvers. Our server fetches one file, the policy of the domain you type, and keeps the answer ten minutes.

What the checker looks at

The _mta-sts record: A TXT record that says a policy exists and carries its id. Senders fetch the policy again only when the id changes: forget to change it and your edits are not seen.
The policy file: Served at https://mta-sts.yourdomain/.well-known/mta-sts.txt, with a valid certificate and without redirect. It gives the mode, the MX hosts allowed and how long senders may remember it.
Your MX hosts against the policy: Each MX host of the domain must match an “mx” line. Under “enforce”, a sender refuses to deliver to a host the policy does not list.
The TLS-RPT record: A TXT record at _smtp._tls that gives the address where senders report, each day, the deliveries that could not be encrypted.

How to read the result

Enforced: Senders that support MTA-STS (Google, Microsoft and others) deliver only over TLS with a valid certificate, to the hosts you listed. An attacker on the way can no longer strip the encryption.
Testing: Senders deliver as usual and only report what would have failed. The right first step: stay there until the reports are clean, then move to “enforce”.
Published but unusable: A record without a policy senders can read protects nothing, and each sender falls back to ordinary delivery. The finding says which part fails.

Errors people run into

What goes wrong most often when MTA-STS is set up, and how to fix it.

The policy file cannot be fetched

Why. The host mta-sts.yourdomain does not exist, answers with a redirect, or presents a certificate that is expired or does not cover that exact name. Senders do not follow redirects and do not accept an invalid certificate here.

Fix. Create the mta-sts host, serve the file directly over HTTPS at /.well-known/mta-sts.txt with a certificate valid for mta-sts.yourdomain, and answer 200 without redirect.

An MX host is not in the policy

Why. A mail server was added or the mail provider changed, and the policy still lists the old hosts. Under “enforce”, mail to the unlisted host is refused by the senders that apply MTA-STS.

Fix. Add an “mx” line for each host (or a wildcard such as *.mail.protection.outlook.com), then change the id of the _mta-sts record so that senders fetch the new policy.

Changes to the policy are not taken into account

Why. Senders keep the policy for max_age seconds and look at the file again only when the id of the TXT record changes.

Fix. Change the id (a date and time is the usual choice) every time the file changes. Before a move of mail provider, publish both sets of hosts first.

Questions

Is MTA-STS the same as STARTTLS?

No. STARTTLS offers encryption, but an attacker on the way can remove the offer and the mail goes in clear. MTA-STS tells senders that encryption, with a valid certificate, is required for your domain.

Which max_age should I use?

A week (604800) to a few weeks once in “enforce”; a day while testing. The maximum is one year. A long value protects longer but makes a mistake last longer.

Do I need TLS-RPT?

It is optional, but without it you never learn that deliveries fail. Publish it before the policy, and read the reports before moving to “enforce”.

What do you send to your servers?

The DNS lookups go from your browser to public resolvers. The policy file is fetched by our server, because browsers may not read it across origins: it receives the domain you typed, fetches that one file, and keeps the answer ten minutes.