SMTP TLS Reports

Your email is encrypted in transit. Probably.

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 and TLS-RPT reports back on how often it worked — two DNS records and a policy file, with nothing routed through us.

Start Free Trial Documentation →
What's at Stake

SMTP asks politely for encryption, and accepts no for an answer.

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, password reset and internal thread you send is subject to that negotiation, and by default nobody tells you how it went.

Optional by Design

Encryption is an upgrade, not a requirement

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.

Silent Downgrade

A stripped offer looks exactly like a server that never offered

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.

No Feedback Loop

You have no idea what proportion succeeded

Your own logs record that a message left. Whether the connection that carried it was encrypted, whether the certificate validated, and how often either failed are facts held by the receiving side. Without a reporting mechanism they stay there.

What SMTP TLS Reporting Does

Make encryption mandatory, and find out whether it holds

MTA-STS publishes a policy saying your mail must be delivered over a validated encrypted connection. TLS-RPT asks receiving servers to report how that went. Report URI turns the reports into something you can act on.

Delivery Visibility

How often encryption succeeded, and where it didn't

Receiving servers report back on the sessions that carried your mail: 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 →
Testing Mode

Publish the strict policy without risking a single message

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, watch which of your recipients' servers would have had a problem with it, and fix those before anything is ever held back.

Learn more about DMARC Monitoring →
Enforcement

Then make encryption a requirement

Switch the policy to enforce and a message will not be delivered over a connection that fails to establish properly or to a host that does not match your published MX records. Reports keep arriving either way, so enforcement does not cost you the visibility that got you there.

Learn more about email deliverability →
Get Started

Find out how much of your mail is really encrypted. Then require it.

Two DNS records. No code. Reports arrive from the servers receiving your mail.

Start Free Trial Talk to our team →

30-day free trial  ·  Two DNS records  ·  No code  ·  Cancel anytime

Detection

What a TLS report tells you

Reports name the specific way a session failed, which is usually enough to tell whether the fix belongs to you, to the recipient, or to nobody at all.

Reported result What it means
Successful session count Mail delivered over a properly established encrypted connection
starttls-not-supported The receiving server never offered to upgrade the connection
certificate-host-mismatch The certificate presented did not match the expected mail host
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

Failures against a recipient you do not control are still worth knowing about — they tell you which of your correspondents cannot currently receive your mail securely.

Architecture

A policy file and two DNS records. No code.

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 servers keep sending exactly as they do today, and the reports come from the receiving side. 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.

Policy file — served at /.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: in1-smtp.example.com
max_age: 86400
DNS — activate the policy and request reports
_mta-sts   TXT  "v=STSv1; id=1565808194"
_smtp._tls TXT  "v=TLSRPTv1;
  rua=mailto:your-subdomain-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 your recipients handling the policy cleanly.

No code added anywhere

Your mail is never routed through us

Testing mode reports without holding mail back

We never receive the content of your messages

Reports come from the servers actually receiving your mail

Email Security

Transport security is a separate question from identity

MTA-STS and TLS-RPT are about the connection: whether the pipe carrying your message was encrypted and validated. DMARC, SPF and DKIM are about the claim: whether the message was really from you. Both matter, they fail in different ways, and neither substitutes for the other — an encrypted delivery of a forged message is still a forged message.

If you are starting from nothing, DMARC generally comes first, because impersonation is the more commonly exploited weakness.

DMARC Monitoring →
Scope

One layer in the stack. Here's how it fits.

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 receive — it is the transport encryption layer, 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.