Mail Server Rabbit Hole
I started tinkering with my mail server configuration, and while looking at some of the "can I encourage TLS?" bits I found MTA-STS and learned that there's a whole DNS-based authentication thing I never knew about.
The two intertwined bits here are ensuring only allowed servers handle your e-mail, and that they do it in a way that others can't see.
There have been DNS-based things in the past, and I've added them all. DKIM, SPF, DNSSEC, and DMARC are all things I've had in place for a while. I've jumped through a couple hoops to get GMail to "trust" my server when forwarding messages for domains I host (but for users who don't have their e-mail hosted on my server).
DNSSEC is more about making sure that names in my domains' e-mails are coming from trusted servers. SPF is based on DNS records used to help make sure that mail sent from my domains are coming from my servers. DKIM is another mechanism to leverage DNS records to also ensure that messages are coming from my servers. DMARC is used to give other email servers a way to report back when something doesn't look right.
A new (to me) idea of MTA-STS seems to be a bit of this, and a way to try to encourage mail servers to use encrypted channels. I've already got my server configured to support and encourage that via its HELO response, by telling connecting servers (and clients) to leverage TLS with a STARTTLS keyword. I'm just trying to figure that out now, but it looks like it should be straightforward to configure, if not figure out how to implement.
DANE is another identification attempt based in DNS that ties the certificate used in the encryption to a hash shared in DNS, to try to help ensure that the certificate used is the one intended.
I've tinkered a little to get some of these things configured, but am only investing enough time right now to keep warnings out of my logs. I'll return and finish locking this down. E-mail security should help reduce the amount of junk trying to get in and through my servers.