Matt,

Thanks, but I don't feel like managing a huge list of ips for a single customer, they list a bunch of /20's, /24's, et al, on the support page, it's like basically saying spf to +all.  Honestly, we can probably do everything that AppRiver can do already, so I'm going to try and have them just go direct to us.

Scratch the ARC deal as well, I just tested this out, and you guys are accepting the emails fine.  Gmail is doing a SRS rewrite and resigning with ARC.  I just did a forward from GMail to my personal and it's fine.

[2020.04.22] 13:18:29.526 [49227] Spam check args: from: eric@securedomain.com; messageID: 49227; messagePath: M:\SmarterMail\Spool\SubSpool1\191349227.eml; sender: gmail.username+caf_=local.username=domain.com@gmail.com; sendersDomain: gmail.com; sendersIp: 209.85.222.50; returnPath: gmail.username+caf_=local.username=domain.com@gmail.com 

[2020.04.22] 13:18:29.526 [49227] [209.85.222.50] Valid reverse DNS entry found: mail-ua1-f50.google.com 

[2020.04.22] 13:18:29.588 [49227] Running SPF check 

[2020.04.22] 13:18:29.588 [49227] Finished SPF check; result = Pass 

[2020.04.22] 13:18:29.588 [49227] [DKIM] Performing DKIM check... 

[2020.04.22] 13:18:29.588 [49227] [DKIM] Result: Good. 

[2020.04.22] 13:18:30.447 [49227] Spam Checks completed. 

[2020.04.22] 13:18:30.447 [49227] SpamCheck Processing Thread Completed

You are right, the exception mechanisms are too limiting.   See my soapbox at this link.   

https://portal.smartertools.com/community/a93134/discussion-the-uses-and-misuses-of-sender-authentication-spf-dkim-dmarc.aspx 

I recommend an upgraded spam filtering structure, combined with a philosophy that 100% authentication is the goal.   100% authentication uses a mixture of SPF/DKIM/DMARC and the upgraded local policy system.

There are two ways to conclude that a message is accurately identified:

Options for local policy rules to treat a message as equivalent to SPF PASS, when the normal result is Fail, SoftFail, Neutral, PermError, None, or even TempError)

Options for local policy rules to treat a message as equivalent to DMARC PASS, when the normal result is NO POLICY or PermError

The goal is to get to 100% authentication for many reasons.   Fortunately, most messages can be authenticated, so the amount of inspection is not as awful as you might expect.   You will end up with a lot of rules, so they need to be in a database where entries are unique and tables are indexed for performance.

I do not blocking on authentication failure, because the failure does not prove malice.   I do target those messages for expert review.  The review either leads to an allow rule like the ones above or a block rule.   Either way, the ambiguity is eliminated for the next message.

100% authentication has cumulative benefits:

Hello @Matt,

the setting for IP bypass can now be found under Settings -> Security -> Whitelist

But this does not bypass the DMARC check.

As I read in the online help, DMARC can only be deactivated for the entire server.

I have a domain for which the SPAM checks go through another provider. I have to deactivate DMARC for the whole server so that this works without errors.

Regards

Oliver

Another example of why the DMARC check should not do unconditional block or quarantine.   

I'm pretty sure we forcefully do DMARC internally now even when its turned off, we just wont apply the weights to the email so there should be no forced blocking. We do this because we rely on the "trust" that DMARC affords us because otherwise we can't effectively serve the trusted sender functionality as anyone can say they are anyone else bypassing all your spam checks. All that bypass does is make sure the DMARC validation occurs against the other IP's in the email chain it skips/bypasses that IP when looking through the Received: chain for an IP to do the DMARC (and its associated checks) against. 

If we can't validate with a POSITIVE result that the email is truly from a particular sender, then trusted sender functionality won't work and that is desired behavior because it keeps users safe.

PS: we support ARC now, didn't realize my og response was from 2020.

As a design principle, you should assume that exceptions will be need for any rule that depends on (a) crowd-sourced data, or (b) heuristics.    Exception design will sometimes require more effort than designing the original rule.

In the case of DMARC, your implementation should have been informed by RFC 7960, which was written because of mailing list blocks created by mindless enforcement of DMARC p=reject.

To my knowledge, SmarterTools has never documented that Trusted Senders will work when DMARC enforcement is off.   Will BIMI indicators also work?

Going one step further, I recommend computing a DMARC result on every message, using a default policy of relaxed alignment (and p=none) when no policy exists.   This will allow you to correctly tag more senders as verified.   About 85% of my incoming messages produce DMARC-equivalent Pass using this strategy.

Beyond default DMARC, the next step is to provide authentication using local policy for the 15% of messages that are legitimate and acceptable but do not authenticate.   Once have these local policy structures are defined and populated, you can start blocking any message that cannot be verified.   Having reached this goal, using customized Declude, I can assure you that it prevents a lot of spam getting through.   Curiously, none of the commercial offerings seem to consider 100% authentication to be a necessary or useful objective.  I don't understand why. 

I can only say that the message that went through my external SPAM filter was rejected by the SM server with “550 Message rejected due to senders DMARC policy”.

After deactivating DMARC on the entire SM server, it was possible to receive the message. Too bad, because this makes DMARC useless for the remaining domains!

@Matt Petty   Correction:  DMARC is not used when enforcement is off

I just checked my message list in webmail.  The Sender Verification icon is present and gray for SPF Pass by itself.   It is green for SPF Pass with Trusted Sender (GAL).    But the detail pop-up always shows DMARC not available and DKIM not available, even for messages from SmarterTools.com that have a DKIM signature, which I verified during Declude processing.  I see that  you also have a DMARC policy with p=reject.