"Correct" use of SPF/DKIM/DMARC is not a simple matter.
These tools are voluntary: they are useful if the domain owner has published policies and if those policies are published correctly. When dealing with crowd-sourced data, you have to assume that there will be errors, so your security design has to have a plan to detect those problems and correct them with local policy entries.
For instance:
example.com does not produce SPF Pass because its policy is non-existent, malformed, or incomplete. You determine that their messages are acceptable and that they legitimately come from Outlook.com. You need a local policy rule like this:
"Treat messages as equivalent to SPF Pass when the host name is *.Outlook.com, the host name is verified by fcDNS, and the SMTP MailFrom domain is
example.com or *.example.com"
With this capability, you can create another rule that sends any SPF result other than Pass to Quarantine. When you review quarantine, acceptable senders get an allow rule like the one above, unacceptable senders get a block rule, no sender needs to be quarantined more than once.
This type of local policy requires a product that can implement a multiple-attribute rule based on host name, fcDNS result, and Mail From domain. I found very few products that could do a multiple-attribute rule of any kind, and the exceptions do not support rules based on fcDNS results.
Instead, you will find products that do this:
- Any SPF result other than FAIL is acceptable. The product can only block malicious impersonation if the domain owner wants to block malicious impersonation.
- If a wanted message produces SPF Fail, the solution is to whitelist that domain. Whitelisting means that the domain is exempt from authentication checks and exempt from content checks, so any impersonation of the whitelisted domain will also be expedited to the recipient.
The same applies to the standard implementation of DMARC:
What you need is a tool that can apply the DMARC test to every message, send results other than Pass to Quarantine, and then create allow rules in local policy for messages that cannot produce Pass. The allow rules are of the form: "Treat message as equivalent to DMARC Pass if the SMTP MailFrom domain is
example1.com and the Mail From domain is authenticated by SPF or local policy, and the message From domain is example2.com"
Instead, you will find the standard implementation looks like this:
- Any DMARC FAIL with p=Reject is rejected. The only workaround is to whitelist the domain so that malicious impersonations will also be exempted from authentication checks and content checks. Rejected messages are usually not retained, so you will have trouble knowing whether a message was blocked incorrectly. The most common cause of false positives will be messages from mailing lists.
- Any DMARC FAIL with p=Quarantine is quarantined. The only way to prevent future messages from being quarantined is to whitelist the domain, with the same problem as above.
- Any DMARC Fail with p=none is exempt from authentication. The product can only block malicious messages if the domain owner wants to block malicious messages.
- Any domain without a DMARC policy is exempt from authentication. The product can only block malicious messages if the domain owner wants to block malicious messages.
- Because DMARC makes mailing list messages look suspicious, relatively few domains are willing to publish a DMARC policy other than p=none. Since a result of p=none is ignored, and since attackers know the DMARC policy of the domain they impersonate, they usually impersonate a domain with p=none or no policy. Collectively, the test is nearly useless as a security mechanism.
- DMARC Pass can only be detected if the domain owner publishes a DMARC policy. Most messages will pass the DMARC test based on SPF Pass with alignment or DKIM pass with alignment, but this result is never detected because the reported result is No Policy.
Once you start enforcing authentication, you learn a lot while doing quarantine reviews. My most recent learning is that I need sometimes, the Reply-To address indicates the true author, so Reply-To reputation needs to be checked any time that its domain is different from both the SMTP Mail From and message From domains.
I have also learned that if the message passes SPF, I don't need to worry very much about alignment with the From address. This has been a convenient surprise as I have sorted out what my own definition of what "100% acceptable authentication" means to me.
This approach also requires a good message review tool that includes all messages, whether blocked, quarantined, or allowed.