Where does the original post backs that up?
The original post here shows that SPF and DKIM are not being used to reject email, and that this is the root of the problem:
Inbound testresults -- DMARC, SPF and DKIM test are failing
Which makes sense, if you're trying to avoid receiving spoofed emails and you want to receive better results on a check like emailspooftest.com, you're going to want to increase the amount of email you reject based on SPF and DKIM failure. The tests make that clear:
Testresults of emailspoof:
SPF is not enforced.
Fix: Set email systems to reject email from servers that fail SPF checks.
DNS Settings for badSPF.com
This email should have been rejected by strict DKIM enforcement.
Fix: On inbound email systems set DMARC alignment for DKIM restrictions to deny email without a DKIM signature for domains that require DKIM via DMARC.
Now of course to get more specific into how the DMARC record suggests handling of DKIM you're going to want to move a bit further into things, but the number of emails that pass SPF and lack DKIM headers while the domain declares that anything lacking DKIM should be rejected isn't significant even for my exceptionally busy servers, so I doubt the average user is going to see a difference from focusing too heavily on that. If it passes SPF and has DKIM headers, then it still has to pass the DKIM test. So for DMARC to really matter there where ESF's SPF/DKIM checks wouldn't be sufficient, to be clear, would only be when SPF passes and there are no DKIM headers. Now my mail servers are busier than an oversold HostGator server and I can tell you that edge case isn't going to be one that makes any noteworthy difference. Certainly, it won't be something that pays you back for the time spent worrying about it.
So what you really want to do, to make a blanket action that impacts this heavily, is to make sure that both EASY_SPF_FAIL and EASY_DKIM_FAIL, independently, reach a score equal to EASY_HIGH_SCORE_DROP. So set both to 100 (as EASY_HIGH_SCORE_DROP is 100 by default), trust me you're not going to be seeing any spoofed email in the real world unless something isn't working as intended or the envelope sender wasn't actually what you thought it was (it doesn't have to match the From header, for example).
Personally, I set EASY_SPF_FAIL to 100 and EASY_DKIM_FAIL to 50, with EASY_HIGH_SCORE_DROP set to 150. This is because of what I was talking about with average users. Now you might have 5,000 or 10,000 customers and never see a ticket about this, you only need 5-10 users to drive you insane over it and start harassing you because they don't even know that they have SPF/DKIM defined by their DNS host and they just setup Random Support Ticket SaaS Notification App #587 to send email to themselves from their domain and it's driving them crazy. If you have a lot of small to medium SMBs that are slightly more tech focused with an international customer base, you start to see these types pop up more often than local coffee shops, restaurants, things like that. So like your SEO outfits, your web designers, your small time "app developer as a service" bunch, these are where that complaint pops up more if you enforce SPF/DKIM too strictly. You can argue that they're unreasonable for not wanting it enforced and you wouldn't be crazy, but it's also not crazy to not want to have to explain this to people every day because time = money and reducing support overhead can be more valuable than a slight increase in spoofed email, depending on the situation.
All that said, I'm pretty sure ESF can do something with DMARC if you really do want to go there, but I can't find any official documentation on it. You'll notice in variables.conf this bad boy right here:
.include_if_exists /etc/exim.easy_spam_fighter/variables.dmarc.conf
Now if exim could handle DMARC before Rspamd has to step in then we're done here right, that's the highest level solution in the stack. But the only documentation I can find on that file is this tutorial from 2018:
Hi everyone, in last few days I have been playing around with DMARC because I wanted to be able to check it, and report it as many providers are already doing, so I started to work on it using OpenDMARC. Here it is a small How-To that will help you to make this integration, depending on the...
forum.directadmin.com
Now that tutorial may well function perfectly and may well be the perfect solution if you really want to hit that edge case where SPF passes, DKIM headers aren't in the email, and DMARC says to reject it without DKIM. I still think that's heavy handed, but to each their own. Of course Rspamd can handle DMARC stuff as well. Defaults should usually be lenient with room for admins to increase things, that's just a good practice when you don't want to scale up support too hard. Especially for DA themselves, if not the hosts. Because if the defaults are too heavy handed, DA devs are going to get more tickets than they do about users receiving too much spam. It's just natural that people run to the devs faster for "I'm not receiving important emails" than they do for "I'd like to receive less of these other emails." One feels like an emergency, the other feels like a feature request.
Again, sorry if I offended you, that was certainly not my intention, because I really respected you before and I still do.
You know I love you Richard.