How MTA-STS and TLS-RPT work together

What MTA-STS actually enforces

MTA-STS requires two published artifacts that must agree: a DNS TXT record at _mta-sts.example announcing that a policy exists, and a policy file fetched over HTTPS from a fixed URL, https://mta-sts.example/.well-known/mta-sts.txt, listing the domain's actual mail server hostnames and an enforcement mode.

A sending server that supports MTA-STS checks for this policy before delivering mail, and if the policy's mode is enforce, it will only deliver over a TLS connection where the certificate validates against one of the listed hostnames. If that fails, for any reason, the sender refuses to deliver in plain text as a fallback, which is precisely the behavior that stops a silent downgrade attack from succeeding.

The mode field has three values: none disables enforcement while keeping the policy published, testing reports failures via TLS-RPT without blocking delivery, and enforce actually rejects delivery when the required TLS connection cannot be established. A new deployment should start at testing, not enforce, to avoid an untested policy blocking real mail.

What TLS-RPT reports on

TLS-RPT is a single TXT record at _smtp._tls.example naming one or more addresses, typically mailto: or an HTTPS endpoint, that should receive a daily aggregate report. Unlike MTA-STS, TLS-RPT enforces nothing on its own; it exists purely to make TLS negotiation failures, which otherwise generate no signal back to the domain owner at all, visible.

Reports arrive as JSON, grouped by the policy type involved, MTA-STS or DANE, along with a result for each: success, or a specific failure reason such as certificate-expired, certificate-not-trusted, or validation-failure. A domain publishing TLS-RPT even without MTA-STS still receives reports about ordinary opportunistic STARTTLS failures, which is useful on its own, but the reports become far more actionable once there is an actual enforced MTA-STS policy for them to report violations against.

Why the two are meant to be deployed together

Publishing MTA-STS at mode: enforce without TLS-RPT means any delivery failures caused by the policy, such as a mail server hostname you forgot to include in the policy file, or a certificate that quietly expired, produce no notification at all; mail simply stops arriving from senders that honor the policy, with no visible cause.

TLS-RPT closes that blind spot. Deploying it alongside MTA-STS, even during the testing phase, means a misconfiguration in the policy shows up in the next day's report as a spike in failures, giving you a chance to fix it before switching to enforce, and continued visibility afterward in case something changes later, such as a certificate renewal that unexpectedly used a different hostname.

A safe rollout sequence

• Publish the TLS-RPT record first, or at the same time as MTA-STS, so reporting is active from day one

• Publish the MTA-STS DNS record and policy file with mode: testing, listing every current mail server hostname

• Watch TLS-RPT reports for a period, commonly one to two weeks, confirming no unexpected failures appear against the testing policy

• Switch the policy's mode to enforce once reports are clean

• Keep watching TLS-RPT reports indefinitely afterward, since a later infrastructure change, such as adding a new mail server, requires the MTA-STS policy file to be updated too, and a forgotten update would otherwise cause silent delivery failures

A common failure: the policy file's own certificate

Because the policy file itself is fetched over HTTPS, the hostname serving it, mta-sts.example, needs its own valid, trusted TLS certificate, separate from the certificates on the mail servers the policy describes. An expired or misconfigured certificate on that hosting hostname breaks MTA-STS entirely, since senders cannot even retrieve the policy to find out what it says, regardless of how correctly the mail servers themselves are configured.

This dependency is easy to overlook because the hosting hostname is often on completely different infrastructure than the mail servers, such as a general web host rather than the mail platform, which means its certificate can lapse without anyone connecting the resulting mail delivery problems back to it.

How this relates to DANE

DANE (DNS-based Authentication of Named Entities) is a related but separate mechanism that pins a mail server's TLS certificate using a TLSA record, secured by DNSSEC rather than by an HTTPS-hosted policy file. Where MTA-STS relies on the web PKI, trusted certificate authorities, DANE relies on DNSSEC's chain of trust instead, which makes it a meaningfully different security model rather than a redundant alternative.

TLS-RPT reports on both mechanisms using the same record and the same report format, distinguishing MTA-STS failures from DANE failures within the same daily report. A domain can deploy MTA-STS, DANE, both, or neither; TLS-RPT is useful in every one of those cases, since it also reports on ordinary opportunistic STARTTLS behavior even when neither stricter mechanism is in place, giving a domain owner visibility into TLS delivery outcomes as a first step before deciding whether either stricter mechanism is worth the additional operational commitment.