Email & webmail

Set up MTA-STS and TLS-RPT to secure inbound email

How MTA-STS forces encrypted delivery to your mail servers, how TLS-RPT reports problems, and how to publish the DNS records and HTTPS policy file step by step.

AdvancedEmail domains3 min read

SMTP encryption between mail servers is normally opportunistic: if a server offers STARTTLS it is used, but an attacker in the middle can strip it and read the mail. MTA-STS (Mail Transfer Agent Strict Transport Security) lets you tell senders "only deliver to my MX servers over valid TLS". TLS-RPT sends you reports when that fails. This guide sets up both.

Before you start

  • Your MX servers must support STARTTLS with a valid, publicly trusted certificate whose name matches the MX hostname.
  • You need to host a small file over HTTPS on mta-sts.yourdomain.com.
  • Access to your DNS zone.

How MTA-STS works

  1. A sending server sees your _mta-sts TXT record.
  2. It fetches your policy from https://mta-sts.example.com/.well-known/mta-sts.txt.
  3. It caches the policy and, in enforce mode, refuses to deliver unless the MX matches the policy and TLS is valid.

Create the policy file

Create mta-sts.txt (plain text, CRLF or LF line endings):

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mailprovider.example
max_age: 86400
  • mode – testing (report only), enforce, or none (to retire the policy).
  • mx – one line per allowed MX host; wildcards match one label.
  • max_age – how long senders cache it in seconds; start short, raise to weeks once stable.

Host the policy over HTTPS

  1. Create a subdomain mta-sts.example.com (in cPanel: Domains → Domains → Create A New Domain) and make sure it has a valid SSL certificate (AutoSSL covers it).
  2. Upload the file to .well-known/mta-sts.txt in the subdomain's document root.
  3. Check: curl https://mta-sts.example.com/.well-known/mta-sts.txt returns the file with no redirects.

Publish the DNS records

NameTypeValue
_mta-sts.example.comTXTv=STSv1; id=20260101T000000
_smtp._tls.example.comTXTv=TLSRPTv1; rua=mailto:tlsrpt@example.com

The id is any string that changes whenever you change the policy file – a timestamp works well.

Move from testing to enforce

  1. Run in testing mode for a few weeks and read the TLS-RPT reports (JSON, often gzipped) sent to your rua address.
  2. Fix any MX certificate issues they reveal.
  3. Change mode: enforce, raise max_age (for example 604800 or more) and update the id in DNS.

Warning: In enforce mode, an expired MX certificate or a new MX host not listed in the policy means senders hold or bounce your mail. Update the policy before changing MX records, and monitor certificate expiry.

Troubleshooting

  • Policy not found: the file must be served at the exact path over HTTPS with a valid certificate and no redirect.
  • Reports show certificate errors: the MX certificate doesn't match the MX hostname or is self-signed.
  • Changes ignored: you didn't update the id in the TXT record.

FAQ: MTA-STS and TLS-RPT

Is MTA-STS the same as DANE?

Both enforce TLS for mail. DANE relies on DNSSEC and TLSA records; MTA-STS relies on HTTPS and the web PKI, which makes it easier to deploy without DNSSEC.

Does MTA-STS protect mail I send?

No. It protects mail sent to your domain by servers that support MTA-STS. Your outgoing mail follows the recipient's policy.

Do I need TLS-RPT?

It's optional but strongly recommended, because it shows delivery problems before you switch to enforce.

Next steps

Was this guide helpful?

Still stuck?

Ask MdmHost AI for a quick answer, or open a ticket and our team will take a look. We are here 24/7.