TLS-RPT (RFC 8460) is a reporting standard: providers like Google and Microsoft send your domain a daily summary of every TLS negotiation with your mail servers, including failures like expired certificates or missing STARTTLS. This tool collects those reports and turns them into a plain-English weekly digest.

Do I need MTA-STS to use TLS-RPT?

No. Reports arrive without MTA-STS, showing successful and failed TLS sessions. With an MTA-STS policy in place the reports become far more valuable, because senders also report certificate and policy validation failures. The tool checks your MTA-STS state and can generate the policy for you.

Can MTA-STS enforce mode break my email?

Enforce mode tells senders to refuse delivery to your domain when TLS validation fails, so a wrong certificate or a stale policy can cost you inbound mail. The safe path is to publish the policy in testing mode, watch your weekly TLS reports until they are clean, and only then move to enforce.

Free forever

Free Weekly TLS-RPT Monitoring

Know when senders cannot reach your mail server securely. Add one DNS record and get a plain-English report every Monday - how many connections succeeded, what failed, and exactly what to fix before mail starts bouncing.

Get your reporting address

Enter your email and the domain you want to watch. We check your domain's readiness live, and generate a unique reporting address for your DNS.

No account. Nothing to log into. No password. Just a DNS record. No spam. We never email you until your DNS is verified.

Why TLS-RPT matters

Almost all legitimate mail travels between servers over encrypted TLS connections. When that encryption fails - an expired certificate, a misconfigured mail host, a downgrade attack - senders either fall back to plain text or, if you enforce MTA-STS, stop delivering to you entirely. Either way, you usually find out from angry users, not from your systems.

TLS-RPT (RFC 8460) fixes the visibility problem: providers like Google and Microsoft send your domain a daily summary of every TLS negotiation with your mail servers - successes, failures, and why they failed. This tool collects those reports and turns them into a plain-English weekly summary.

Where our DMARC Monitor watches mail sent as your domain, TLS-RPT watches mail delivered to your domain. They are complementary - most domains should run both.

What is MTA-STS, and do you need it?

MTA-STS (RFC 8461) is a policy you publish saying "only deliver mail to me over valid TLS, to these mail servers". Reports still arrive without it, but with a policy in place they become far more valuable: senders start telling you about certificate problems and policy mistakes before they cost you mail.

Enter your domain above - the readiness check tells you instantly whether you already have MTA-STS and whether the policy is healthy.
If you do not, we generate both the DNS record and the policy file for you, ready to paste.
Start in testing mode: nothing can break, and your weekly reports show what enforce mode would have blocked.
After a clean week or two, switch to enforce. Your domain is then protected against TLS downgrade attacks - and this monitor tells you if anything ever starts failing.

Careful with enforce mode: it instructs Gmail, Outlook and others to refuse delivery to your domain if your certificates or policy are wrong. That is exactly why you monitor in testing mode first - this tool shows you a clean week before you commit.

Service limits

A few limits keep the service fast, reliable, and free:

Report attachments up to 2 MB compressed, and up to 3 per email.
Up to 100 policies per report and 5,000 failure details per policy; larger reports are truncated.
Up to 100 reports per day per monitored domain (typical is one per reporter per day).
Report data is retained for 14 days; your weekly digest summarizes that window.
We process aggregate TLS reports (RFC 8460) delivered by email.