> so a restrictive DMARC policy (p=reject; adkim=s)
This isn't how DMARC works. Valid SPF OR DKIM will validate a message. So unless you drop your SPF policy DMARC will still pass. And unfortunately if you don't have a good SPF policy many mail servers will send your messages to the spam folder, so there isn't a good way to have only DKIM set up.
There are some discussions about requiring DKIM independent of SPF, but nothing published (nevermind adopted) yet.
Oops! Thank you for this, for some reason I always thought the policy is "AND", not "OR". My mistake.
Well, guess I have something to do for Christmas... (I run a non-Postfix MTA, gotta try to test it and see if I can implement a patch if it's vulnerable.)
I currently don't have DMARC setup on my mail server (which runs for a couple of domains plus subdomains for me and a couple of friends/family), but have SPF records set appropriately and DKIM configured. We've not noticed any deliverability issues.
Though I'd be interested to work out (or, be told!) how this might affect this vulnerability. I always assumed that most mail servers both check against SPF records and verify DKIM signatures if both are present, rather than it being a this-or-that thing, so DKIM offering some mitigation is not undone by the presence of SPF.
I doubt it. Some servers may reject based on SPF when there is no DMARC policy but there is no way to know that DKIM is enabled unless you see a signature. So a spoofer could just not include a signature and the receiver would have no way of knowing if the message should be signed.
This isn't how DMARC works. Valid SPF OR DKIM will validate a message. So unless you drop your SPF policy DMARC will still pass. And unfortunately if you don't have a good SPF policy many mail servers will send your messages to the spam folder, so there isn't a good way to have only DKIM set up.
There are some discussions about requiring DKIM independent of SPF, but nothing published (nevermind adopted) yet.