Encryption between mail servers is optional and negotiated in the clear, so it can quietly fail or be stripped without either end noticing. MTA-STS makes it mandatory for mail to your domain, and TLS-RPT has the servers sending it report back on how often it worked — two DNS records and a policy file, with nothing routed through us.
When one mail server hands a message to another, encryption is opportunistic. The offer to upgrade the connection is made in plain text, and if it is refused, removed in transit, or fails on a certificate that does not match, the usual outcome is that the message is delivered anyway — unencrypted, silently, with no error raised at either end. Every invoice, contract and reply sent to your domain is subject to that negotiation, and by default nobody tells you how it went.
SMTP begins in the clear and offers to upgrade. A receiving server that does not support the upgrade, or an intermediary that removes the offer, simply gets a plain-text delivery instead. Nothing in the protocol treats that as a failure worth mentioning.
Because the negotiation happens before any encryption exists, it can be tampered with by anyone on the path. The sending server cannot distinguish an attacker removing the option from a recipient that genuinely lacks it — so it does the helpful thing and sends anyway.
Your mail servers only see the connections that reach them. Whether a sender's connection was downgraded on the way, whether it could validate your certificate, and how often either failed are facts held by the sending side. Without a reporting mechanism they stay there.
MTA-STS publishes a policy saying mail to your domain must be delivered over a validated encrypted connection. TLS-RPT asks the servers sending it to report how that went. Report URI turns the reports into something you can act on.
Sending servers report back on the sessions they opened to your mail servers: how many were successfully secured, how many failed, and why. A certificate that does not match the expected host, an expired chain, a connection that never upgraded — each is reported with a count, so an intermittent problem is visible as a proportion rather than as an anecdote.
Learn more about SMTP TLS Reporting →MTA-STS has a testing mode that behaves exactly like enforcement for reporting purposes but delivers the mail regardless. You can publish the policy you eventually want, see which of your mail servers would have caused senders a problem, and fix those before anything is ever held back.
Switch the policy to enforce and senders will not deliver to your domain over a connection that fails to establish properly, or to a mail server your policy does not list. Reports keep arriving either way, so enforcement does not cost you the visibility that got you there.
Two DNS records. No code. Reports arrive from the servers sending you mail.
30-day free trial · No credit card · Two DNS records · No code
Reports name the specific way a session failed and the mail server it failed against, which is usually enough to tell what needs fixing.
| Reported result | What it means |
|---|---|
| Successful session count | Mail delivered over a properly established encrypted connection |
| starttls-not-supported | The sender never saw your mail server offer to upgrade the connection |
| certificate-host-mismatch | The certificate your mail server presented did not match its name |
| certificate-expired | A valid chain, but past its expiry date |
| validation-failure | The certificate could not be validated against a trusted chain |
| Policy mode | Whether the failure was observed only, or actually held the message back |
A failure that only one sender reports is worth a closer look — either that sender's view of your mail server differs, or they reached a different one of your MX hosts than everyone else did.
MTA-STS is a policy you publish and TLS-RPT is a request for feedback. Neither puts anything in the path of your mail: your mail servers keep receiving exactly as they do today, and the reports come from the servers sending to you. What MTA-STS is to SMTP, HSTS is to HTTP.
Start in testing mode and no message is ever held back. Publish the policy file, then the two records that activate it and request reports.
version: STSv1
mode: testing
mx: in1-smtp.example.com
max_age: 604800
_mta-sts TXT "v=STSv1; id=1565808194"
_smtp._tls TXT "v=TLSRPTv1;
rua=mailto:yoursubdomain-d@tlsrpt.report-uri.com"
Your unique reporting address is on your Setup page once you have an account. Change mode to enforce when the reports show senders reaching every one of your mail servers cleanly.
MTA-STS and TLS-RPT are about the connection: whether the pipe carrying a message to you was encrypted and validated. DMARC, SPF and DKIM are about the claim: whether a message that says it is from you really was. They protect different mail — MTA-STS covers what you receive, DMARC covers what is sent in your name — so neither substitutes for the other.
If you are starting from nothing, DMARC generally comes first, because impersonation is the more commonly exploited weakness.
SMTP TLS Reporting covers the connection between mail servers. It does not authenticate the sender, it does not inspect content, and it has no bearing on mail you send — it is the transport encryption layer for mail arriving at your domain, and it works alongside the rest.
| SMTP TLS Reporting does | Pairs with |
|---|---|
| Requires encrypted, validated delivery | DMARC for sender authentication — whether the message was really from you |
| Reports how often encryption succeeded | Email Deliverability for reaching the inbox reliably |
| Names the specific transport failure | Certificate Transparency for certificates issued in your name |
| Tests before it enforces | Fraudulent Emails for the impersonation case in full |
Together, these cover the ways your organisation's identity can be claimed by somebody else — in mail, in transport, and in certificates.