DKIM replay attacks and what to do about them

DKIM replay attacks are one of the new big things lately, and they work like this: Take a DKIM signed email message, and re-send it to a billion other people. Maybe add another header (or change the subject, if the signature doesn't cover the subject), or maybe change nothing. Just take that message and randomly spam a million people. The mail will pass DKIM authentication checks, as long as it is sufficiently unchanged, and thus it authenticates as if it were a legitimate email message. Even if you weren't the original intended recipient. Even if it was sent only to one person but then recent to a million other people, just to annoy them. That's not a good thing -- it can damage a sender's domain reputation, because people unhappy about that unwanted mail will report it as spam, and spam reporting processing mechanisms will tie it back to the sender's domain, letting an unrelated party (the forwarder/re-distributor) off the hook for the havoc they've caused. (Mostly. IP reputation still comes into play here, but still.)

So, a lot of people smarter than me are working on solutions to this "DKIM replay attack" problem, with varying ideas -- which I won't share here as my goal isn't just to quote discussions happening on various mailing lists -- but I did want to share this really interesting 2020 article from Matthew Green, cryptographer and professor at Johns Hopkins University, were he points out that DKIM has pretty much strayed from its original intent.

He writes: "The key design goal of DKIM was to prevent spammers from forging emails while in transit," but what we ended up with is something that provides a "life-long guarantee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent." Fine if you're trying to authenticate an email found on Hunter Biden's laptop, but this has unintended consequences, and isn't what the spec was designed for. He doesn't touch on DKIM replay attacks, but those are indeed one of (perhaps the worst) unintended consequences of the long life and poor rotation policy when it comes to how most folks have implemented DKIM keys.

Would an authentication key mechanism with a built-in quick expire time solve the DKIM relay problem? If everybody just rotated their current DKIM keys (and deleted old ones from DNS) on a tight schedule, would that make it harder for bad guys to engage in a DKIM replay attacks successfully? Possibly, but I see flaws in that as as possible solution, and I see potential flaws in just about every solution I can think of (or that I've read others propose). What is the solution here, short of going back to SPF to better tie messages to a server source and more harshly message rebroadcasting (which itself harms legitimate message forwarding). I just don't know what the solution should be. Do you?

What I will say, though, in closing, is that publishing private keys so that anybody can spoof mail from a domain is a path to disaster. It obliterates any of the good value DKIM has, and I'm not a fan of throwing the baby out with the bathwater.