DMARC is DKIM or SPF so requiring DMARC part of the way to what you are suggesting. There is still a replay possibility with DKIM even if limited to replaying the exact same message (unless providers or email clients track already seen messages until DKIM expiration, which could happen but I don't think is happening at this point). I'm not an expert just someone trying to find a security focused email provider with minimally reasonable privacy policies that doesn't randomly drop email (which unfortunately doesn't seem to exist :( ) so I'm not sure why things are the way they are. Why SPF exists might just be due to being earlier and there not being any strong reason to stop using it.
Even Google and Microsoft aren't able to simply require whatever they want without a long transition period. I'm fairly sure Microsoft would like to make email entirely proprietary (and some of the issues almost only apply to them so they aren't likely to be the ones to improve email security). As best I can tell the people with the most direct financial interest in email are the marketers, which isn't a great situation for real improvement (BIMI seems primarily designed to replace the lost income from browsers dropping EV certificates while having similar issues). And security is a hard sell for anything it seems. So all in all I think we are lucky that Google has been doing as much as they have been. A number of old timers already complain about how it isn't really email any more. If Google did want to eventually require DKIM the path to get there would likely still look like what they have been doing.
There has also been recent activity just this year to improve the S/MIME situation (best practices document) and in a lot of ways requiring email to be signed by the sender rather than the sender's provider would be more helpful than requiring DKIM over SPF (although it isn't ideal to tie email to the CA system). Possibly we will see a push in that direction at some point.
> There is still a replay possibility with DKIM even if limited to replaying the exact same message (unless providers or email clients track already seen messages until DKIM expiration, which could happen but I don't think is happening at this point).
IIRC Gmail deduplicates based on Message-ID. But even if you replay an identical message... the date would still land it next to the original. So worst case you have two copies of the same thing next to each other. Which can (and already does!) happen occasionally when a server resends a message for whatever reason. It's hardly an issue.
Thanks! And good that Google at least likely deals with it ok. Just as a general thing it is a good idea to be very careful about replay possibilities and I think you are a bit too casually dismissive. Not every provider stores email forever (although storing just the DKIM signature could be done without too much trouble) and there are circumstances where receiving the same message as previously to a cleared inbox might not be an obvious duplicate if you don't happen to look at the date (which is not something I usually do when looking at email). Of course, this is already a potential issue today.
It is if the only thing preventing seeing a resent message as new is the recipient looking at the date or message id. Certainly it is arguable that the client and/or provider tracking seen signatures is a reasonable way to prevent it, but this isn't universally the case at this point and SPF if required (which it never is now unless DKIM isn't used at all) would at least prevent most third parties from doing this (at least without IP spoofing which would be disruptive to do bidirectionally). Not that this is necessarily a sufficient reason to justify using SPF over DKIM only just that it is a consideration. I don't know SMTP enough to know if someone between two servers who can block an encrypted connection at just the right point could cause the sending server to resend a delivered message but I would guess that might be possible. MTA-STS seems infrequently used at this point so currently someone between two servers could likely prevent the use of encryption.
Even Google and Microsoft aren't able to simply require whatever they want without a long transition period. I'm fairly sure Microsoft would like to make email entirely proprietary (and some of the issues almost only apply to them so they aren't likely to be the ones to improve email security). As best I can tell the people with the most direct financial interest in email are the marketers, which isn't a great situation for real improvement (BIMI seems primarily designed to replace the lost income from browsers dropping EV certificates while having similar issues). And security is a hard sell for anything it seems. So all in all I think we are lucky that Google has been doing as much as they have been. A number of old timers already complain about how it isn't really email any more. If Google did want to eventually require DKIM the path to get there would likely still look like what they have been doing.
There has also been recent activity just this year to improve the S/MIME situation (best practices document) and in a lot of ways requiring email to be signed by the sender rather than the sender's provider would be more helpful than requiring DKIM over SPF (although it isn't ideal to tie email to the CA system). Possibly we will see a push in that direction at some point.