Set Up MTA-STS — Enforcing TLS for Inbound Mail

What you need

Access to the DNS zone, a web server with a valid HTTPS certificate for the subdomain mta-sts.yourdomain.com, and a complete list of your MX hosts. That web server must stay reachable — if it goes down, sending servers fall back on their cached policy, but new senders cannot fetch one.

Step 1 — Publish the DNS record

The id is a freely chosen identifier, conventionally a timestamp. It signals to sending servers whether the policy has changed. Every change to the policy file requires a new id — otherwise senders keep using the old version until max_age expires.

Step 2 — Serve the policy file

The file must be reachable at exactly this URL, with a valid certificate for mta-sts.yourdomain.com and content type text/plain:

Contents:

• Every MX host gets its own mx: line. Wildcards are allowed: mx: *.yourdomain.com
• max_age in seconds — how long sending servers cache the policy. 604800 is one week. Start lower (e.g. 86400) so corrections take effect faster
• Line endings: the file must use CRLF. Some parsers are strict about it

The subdomain also needs an A or CNAME record so the web server is reachable at all.

Step 3 — Enable TLS-RPT

Without reporting you are arming this blind. TLS-RPT makes sending servers report daily which connections were successfully encrypted and which were not:

Reports arrive as compressed JSON. Before you switch to enforce, they tell you whether any senders would fail against your policy.

Step 4 — Switch to enforce

After one or two weeks in testing mode without notable failure reports, change the policy file:

Then bump the id in the DNS record. Without that step the change has no effect.

Common mistakes

• Expired certificate on the mta-sts subdomain: the entire policy becomes invalid and the protection lapses. Automated renewal is mandatory.
• id not bumped: the most common mistake after a policy change.
• Forgotten MX host: under enforce, mail is not delivered to unlisted MX hosts. The backup MX is the usual candidate.
• Redirect instead of direct serving: a redirect to another domain invalidates the policy — the file must live directly on the mta-sts subdomain.
• MX certificates do not match: under enforce the hostname in the certificate is validated too. A certificate issued for the provider name rather than the MX name causes rejected delivery.

MTA-STS or DANE?

Both enforce verified TLS connections by different routes. DANE requires a DNSSEC-signed zone, MTA-STS does not. If you run DNSSEC you can and should deploy both in parallel — different senders support different mechanisms.

Testing

Send an email to hello@analyzemy.email. The report actually fetches your policy file and shows mode, MX patterns, max_age and the TLS-RPT record.