SMTP TLS Reporting, first data
The SMTP standard is just as ubiquitous as it is ossified and hard to change. Thus all newer RFCs follow similar patterns of a) adding optional extensions and b) providing feedback loops to detect usage, problems, and abuse of these extensions.
One more recent extension tries to enforce TLS transport between mailservers. This sounds very simple (and would be very simple if one could change the SMTP standard to require TLS), but is not trivial when compatibility is necessary and all TLS policies are “opt-in”.
RFC 8461 defines SMTP MTA Strict Transport Security as a way for recipient mailservers to publish their “I want TLS” policy. This policy is really basic, it contains a list of MX hosts for a domain and three modes “none”, “testing” (i.e. report but do not enforce), and “enforce” (no mails without TLS).
The counter part is RFC 8460 which defines the reporting, i.e. how clients should report that they recognized a policy and how many messages were affected (either successfully delivered or blocked due to the policy). It defines a JSON structure for the reports and a way to specify the report recipients for a domain. The recipients can use an email address or an HTTPS URL.
Out of curiosity I requested these reports for my small mailserver, but so far there is very little interesting data.
In April 2019 Google started to send these reports, they are obviously the main drivers of the protocol. Much later, in August 2020, Microsoft followed. Currently Microsoft only sends reports as mail, they do not support the HTTPS destination. Interestingly they send out reports, but do not publish their own policy for microsoft.com (there is one for outlook.com, though).