The standards are designed for this result:
- SPF validates the invisible SMTP "MAIL FROM" address against the server IP,
- DMARC validates the user-visible FROM header against the SMTP "MAIL FROM" address.
People who do not use DMARC can get very frustated with spammers impersonating others, especially their own domain. So they think checking the FROM header with SPF will solve the problem. However, most of the world's mail is bulk traffic sent by service providers. Most bulk traffic uses the service provider's domain for SMTP and the client domain for the message FROM. If you check SPF against the FROM address, all of that bulk traffic will fail validation.
Both SPF and DMARC will experience validation failures that are not malicious impersonations, but instead are very much wanted. Therefore, before activating either one, you need a system in place to handle false positives. This requires: (a) a message log review tool with allows flexible searching and selection, so that you can see potential problems, (b) a way to collect data without disrupting your users, and (c) an exception mechanism which allows you to configure exceptions safely.
A safe exception for SPF should mimic SPF: When an SMTP domain has a particular value, and the server has a particular identity, then the message is handled as equivalent to SPF PASS. Because you don't know all IP addresses for a sending organization, matching on IP address does not work well for SPF exceptions. The better solution is to match on the domain portion of a host name that represents the organization, when that host name is forward-confirmed to the source IP.
Similarly, a safe exception for DMARC should mimic DMARC. When the message FROM domain and SMTP MAIL FROM domains have specific values, and the SMTP MAIL FROM DOMAIN is validated as SPF PASS or equivalent, then the mesage FROM address is considered equivalent to DMARC PASS.
When a message is confirmed as a malicious or unwanted impersonation, then you want to block the identifiers that are deemed responsible for the attack. This can be one or more of the submitted identifiers, including: the message FROM user or domain, the SMTP MAIL FROM domain, the HELO domain, the Reverse DNS domain, and/or the server IP address. Malicious identifiers do not require validation, since impersonation of a malicous sender is reasonably assumed to be malicious. Consequently, each identifier block can be configured individually as a single-attibute match.
SmarterMail is not well suited to any of this. SPF weighting can be configured to implemented test-but-dont-block, but DMARC seems only to have a enable-and-block option. It does not provide a message review tool, and the logs really don't have enough data for you to create your own. It does not provide three-factor allow rules (independent identifier, validation method, and dependent identifier.) Consequently, I do not recommend enable either SPF or DMARC blocking in SmarterMail.
I have implemented all of the above using a heavily-customized implementation of Declude. My DMARC implementation is a poor-man's version which would make the purists gag, but it works for me. I do not block anything based on validation FAIL. Instead, I use FAIL to prioritize which messages are reviewed for filtering updates. Wanted messages are given a 3-attribute allow rule, and unwanted messages are given a single-attribute block rule. Either way, messages from the source will be handled deterministically thereafter.
I had a great deal of difficulty finding commercial product vendors that could either implement this model, or could explain to me why they had a better one. If anyone has a commercial product that can meet these requirements, please send a private message with the particulars.