What is MTA-STS and TLS-RPT? Securing Email in Transit

The problem: SMTP and opportunistic TLS

The Simple Mail Transfer Protocol (SMTP) was designed in 1982, long before encryption was a mainstream concern. When STARTTLS was later bolted on, it was made opportunistic: a sending server asks the receiving server whether it supports TLS, and if the answer is yes, the connection is upgraded to an encrypted channel. If the answer is no, the message is sent in plain text.

This creates two serious vulnerabilities. First, a man-in-the-middle attacker sitting between two mail servers can strip the STARTTLS offer from the conversation, forcing a downgrade to plain text. The sending server has no way to know that encryption was supposed to be available. Second, an attacker can present a fraudulent certificate and the sending server, with no policy to consult, may accept it without complaint.

The result is that email in transit is far less protected than most people assume. Even organisations that have deployed DMARC, SPF, and DKIM are still vulnerable to interception if they have not addressed transport-layer security. MTA-STS was created to solve this problem.

What is MTA-STS?

MTA-STS stands for Mail Transfer Agent Strict Transport Security. It is defined in RFC 8461 and was published in September 2018. The protocol allows a domain owner to declare that their mail servers support TLS and that sending servers should refuse to deliver mail over an unencrypted connection. In other words, it turns opportunistic TLS into mandatory TLS.

MTA-STS works through two components that work together: a DNS TXT record that signals the policy exists and a policy file hosted over HTTPS that contains the actual rules. When a sending server wants to deliver a message to your domain, it checks for the DNS record, fetches the policy file, and then enforces the rules described in that file. If the receiving server cannot provide a valid TLS certificate, or if TLS negotiation fails, the sending server will not deliver the message.

You can check whether a domain has a valid MTA-STS policy using our free MTA-STS Checker.

How MTA-STS works: DNS record + HTTPS policy file

Setting up MTA-STS requires two pieces. The first is a DNS TXT record published at _mta-sts.yourdomain.com. This record tells sending servers that your domain has an MTA-STS policy and provides a version identifier so they know when the policy has changed. Here is an example:

v=STSv1; id=20260323001;

The v tag is always STSv1. The id tag is a unique string that you change every time you update your policy file. Sending servers cache your policy, and they use the id value to detect changes. A common convention is to use a timestamp (e.g. 20260323001), but any alphanumeric string works.

The second piece is the policy file itself. This must be hosted at a very specific URL:

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

The file must be served over HTTPS with a valid, publicly trusted certificate. This is critical because the entire point of MTA-STS is to establish trust through the web PKI. If the policy file itself were served over an insecure channel, an attacker could tamper with it.

The MTA-STS policy file

The policy file is a plain text file with a simple key-value format. Here is a complete example for a domain that uses Microsoft 365:

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Here is what each field means:

If your domain uses Google Workspace, your policy file would list different mx patterns:

version: STSv1
mode: enforce
mx: *.google.com
mx: *.googlemail.com
max_age: 604800

The mx entries must match the hostnames that your MX records resolve to. If there is a mismatch, sending servers that enforce your policy will refuse to deliver mail, because the certificate on the receiving server will not match the permitted patterns.

What is TLS-RPT?

TLS-RPT stands for SMTP TLS Reporting and is defined in RFC 8460. It is the reporting companion to MTA-STS (and DANE). While MTA-STS tells sending servers to require encryption, TLS-RPT tells them where to send reports when TLS negotiation fails. Without TLS-RPT, you have no way to know that messages are being rejected or downgraded.

TLS-RPT reports are sent as JSON files (either as email attachments or via HTTPS POST) and contain details about each failure: the sending server, the receiving MX host, the type of failure (certificate expired, certificate mismatch, STARTTLS not offered), and the number of affected sessions.

Setting up TLS-RPT requires a single DNS TXT record published at _smtp._tls.yourdomain.com. Here is an example:

v=TLSRPTv1; rua=mailto:[email protected];

The v tag is always TLSRPTv1. The rua tag specifies where reports should be sent. You can use a mailto: URI for email delivery or an https: URI for HTTPS POST delivery. You can even specify both, separated by a comma.

Check your domain's TLS-RPT configuration with our free TLS-RPT Checker.

How to set up MTA-STS: step by step

Follow these steps to deploy MTA-STS for your domain. If you are not sure whether your domain already has a policy in place, start by running a check with our MTA-STS Checker.

1. Confirm your mail servers support TLS. Before enabling MTA-STS, verify that every MX host for your domain supports STARTTLS and presents a valid, publicly trusted certificate. If any of your mail servers have an expired or self-signed certificate, MTA-STS enforcement will cause mail to bounce. Use our SSL Checker or read our guide on SSL certificate monitoring to understand what to check.
2. Create the policy file. Write a plain text file named mta-sts.txt with the content shown in the policy file section above. Set the mode to testing initially so that failures are reported but mail is not blocked.

   version: STSv1
   mode: testing
   mx: *.mail.protection.outlook.com
   max_age: 86400

   Use a short max_age (86400 = one day) during testing so that sending servers refresh the policy quickly if you need to make changes.

3. Host the policy file over HTTPS. The file must be accessible at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This means you need a subdomain mta-sts.yourdomain.com with a valid SSL certificate. Many organisations host this on a simple static site (Cloudflare Pages, GitHub Pages, or an S3 bucket behind CloudFront). The file must be served with a Content-Type of text/plain.
4. Add the DNS TXT record. Create a TXT record at _mta-sts.yourdomain.com with the following value:

   v=STSv1; id=20260323001;

5. Add a TLS-RPT record. At the same time, set up TLS-RPT (see the next section) so you receive failure reports from sending servers during the testing phase.
6. Monitor reports and validate. Wait at least one to two weeks. Review the TLS-RPT reports for any failures. If everything looks clean, update your policy file to mode: enforce and increase the max_age to at least 604800 (one week). Remember to update the id in your DNS record each time you change the policy file.

How to set up TLS-RPT

TLS-RPT setup is simpler than MTA-STS because it only requires a single DNS record. However, it is just as important. Without TLS-RPT, you will not know when sending servers encounter TLS failures delivering to your domain.

1. Choose a reporting destination. Decide where you want to receive TLS-RPT reports. You can use an email address (the reports arrive as JSON attachments), an HTTPS endpoint, or both. If you are using ShieldMarc, you can point reports to your ShieldMarc reporting address for automatic parsing and dashboard visibility.
2. Add the DNS TXT record. Create a TXT record at _smtp._tls.yourdomain.com with the following value:

   v=TLSRPTv1; rua=mailto:[email protected];

   Replace the address with your own reporting mailbox. To send reports to multiple destinations, separate them with a comma, for example: rua=mailto:[email protected],https://report.example.com/tlsrpt.

3. Verify the record. Use our TLS-RPT Checker to confirm that the record is correctly published and syntactically valid. Reports typically start arriving within 24 hours.

A typical TLS-RPT JSON report looks like this (simplified):

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-03-22T00:00:00Z",
    "end-datetime": "2026-03-23T00:00:00Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": ["version: STSv1", "mode: enforce", "mx: *.mail.protection.outlook.com", "max_age: 604800"],
        "policy-domain": "yourdomain.com"
      },
      "summary": {
        "total-successful-session-count": 1045,
        "total-failure-session-count": 0
      }
    }
  ]
}

The key fields to watch are total-failure-session-count and the failure details array (omitted when there are zero failures). If you see failures, the report will include a result-type such as certificate-expired, certificate-host-mismatch, or starttls-not-supported, which tells you exactly what went wrong.

MTA-STS vs DANE: which should you use?

DANE (DNS-based Authentication of Named Entities, RFC 7672) is an alternative approach to enforcing TLS for email. Instead of relying on an HTTPS-hosted policy file, DANE publishes TLSA records in DNS that pin the certificate (or public key) of the receiving mail server. Sending servers verify the certificate against the TLSA record instead of the public CA system.

For most organisations, MTA-STS is the more practical choice. DNSSEC deployment remains low globally, and many DNS hosting providers do not support it well. MTA-STS works without DNSSEC and is supported by Gmail, Outlook.com, and Yahoo, which together handle the vast majority of consumer and business email. If your domain already has DNSSEC enabled, deploying DANE alongside MTA-STS provides the strongest protection. The two are not mutually exclusive.

You can check your domain's DNSSEC status with our DNSSEC Checker to determine whether DANE is a viable option for you.

Common mistakes to avoid

MTA-STS is straightforward in concept, but the details matter. These are the mistakes we see most often:

• MX patterns that do not match your actual MX hosts. The mx entries in your policy file must match the hostnames that your MX records resolve to. If your MX record points to yourdomain-com.mail.protection.outlook.com but your policy says mx: mail.yourdomain.com, the policy will fail validation and sending servers in enforce mode will refuse delivery.
• Missing or invalid HTTPS certificate on the policy host. The mta-sts.yourdomain.com subdomain must serve the policy file over HTTPS with a valid, publicly trusted certificate. A self-signed certificate, an expired certificate, or a certificate that does not cover the mta-sts subdomain will cause sending servers to ignore your policy entirely.
• Forgetting to update the DNS id when changing the policy. Sending servers cache your MTA-STS policy for the duration specified by max_age. They only re-fetch the policy file when the id in the DNS record changes. If you update the policy file (for example, switching from testing to enforce) but forget to update the id, sending servers will continue using the old cached version until it expires.
• Setting max_age too high during testing. If you set max_age to a year while still in testing mode and then discover a problem, you cannot force sending servers to re-fetch the corrected policy. They will keep the cached version for up to a year. Start with a short max_age (one day or one week) and only increase it once you are confident the policy is correct.
• Deploying MTA-STS without TLS-RPT. MTA-STS without TLS-RPT is like deploying a firewall without logging. You will not know when legitimate mail is being rejected due to TLS failures. Always deploy both together.
• Wrong Content-Type for the policy file. The policy file must be served with Content-Type: text/plain. Some web servers or CDNs default to application/octet-stream for files without a recognised extension. Check your server configuration if sending servers report policy fetch failures.

Where MTA-STS fits in your email security stack

Email security is built in layers, and each protocol addresses a different threat. SPF, DKIM, and DMARC protect your domain from being spoofed. MTA-STS and TLS-RPT protect the message itself while it travels between servers. Here is how they all fit together:

• SPF verifies that the sending server is authorised to send on behalf of your domain.
• DKIM verifies that the message content has not been altered in transit using a cryptographic signature.
• DMARC ties SPF and DKIM together with alignment and tells receiving servers what to do with failures.
• MTA-STS ensures the SMTP connection itself is encrypted, preventing interception and downgrade attacks.
• TLS-RPT gives you visibility into TLS failures so you can detect and fix problems before they affect delivery.

For a comprehensive view of your domain's security posture across all of these layers, run a Security Grade check. It evaluates SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DNSSEC, and more in a single scan and gives you a clear score with actionable recommendations.

Next steps

Now that you understand how MTA-STS and TLS-RPT work, here is where to go next:

• Check your MTA-STS policy with our free MTA-STS Checker to see whether your domain has a valid policy in place.
• Check your TLS-RPT record to verify that you are receiving TLS failure reports.
• Check your DMARC record to confirm your authentication policies are in place before layering on transport security.
• Run a Security Grade check for a complete overview of your domain's email security.
• Read our guide on What is DMARC? if you have not yet set up DMARC for your domain.
• Learn the differences between SPF, DKIM, and DMARC to understand how each protocol contributes to your overall email authentication posture.