Mailrith
Start

Browse guides

Jump between email sending topics and concepts.

MTA-STS and TLS Reporting

MTA-STS and TLS reporting are advanced controls for domains that need stronger protection for inbound email transport.

6 min read

Overview

Normal TLS 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.

What to Do

  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.

What to Check

  • 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, 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.

Note

MTA-STS is important for some organizations, but it is not the first setting to fix when a Mailrith campaign has deliverability trouble.

Related Guides

  • Sender Domains and Email Authentication : 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 : An email can include several sender-related addresses. Each address has a separate role for delivery, authentication, or replies.
  • DNS, PTR, and Reverse DNS : DNS records identify your domain. Reverse DNS helps inbox providers check that a sending IP address has a valid hostname.
Previous
TLS and Secure Sending
Next
ARC and Forwarded Email

On this page

Jump to the section you need.

Create your account and choose the plan that fits your workflow.

Get Started