# MTA-STS and TLS Reporting > MTA-STS and TLS reporting are advanced controls for domains that need stronger protection for inbound email transport. - Human page: https://mailrith.com/guides/mta-sts-and-tls-reporting - Markdown page: https://mailrith.com/guides/mta-sts-and-tls-reporting.md - Category: Authentication and Deliverability - Reading time: 6 min read - Related keywords: MTA-STS and TLS Reporting, MTA-STS and TLS Reporting guide, Authentication and Deliverability, Authentication and Deliverability guide, email sending guide, email marketing guide, email deliverability guide, TLS and Secure Sending, RFC 8461 MTA-STS, RFC 8460 SMTP TLS Reporting ## AI Agent Notes - Use this page as plain-language guidance for the specific email sending issue named in the title. - Preserve the distinction between Mailrith, an email delivery service, DNS, and inbox providers when explaining fixes. - When a user is running a Mailrith free tool, pair that specific free-tool result with the relevant issue or step section from this guide. ### MTA-STS and TLS Reporting MTA-STS and TLS reporting are advanced controls for domains that need stronger protection for inbound email transport. Normal [TLS](https://mailrith.com/guides/tls.md) helps encrypt email while the message travels between mail servers. MTA-STS is an advanced domain policy. It tells other mail servers to use TLS when they deliver mail to your domain and to verify the certificate correctly. MTA-STS mainly protects mail coming into your domain. It does not control campaigns that Mailrith sends out. MTA-STS protects receiving paths, such as mail delivered to `team@example.com`. It is useful for organizations that need to prevent downgrade attacks on inbound mail delivery. TLS reporting, often called TLS-RPT, lets other mail systems send reports when they cannot deliver mail to your domain securely. These reports help administrators find certificate, DNS, or policy problems. Most Mailrith users do not need to configure MTA-STS before sending campaigns. For campaign sending, first use a trusted email delivery service or secure SMTP settings. Then configure SPF, DKIM, DMARC, and alignment so they pass. If your team manages company mail infrastructure, discuss MTA-STS and TLS-RPT with the mail administrator. A broken policy can affect inbound mail, so deploy the policy carefully and monitor it after release. 1. For Mailrith sending, first confirm that the delivery connection uses secure API or SMTP settings. 2. Set up SPF, DKIM, DMARC, and alignment for the sender domain before you treat MTA-STS as a sending requirement. 3. If you manage inbound mail for your domain, ask your mail administrator whether MTA-STS is already enabled. 4. If you enable MTA-STS, publish the policy carefully. Confirm that the HTTPS policy file is reachable, the DNS TXT record exists, the MX records are correct, and the mail server certificates are valid. 5. If you enable TLS reporting, publish the TLS-RPT DNS record and send reports to a monitored mailbox or reporting tool. 6. After rollout, monitor reports so your team can find inbound mail problems early. - MTA-STS protects inbound delivery to your domain. - TLS-RPT reports secure-delivery problems for mail sent to your domain. - Mail administrators usually manage these settings. Campaign editors usually do not. - Do not deploy MTA-STS unless you control and understand your domain's inbound mail setup. - For Mailrith campaigns, focus first on [TLS and Secure Sending](https://mailrith.com/guides/tls.md), SPF, DKIM, DMARC, and alignment. ## Fix Common Issues ### Missing MTA-STS DNS Record An MTA-STS checker did not find a TXT record beginning with `v=STSv1` at `_mta-sts.yourdomain.com`. 1. First confirm that your organization wants to use MTA-STS for inbound mail. 2. Create the HTTPS policy file at `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt`, then verify that the file is reachable. 3. Confirm that the policy file lists the correct MX hosts and mode. 4. Publish the `_mta-sts` TXT record only after the policy file is ready. 5. Include an `id=` value in the DNS record and change that value whenever the policy file changes. 6. After DNS propagates, run the MTA-STS checker again. ### Multiple MTA-STS Records An MTA-STS checker found more than one MTA-STS TXT record at the `_mta-sts` host. 1. Open the DNS zone for your domain. 2. Find every TXT record at `_mta-sts`. 3. Keep one record that starts with `v=STSv1` and contains the current `id=` value. 4. After you choose the current record to keep, remove the duplicate or old MTA-STS TXT records. 5. Run the MTA-STS checker again and confirm that the MTA-STS result returns only one record. ### MTA-STS Policy ID Missing An MTA-STS checker found an MTA-STS record, but the record does not include an `id=` value. 1. Choose a simple policy id value, such as a date or version number. 2. Edit the `_mta-sts` TXT record and add `id=your-version`. 3. Update the id whenever the HTTPS policy file changes. 4. Wait for DNS propagation, then run the MTA-STS checker again. ### MTA-STS Policy File Needs Confirmation A browser-based MTA-STS checker can see the DNS signal, but it cannot fully verify the remote HTTPS policy file. 1. Open `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt` from a server-side tool, or ask your mail administrator to fetch the file. 2. Confirm that the file is served over HTTPS and uses a valid certificate. 3. Confirm that the file contains the intended mode, max age, and MX host patterns. 4. Confirm that the MX hosts in the policy match your domain's real inbound mail servers. 5. Start in testing mode if your team is not ready to enforce the policy. 6. After you change the policy, monitor TLS reports. ### Missing TLS-RPT Record A TLS-RPT checker did not find a TXT record beginning with `v=TLSRPTv1` at `_smtp._tls.yourdomain.com`. 1. Choose a mailbox or reporting service that will receive and review TLS reports. 2. Create a TXT record at `_smtp._tls`. 3. Use a value such as `v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com` with your real report address. 4. Save the record and wait for DNS propagation. 5. Run the TLS-RPT checker again. ### Multiple TLS-RPT Records A TLS-RPT checker found more than one TLS-RPT TXT record at `_smtp._tls`. 1. Open the DNS zone for your domain. 2. Find every TXT record at `_smtp._tls`. 3. Merge every report destination into one `v=TLSRPTv1` record. 4. After you create the single merged record, remove the duplicate TLS-RPT records. 5. Run the TLS-RPT checker again and confirm that the TLS-RPT result returns only one TLS-RPT record. ### TLS-RPT Report Destination Missing A TLS-RPT checker found a TLS-RPT record, but the record does not include a usable `rua=` destination. 1. Choose a monitored mailbox or reporting service endpoint. 2. Edit the `_smtp._tls` TXT record. 3. Add a destination such as `rua=mailto:tls-reports@yourdomain.com`. 4. Use only destinations that your team can process. 5. After DNS propagates, run the TLS-RPT checker again. > MTA-STS is important for some organizations, but it is not the first setting to fix when a Mailrith campaign has deliverability trouble. Related resources: - [TLS and Secure Sending](https://mailrith.com/guides/tls.md): Understand the baseline TLS behavior to configure before MTA-STS. - [RFC 8461 MTA-STS](https://www.rfc-editor.org/rfc/rfc8461): The IETF standard for SMTP MTA Strict Transport Security. - [RFC 8460 SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460): The IETF standard for SMTP TLS reports. ## Related Guides - [Sender Domains and Email Authentication](https://mailrith.com/guides/sender-domains-and-authentication.md): Your sender domain is what inbox providers learn to trust. Authentication proves that your email delivery service is allowed to send email for your domain. - [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email can include several sender-related addresses. Each address has a separate role for delivery, authentication, or replies. - [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain. Reverse DNS helps inbox providers check that a sending IP address has a valid hostname.