all guides

// how to fix

Protect your incoming mail with MTA-STS and TLS-RPT

MTA-STS forces other servers to use encryption when they deliver email to your domain. TLS-RPT sends you reports when that fails. Both are optional but recommended.

What it means

When a server delivers an email to your domain, it can encrypt the connection with TLS. By default this is optional: if someone in the middle blocks encryption, the email is sent in clear text and can be read or redirected.

  • MTA-STS (Mail Transfer Agent Strict Transport Security) lets you say: "only deliver to my mail servers with valid encryption, otherwise do not deliver".
  • TLS-RPT (TLS Reporting) asks other servers to send you a daily report when they had trouble connecting securely.

Both protect the email you receive. They do not change how your sent emails are scored.

Why it matters

They block interception of incoming email, such as invoices, password resets and contracts. Gmail, Microsoft and other large providers respect MTA-STS. They are recommended for businesses, but optional for small senders.

How to check

Use the Domain scanner at /domain-scanner. It looks for the MTA-STS record, downloads the policy file and checks the TLS-RPT record.

How to fix it

MTA-STS needs three pieces: a policy file on a website, a DNS record, and mail servers with valid certificates.

  1. Check your MX servers. They must offer TLS with a valid certificate matching their name. Google Workspace and Microsoft 365 already do.
  2. Create the policy file, a plain text file served at exactly https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Start in testing mode:
    version: STSv1
    mode: testing
    mx: *.mail.protection.outlook.com
    max_age: 86400
    List each of your MX hosts on its own mx: line. For Google Workspace, use mx: *.google.com and mx: *.googlemail.com, or the exact names your MX records show.
  3. Publish the website mta-sts.yourdomain.com with a valid https certificate. Any simple static hosting works.
  4. Add the MTA-STS TXT record. Change the id each time you edit the policy file:
    _mta-sts.yourdomain.com  TXT  "v=STSv1; id=20261030"
  5. Add the TLS-RPT TXT record to receive reports:
    _smtp._tls.yourdomain.com  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"
  6. Read the reports for a few weeks. When there are no failures, change mode: testing to mode: enforce, raise max_age (for example 604800, one week), and change the id in DNS.

Be careful

In enforce mode, if your certificate expires or your MX changes without updating the policy, other servers will stop delivering to you. Update the policy file whenever you change email provider.

Check that it is fixed

DNS changes are not instant. Most are visible within a few minutes, but some providers take up to 24 to 48 hours.

Run the Domain scanner again: MTA-STS and TLS-RPT should both be found and valid.

The standards: RFC 8461 (MTA-STS) and RFC 8460 (TLS-RPT).

Check that it is fixed

DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.

Related guides