# MTA-STS and TLS Reporting > MTA-STS and TLS reporting are advanced controls for domains that want 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 free tool, pair the 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 want stronger protection for inbound email transport. Normal [TLS](https://mailrith.com/guides/tls.md) helps encrypt email while it travels between mail servers. MTA-STS is an advanced domain policy that tells other mail servers to use TLS when delivering mail to your domain and to verify the certificate properly. MTA-STS is mainly about mail coming into your domain, not campaigns Mailrith sends out. It protects receiving paths such as mail delivered to `team@example.com`. It is useful for organizations that care deeply about preventing downgrade attacks on inbound mail delivery. TLS reporting, often called TLS-RPT, lets other mail systems send reports when they have trouble delivering mail to your domain securely. These reports can help administrators find certificate, DNS, or policy problems. Most Mailrith users do not need to configure MTA-STS before sending campaigns. For campaign sending, the practical baseline is to use a reputable email delivery service or secure SMTP settings, then make SPF, DKIM, DMARC, and alignment pass. If your team manages company mail infrastructure, MTA-STS and TLS-RPT can be worth discussing with the mail administrator. A broken policy can affect inbound mail, so it should be deployed carefully and monitored. 1. For Mailrith sending, first make sure the delivery connection uses secure API or SMTP settings. 2. Set up SPF, DKIM, DMARC, and alignment for the sender domain before treating 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 enabling MTA-STS, publish the policy carefully and confirm the HTTPS policy file, DNS TXT record, MX records, and mail server certificates are correct. 5. If enabling TLS reporting, publish the TLS-RPT DNS record and route reports to a monitored mailbox or reporting tool. 6. Monitor reports after rollout so inbound mail problems are caught early. - MTA-STS protects inbound delivery to your domain. - TLS-RPT reports secure-delivery problems to your domain. - These settings are usually managed by mail administrators, not campaign editors. - Do not deploy MTA-STS casually if you do not control the 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 A checker did not find a TXT record beginning with `v=STSv1` at `_mta-sts.yourdomain.com`. 1. First confirm that your organization really wants MTA-STS for inbound mail. 2. Create and verify the HTTPS policy file at `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt`. 3. Confirm the policy file lists the right 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. Run the MTA-STS checker again after DNS propagates. ### Multiple MTA-STS Records A checker found more than one MTA-STS TXT record at the `_mta-sts` host. 1. Open the DNS zone for the domain. 2. Find every TXT record at `_mta-sts`. 3. Keep one record that starts with `v=STSv1` and has the current `id=` value. 4. Remove duplicate or old MTA-STS TXT records. 5. Run the checker again and confirm only one record is returned. ### MTA-STS Policy ID Missing A 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 and run the checker again. ### MTA-STS Policy File Needs Confirmation A browser-based 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 it. 2. Confirm the file is served over HTTPS with a valid certificate. 3. Confirm the file contains the intended mode, max age, and MX host patterns. 4. Confirm the MX hosts in the policy match the domain's real inbound mail servers. 5. Start in testing mode if your team is not ready to enforce. 6. Monitor TLS reports after changing the policy. ### Missing TLS-RPT Record A 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 actually 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 checker found more than one TLS-RPT TXT record at `_smtp._tls`. 1. Open the DNS zone for the domain. 2. Find every TXT record at `_smtp._tls`. 3. Merge every report destination into one `v=TLSRPTv1` record. 4. Remove duplicate TLS-RPT records. 5. Run the checker again and confirm only one TLS-RPT record is returned. ### TLS-RPT Report Destination Missing A 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 your team can process. 5. Run the TLS-RPT checker again after DNS propagation. > MTA-STS is important for some organizations, but it is not the first thing 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 that comes 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 the name inboxes learn to trust, and authentication proves that your email delivery service is allowed to send for it. - [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email has several sender-related addresses, and each one has a different job in delivery and replies. - [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain, while reverse DNS helps inboxes check whether a sending IP has a sensible hostname.