TLS-RPT — Getting Told When Encrypted Delivery Fails
TLS-RPT publishes an address where other mail servers can send reports about their attempts to deliver to you over TLS, including the ones that failed. It is a small DNS record whose only job is to open a feedback channel, and this check confirms the record is present and correctly formed.
Why run it
Because without it you have no visibility into delivery failures that happen at the sender. If a certificate problem or an MTA-STS mismatch causes other servers to abandon delivery, that decision is made entirely on their side — nothing arrives, nothing is logged by you, and the sender may not tell their user either. TLS-RPT is the only mechanism that surfaces it. A malformed record is worse than none, because it creates the belief that you would be told.
Why automate it
This is a set-and-forget record, which is precisely why it needs checking: nobody looks at it again, and a DNS tidy-up that removes it produces no symptom at all. Its absence is only discovered during the incident it would have warned you about. A scheduled check costs essentially nothing and preserves a channel whose entire value is that it works on the day something else breaks.
What it gives you
Keeps open the one feedback loop that reports mail failures happening outside your infrastructure. It is a small record that determines whether an encrypted-delivery problem is something you learn about in reports or something you never learn about at all.