DKIM: Show Your Privates
Trying to retrofit &quot;we guarantee this really came from this person on this date&quot; features onto server-to-server SMTP transport is a losing game in my opinion.<p>I&#x27;ve been running smtpd on the Internet since 1996, for ISP purposes.<p>DKIM is all fine and good, and a beneficial thing as part of a multi pronged anti spam approach, and for the general health of the Internet.<p>But it&#x27;s not meant to be used with rotating a key every day. My worry is that some hacked up setup like this will provide people with a sense of false confidence that shouldn&#x27;t exist.<p>Email is <i>still</i> like a postcard, not a sealed envelope.<p>I would consider it a very poor idea to have a set of automatic scripts messing around with the MX records or DKIM records on the domain zonefiles on my set of authoritative-only nameservers. Those things aren&#x27;t meant to change often.<p>All of the considerations involved in setting up and running your own smtpd in a highly reliable manner in the year 2020 (not just pointing your MX records to office365 or gsuite and calling it a day)...<p>Yes you should run DKIM. You should pay attention to stuff like DMARC, SPF, your IP space reputation, proper configuration of your smtpd, your own smtpd&#x27;s configuration to discard incoming stuff based on RBLs and spamassassin, as I have my postfix system set up to do. But ultimately server to server SMTP in the year 2020 is a hack job piled on top of a hack job.<p>There is no need to start doing things that require you to set very low TTLs on your domain zonefiles and then blindly trust that every caching DNS resolver out there on the internet will respect that (breaking news: they won&#x27;t! it will break mail delivery in new and amazing ways!).<p>If you want a proper cryptographically secured end to end communication method, it&#x27;s not anything that speaks SMTP. Go use Signal to chat or something.