How to Set Up MTA-STS and TLS-RPT for Email Security

MTA-STS helps a receiving domain tell sending mail systems which mail servers should accept its messages and that those connections must use trusted TLS. TLS-RPT adds reporting: participating senders can send you information about TLS delivery failures and policy problems. If you are researching how to set up MTA-STS and TLS-RPT for email security, begin with your inbound mail configuration, not with a DNS record.

These controls do not replace SPF, DKIM, or DMARC. They address a different part of the journey: the encrypted connection between mail servers. A policy that names an old or misconfigured MX host can disrupt delivery, so test the complete setup before enforcing it.

1. Confirm your mail-hosting setup is ready

Start with the domain’s current MX records. List every hostname they point to, including hosts used for backup or regional delivery. If your provider manages inbound mail, ask it to confirm which MX names belong in an MTA-STS policy and whether each one supports TLS with a valid certificate.

Check the names, not just the provider’s brand. A domain might have MX records such as mx1.mail.example.com and mx2.mail.example.com, while its provider also operates other hosts that are not listed for your domain. Your policy should cover the MX hostnames that can receive mail for the domain.

Check each listed host’s certificate and TLS configuration. The certificate must be trusted and valid for the MX hostname that the sending mail system connects to. A certificate that covers a provider’s website but not its mail host is not a suitable substitute.

Ask your mail provider about planned host changes, too. If an MX hostname is due to change during setup, wait until you have the final list or coordinate the policy update with the provider. An unlisted replacement host can cause delivery problems once a sender has cached an enforced policy.

2. Publish a TLS-RPT reporting destination

Choose where reports should go before publishing the DNS record. You can use a mailbox that accepts reports or a TLS reporting service that gives you an address or HTTPS destination. Confirm the destination is monitored and that your mail system will accept incoming reports there.

Publish a TXT record at _smtp._tls.example.com, replacing example.com with your domain. A mail destination uses a value in this format: v=TLSRPTv1; rua=mailto:tls-reports@example.com. If your reporting service supplies a different destination, use the exact URI it provides.

Keep the mailbox separate from a person’s everyday inbox if possible. TLS reports may arrive as structured attachments, and a dedicated mailbox makes it easier to set access rules, retain messages, and route review to the administrator responsible for mail delivery. Check its storage and filtering settings before publishing the record.

DNS changes may take time to appear because resolvers cache records according to their TTL. After publishing the record, query the authoritative DNS service and a public resolver to confirm that both return the intended TXT value. A typo in the record name can leave the destination invisible to senders.

3. Host the MTA-STS policy file

Place the policy at https://mta-sts.example.com/.well-known/mta-sts.txt, using your own domain in place of example.com. The endpoint must be reachable over HTTPS, and its certificate must be valid for the hostname mta-sts.example.com. A file on the website’s usual homepage path will not meet this requirement.

The policy is a plain-text file. For an initial test, use fields like these:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Replace the sample MX names with the actual inbound hosts for your domain. The max_age value is the number of seconds a sender may cache the policy; the example above is one day. A shorter initial period can make a test policy easier to revise, while a longer period means senders may retain it longer.

Use testing before enforcement. In this mode, senders can report policy failures without treating the policy as a demand to reject mail that cannot be delivered using the required TLS conditions. Test the URL from outside your network and verify that it returns the file without a login, redirect loop, or web application error.

4. Publish the MTA-STS discovery record

Senders discover the policy through a TXT record at _mta-sts.example.com. Its value includes the version and a policy identifier, for example: v=STSv1; id=20261104a. Choose an identifier you can track in your change log rather than reusing an old value.

Change the identifier whenever you publish a revised policy file. This tells sending systems that they should check for an updated policy instead of relying only on a cached copy. The identifier is a discovery signal; it does not replace the policy file or its HTTPS hosting.

Publish the record only after the policy file is reachable at the required URL. Then query the TXT record and load the URL from an external connection. The DNS record and the file must describe the same current setup: a fresh identifier pointing to a missing or outdated file is still a broken deployment.

5. Check discovery, policy, and MX coverage

Verify each layer independently. Query the _smtp._tls and _mta-sts TXT records, request the policy URL over HTTPS, and compare every mx: line with your live MX records. This three-part check catches errors that a DNS lookup alone cannot find.

Confirm that the HTTPS response uses a trusted certificate for the MTA-STS hostname and that the file contains the expected fields. Then check each MX host for TLS support and a certificate valid for that exact host. If your provider has several inbound MX names, test each one rather than assuming they share an identical certificate configuration.

Keep a record of the results, including the DNS values, policy identifier, MX hostnames, and date checked. That gives the next administrator a useful baseline if reports later show a failure. For more email setup reading, the YourTrend blog RSS feed can be added to a team’s reference list.

6. Review reports before enforcing the policy

Leave the policy in testing mode while you collect TLS-RPT feedback and check normal mail flow. Reports can identify sending systems that encountered a certificate issue, a TLS negotiation problem, or a mismatch between your advertised MX hosts and the policy. A report is evidence to investigate, not an automatic instruction to change a DNS record.

Inspect the report’s reporting period, affected policy domain, and receiving host details. Compare them with your own MX inventory and provider’s configuration. If a legitimate host is missing, update the policy file and change the policy ID; if a certificate is wrong, have the provider correct it before enforcement.

Also test delivery from the mail systems your organization depends on, such as a business partner or a separate service you control. Confirm that messages arrive and that your inbound logs show successful TLS connections. A quiet report mailbox alone does not prove that every sender has tested your policy.

Use a defined review window that reflects your mail volume and operational needs. There is no universal number of days that guarantees every sending system will appear in reports, so do not treat a specific calendar interval as proof of coverage. Record what you checked and which known senders successfully delivered during the test.

7. Enforce, monitor, and maintain the setup

When the MX list, certificates, HTTPS policy, and test results are ready, revise the policy mode from testing to enforce. Publish the changed policy file and a new _mta-sts identifier. Verify both from outside your network after the update, then continue checking TLS-RPT reports and mail-flow logs.

Under enforcement, a sending system that supports MTA-STS is expected to use TLS and validate the receiving host according to the policy. If it cannot do so, delivery may be delayed while the sender retries rather than sent over an unprotected connection. Coordinate the change with your mail provider and support team so they know how to diagnose a delivery delay.

Document the maintenance steps alongside the policy URL and DNS records. When an MX host changes, update the policy before relying on the new host; when a certificate is renewed, verify its hostname coverage and trust chain. If enforcement exposes a problem, changing the mode back to testing can reduce policy impact, but update the policy ID and confirm the revised file is served correctly.

Assign an owner to review the reporting mailbox or service and to track DNS and certificate changes. If you publish operational notes or mail-service updates for colleagues, the YourTrend blog feed is another feed they can follow. A named owner and a recorded MX change procedure make the next renewal or provider migration easier to handle.