Understanding MTA-STS and TLSRPT

When one mail server sends an email to another mail server, that connection is usually encrypted with TLS (like the "https" of email). The problem is: this encryption is optional by default. This is called "opportunistic TLS."

If an attacker sits between the two mail servers (a "man-in-the-middle"), they can force the connection to drop the encryption or use a fake certificate, and neither mail server will complain. The email still gets delivered. Nobody gets an error. Nobody knows it happened.

Two technologies fix different halves of this problem:

Think of it like this: MTA-STS is the lock on the door. TLSRPT is the security camera that tells you someone tried to pick it.

They are independent of each other. You can set up one without the other, but they work best together.

Normally, when Server A wants to send mail to Server B, Server A looks up Server B's mail server in DNS (MX record) and just tries to connect. If Server A can't establish an encrypted connection, or if it gets tricked into thinking a fake server is the real one, it usually just falls back to sending the email anyway, unencrypted, or to the wrong place.

MTA-STS lets your domain say: "Only deliver mail to me over a valid, encrypted, certificate-checked TLS connection. If you can't do that, do not deliver the mail at all."

MTA-STS only works if the sending server actually checks for it and honors it. It is not something your domain can force onto every sender in the world, as it relies on the other side cooperating. So there are two very different scenarios:

Scenario A: The sending server supports MTA-STS. This is the case described above. The sending server sees your DNS record, fetches your policy, and refuses to deliver mail unless it can do so over a valid, encrypted, verified connection. If it can't, it queues the mail and retries for a while, then eventually bounces it back to the original sender with an error.

Scenario B: The sending server has no idea what MTA-STS is (older or simpler mail software). Here's the important part: that server will never even check for your MTA-STS record. It simply doesn't know the standard exists. So it does whatever it normally does, which, for most old-style mail servers, means attempting opportunistic TLS (try to encrypt, but if that fails, send the email anyway, unencrypted).

In other words, MTA-STS cannot protect a connection if the other side isn't looking for your policy in the first place. It only forces the issue for senders who already support and respect the standard. Every major provider (Gmail, Microsoft 365, etc.) supports it today, but a small, old, or custom-built mail server somewhere on the internet might not.

MTA-STS (and another related standard called DANE) can block insecure delivery - but on their own, they're silent. If mail starts failing because of a TLS problem, you won't know unless someone complains that their email never arrived.

TLSRPT gives you visibility. It tells other mail servers: "When you have a TLS success or failure delivering mail to us, please send us a report about it."

You get a daily report (usually as a JSON file, often gzipped and attached to an email) showing:

Valimail collects and parses TLSRPT reports for you, so instead of digging through raw JSON files, you get a simple dashboard. You'll find it under Reports in the left-hand side menu.

At the top of the page, you can filter by Domain, Policy Mode, MX Host, and Date Received. If you manage several domains, use these filters to narrow down to the one you're troubleshooting.

This is a bar chart showing successful (blue) vs. failed (red) TLS connections per day. It's the fastest way to spot a problem; a sudden spike of red bars usually means something changed (an expired cert, a new sending source, a policy misconfiguration) around that date. Use this chart to line up "when did failures start" with anything you changed on your end.

Below the chart is a table listing one row per report received, per domain/MX host combination. Key columns:

Click on a number in the Failure Count column to drill into the details of what went wrong.

Clicking into a failure count opens a breakdown table with:

These are the result-type values you'll most commonly see in the failure-details section of a report.

certificate-expired

What it means: The receiving mail server's TLS certificate had passed its expiration date at the time of the connection attempt.

Common cause: Certificate renewal process failed or wasn't automated, or an old cert wasn't removed from rotation.

Fix: Renew the certificate immediately. Long-term, automate renewal (e.g., ACME/Let's Encrypt auto-renewal, or a calendar reminder tied to your certificate authority at least 30 days before expiry).

certificate-not-trusted (sometimes certificate-host-mismatch is separate, see below)

What it means: The certificate presented wasn't signed by a Certificate Authority (CA) that the sending server trusts. This can happen with self-signed certificates or an incomplete certificate chain.

Common cause: Missing intermediate certificates on the server, or use of an internal/self-signed cert on a public-facing mail server.

Fix: Make sure your server sends the full certificate chain (leaf + intermediates), not just the end-entity certificate. Use a publicly trusted CA for anything internet-facing.

certificate-hostname-mismatch

What it means: The certificate's Common Name (CN) or Subject Alternative Names (SANs) don't match the hostname the sending server connected to.

Common cause: The MX record points to a hostname that isn't listed on the certificate, often after a migration or when using a shared/wildcard cert that wasn't updated.

Fix: Confirm the exact hostname in your MX records matches a name on the certificate's SAN list. Reissue the certificate if needed to include the correct hostname.

starttls-not-supported

What it means: The sending server tried to start a TLS session (via the STARTTLS command), but the receiving server didn't support it or responded incorrectly. Common cause: Misconfigured mail server software, a firewall/proxy stripping the STARTTLS command in transit, or an outdated MTA that doesn't support STARTTLS at all.

Fix: Check your mail server's STARTTLS configuration directly (you can test with openssl s_client -starttls smtp -connect yourserver.com:25). Check for any network appliance in between (like an old-school "transparent SMTP proxy") that might be interfering.

validation-failure (general TLS validation failure, catch-all)

What it means: A generic bucket for TLS negotiation problems that don't fit the more specific categories above.

Common cause: Varies - can be a cipher suite mismatch, a truncated handshake, or a TLS version incompatibility (e.g., server only supports TLS 1.3, sender only supports up to TLS 1.1).

Fix: Check the report for the sending server's IP and try connecting manually to reproduce the issue. Ensure your server supports at least TLS 1.2 and offers modern cipher suites.

sts-policy-fetch-error

What it means: The sending server saw your MTA-STS DNS record, but couldn't successfully download your policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

Common cause: The web server hosting the policy file is down, the HTTPS certificate on that specific host is invalid, or the file doesn't exist at that exact path. Fix: Manually browse to the policy URL and confirm it loads over valid HTTPS with no certificate errors. Make sure the mta-sts subdomain has its own valid certificate (it's separate from your mail server's certificate).

sts-policy-invalid

What it means: The policy file was fetched successfully, but its contents don't follow the correct format.

Common cause: Typo in the file (wrong syntax, missing version: line, malformed mx: entries), or incorrect line endings/encoding.

Fix: Compare your file line-by-line against the format shown in Part 1 of this guide. The file must be plain text, UTF-8, with each directive on its own line.

sts-webpki-invalid

What it means: Similar to sts-policy-fetch-error, but specifically means the certificate used to serve the policy file over HTTPS failed standard browser/webPKI validation (expired, self-signed, wrong hostname, etc.).

Common cause: The mta-sts.yourdomain.com subdomain has a lapsed or misconfigured certificate - easy to forget since it's a separate host from your regular mail or web certificates.

Fix: Reissue/renew the certificate specifically for the mta-sts. subdomain. If you use automated certificate renewal elsewhere, make sure this subdomain is included in that automation.

dnssec-invalid

What it means: Relevant to DANE-based validation (a cousin of MTA-STS), the DNSSEC signature on your DNS records didn't validate correctly.

Common cause: DNSSEC misconfiguration, an expired DNSSEC signature, or a broken chain of trust from the DNS root down to your zone.

Fix: Use a DNSSEC validation tool (like dnsviz.net) to check your zone. Contact your DNS provider if signatures are expired or misconfigured - this is often a provider-side automated process that broke.

dane-required

What it means: The receiving domain published a DANE TLSA record requiring DANE validation, but the connection failed to validate against it.

Common cause: The TLSA record doesn't match the certificate currently in use (common after a certificate renewal, when the TLSA record wasn't updated to match).

Fix: Whenever you renew or replace a certificate on a DANE-protected server, update the corresponding TLSA DNS record at the same time. Consider automating this alongside your certificate renewal process.

connection-failure / tls-timeout / connection-timeout

What it means: The sending server couldn't even establish a network connection, or it timed out during the handshake.

Common cause: Firewall blocking the connection, mail server down or overloaded, network routing issue, or a rate-limit/blocklist silently dropping the connecting IP.

Fix: Confirm the mail server is up and reachable on port 25 (and/or 465/587 depending on setup) from external networks. Check firewall logs for dropped connections from the reporting sender's IP ranges.