Setting Up MTA-STS and TLS-RPT

MTA-STS (SMTP MTA Strict Transport Security) is an open standard that tells sending mail servers that your domain accepts mail only over an authenticated TLS connection. It protects incoming mail to your domain against downgrade and man-in-the-middle attacks, in which an attacker strips the TLS negotiation and the message is delivered in plain text.

📘

Who configures it

MTA-STS applies to mail that other servers deliver to your domain. The domain administrator sets it up at the mail hosting provider, the DNS provider, and the web server — there is no MTA-STS screen in a marketing platform, so do not look for one in the interface. Only mail servers that support MTA-STS enforce the policy; other servers keep delivering mail without the extra MTA-STS check.

MTA-STS and DMARC

MTA-STS and DMARC solve different problems and are configured independently. DMARC helps receiving servers detect email that uses your domain as a forged sender domain; MTA-STS protects the delivery of email to your domain against attacks on the TLS connection.

MTA-STS requires neither DMARC nor a specific DMARC policy. Sender authentication is set up separately — see Setting Up Email Domain Authentication.

What the Setup Consists Of

A working MTA-STS setup has four parts:

1. A working web host on the mta-sts.<yourdomain> subdomain, with a valid TLS certificate.
2. A policy file published over HTTPS at https://mta-sts.<yourdomain>/.well-known/mta-sts.txt.
3. A TXT record at _mta-sts.<yourdomain> that announces the policy and its version.
4. A TXT record at _smtp._tls.<yourdomain> that asks reporting senders to send you TLS reports (TLS-RPT).

Your domain must also have MX records — MTA-STS describes how mail to those hosts must be delivered. If the domain has no mail hosting, set that up first.

Before you start, check that every MX host of your domain supports STARTTLS and uses a valid TLS certificate. If inbound mail passes through a third-party gateway, filtering service, or forwarder, ask its provider which MX hosts belong in the MTA-STS policy.

Setup Order

Publish the policy file before the DNS record that announces it. Once _mta-sts is published, sending servers start looking for the policy, so the file has to be in place and correct by then. The order below follows the recommendations of Google Workspace and Microsoft.

1. Enable TLS reports.
2. Create the mta-sts subdomain and its hosting.
3. Publish the policy file in testing mode and check it.
4. Publish the _mta-sts DNS record.
5. Review the reports and switch to enforce.

1. Enable TLS Reports (TLS-RPT)

TLS-RPT (RFC 8460) asks sending servers to report the outcome of TLS negotiation with your mail hosts. Enable it first, so the reports cover the whole testing period.

Add a TXT record:

Reports arrive as daily aggregate files. They show which senders failed to establish a compliant connection and why.

Typical failure reasons in the reports:

• the MX host is not in the policy;
• the certificate has expired;
• the certificate was not issued for that MX host;
• the certificate chain is not trusted;
• STARTTLS is unavailable;
• the TLS negotiation failed.

📘

Reports to an address in another domain

If the report address belongs to a different domain than the one being reported on, that domain has to confirm it agrees to receive the reports with an additional DNS record. The requirement is described in RFC 8460; a reporting service will tell you the exact record to add.

2. Create the mta-sts Subdomain

The policy file is served over HTTPS from a dedicated subdomain named mta-sts, so that subdomain has to exist as a working web host:

1. Create an A, AAAA, or CNAME record for mta-sts.<yourdomain> pointing at the web server or hosted service that will serve the file.
2. Configure that server to serve the /.well-known/ path.
3. Issue a TLS certificate valid for mta-sts.<yourdomain>.

Without these three steps the policy URL does not exist, and everything that follows fails.

3. Publish the Policy File

The policy file is a plain-text file served over HTTPS at:

https://mta-sts.<yourdomain>/.well-known/mta-sts.txt

Requirements for the file:

• It must be served over HTTPS with a valid certificate issued for mta-sts.<yourdomain>.
• It must be returned with the text/plain content type.
• Redirects to another host are not allowed.

File contents:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.mailprovider.com
max_age: 604800

• version — always STSv1.
• mode — the policy mode, see below. Start with testing.
• mx — one line per mail host allowed to receive mail for the domain. The values must match your MX records. Wildcards are allowed for the first label.
• max_age — how long, in seconds, a sending server may cache the policy. A week (604800) is a common starting value; a month (2592000) is typical for a stable policy.

Check the file as described in Verify before moving on.

4. Publish the DNS Record

Once the policy file is reachable and correct, announce it with a TXT record:

• v — the version of the standard. Always STSv1.
• id — an identifier of the current policy version.

Change the id value every time you edit the policy file. Sending servers cache the policy and re-read the file only when the id changes.

According to RFC 8461, id is 1 to 32 characters long and contains only Latin letters and digits. It does not have to be a date — a timestamp is simply a convenient way to produce unique values.

5. Choose the Policy Mode

Start with testing. Keep the policy in testing for at least several days, and for domains with low or irregular mail volume, several weeks. Switch to enforce only once the reports cover every significant source of inbound mail and show no systematic failures.

In enforce mode, errors in the mx list or in the TLS certificates of those hosts can delay or prevent delivery of incoming email. The exact caching and retrieval logic is defined by RFC 8461.

Verify

Check the policy file:

curl -I https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

The response must be 200, with Content-Type: text/plain and no redirect. Then read the file itself and confirm the syntax is valid and the mx lines match your real MX records:

curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
dig +short MX yourdomain.com

Check both TXT records, and repeat the query against a second resolver to confirm the records have propagated:

dig +short TXT _mta-sts.yourdomain.com
dig +short TXT _smtp._tls.yourdomain.com
dig +short TXT _mta-sts.yourdomain.com @1.1.1.1

Confirm that every host listed in mx accepts STARTTLS with a valid certificate, and wait for the first TLS reports before switching the mode to enforce. An online MTA-STS validator is a useful extra check, but treat it as a second opinion rather than as proof that the setup is correct.

Repeat the check after any change to the domain's MX records — an outdated mx list in an enforced policy causes delivery failures for mail sent to your domain.

If Something Breaks After You Switch to enforce

1. Change mode: enforce to mode: testing in the policy file.
2. Publish the updated file.
3. Change the id in the _mta-sts DNS record so senders fetch the new version.
4. Read the TLS reports and fix the MX hosts or certificates.

Because of caching, the change does not take effect immediately. Don't delete the DNS record instead: senders can keep using the cached policy until max_age expires.

Changing Your MX Servers

Change the MX records and the policy together:

1. Put the policy back into testing mode and change its id.
2. Add the new MX hosts to the policy file before you change DNS.
3. Check their TLS certificates and STARTTLS.
4. Change the domain's MX records.
5. Read the TLS reports.
6. Return to enforce and update the id again.

Account for the previous max_age: some senders may keep applying the cached policy until that period ends.

Related Articles

• Setting Up Email Domain Authentication
• FAQ: Setting Up Digital Signatures and Domain Reputation
• Domain Verification Troubleshooting