One of the great mysteries about DMARC is why anyone cares about the sender's DMARC policy. You should ALWAYS care whether a message is a malicious impersonation or not. You should NEVER let your network security be influenced by the other domain's fear of false positives. Your job is to block bad stuff and correct false positives when they occur. So teste everything for DMARC so that you have data, Then do your job to disposition the exceptions.
The dangerous consequences of obeying the sender's advice:
- About 95% of all domains have a DMARC policy of NONE or no policy at all. If you follow that policy guidance, you will accept somewhere around 95% of all malicious impersonation. Don't do it.
- You will also reject about 5% of your incoming mailing list messages, even when they are harmless and desired by your users. Don't do that either.
My experience is that attackers understand DMARC perfectly, and consequently 100% of malicious impersonation uses a domain with p=none or no policy.
Yale.Edu is their favorite target. For most people, DMARC has not removed the threat volume, it has only modified the attackers choice of what to impersonate. Maybe people are less likely to fall for an impersonation of it is not a bank, but your job is to prevent the malicious impersonation from landing in the user's mailbox at all. It is the one part of email filtering that can be done reliably.
- You SHOULD apply the DMARC test to every message, using relaxed alignment. Messages that fail DMARC and fail your local policy rules should go to Quarantine. Nothing should be rejected based on DMARC results alone.
- You SHOULD have a way of authenticating a message by local policy when it fails authentication but is legitimate and acceptable. This result will happen. The details of this are a longer spiel, but I have posted them previously.
- You should NEVER whitelist a domain without some form of verification for that domain. If you do, you are also whitelisting an attacker that chooses to impersonate your whitelisted domain. Since any domain may need to be whitelisted, you need a way to provide alternate authentication for any message that does not authenticate automatically.
These are strategies that flow directly from your filtering needs. IETF does not try to define the part of the solution that involves local policy, so the effect of their specification is to protect brand image while harming recipients. Even the brand owner is a recipient, so the harm is universal.
Based on a lot of experience, it has been sufficient to require SPF PASS or DMARC PASS based on a signature. The messages that produce SPF Pass with unaligned From addresses are typically from email service providers or mailing list. Why is this sufficient? If an attacker is using an environment that allows him to impersonate the From address, he can probably impersonate the Mail From address as well, and will. If he is on an environment that does not allow impersonation of Mail From, he probably cannot impersonate the From address either. There are exceptions, but creating an exception for every email service provider has not proven to be a priority.
Unfortunately, you cannot create this type of solution with SmarterMail, you have to use something that can be customized. I use Declude. For new implementations, use Declude Reboot or rSpamD or PostFix.