Hey everyone,
I'm setting up a direct send prevention rule that's currently running in audit mode just to keep tabs on things. However, I'm running into an issue where emails that should be excluded based on their sender IP are still being flagged by the rule. Here's what I have so far:
The rule triggers when emails are sent to members of my organization and received from outside. I specifically have rules to handle exceptions based on sender IPs, but some emails from a smart filtering system with a specific IP are still getting caught.
For context, here's the format of my rule:
- Apply this rule if the message is sent to 'Inside the organization' and received from 'Outside the organization'.
- Send an incident report to [email protected] if it matches any of the specified sender IPs or certain email addresses like '[email protected]'.
Even after excluding these IPs, I'm seeing problematic emails that have headers tracing back to the excluded IP. They seem to be calendar invites, and it's been a hassle trying to figure out why they're being flagged.
Has anyone encountered this before and found a solution?
3 Answers
I've noticed that all IPv6 "skype" notifications are getting flagged constantly due to anti-phishing policies, and unfortunately, there's no bypass option for them right now. I'd suggest submitting those emails as false positives and reaching out to Microsoft. They really need to handle this better.
Try adding a new exception to your rule, saying "Except if... The message headers... include these words" and specify the header name as "X-MS-Exchange-Generated-Message-Source" with the value set to "Mailbox Rules Agent". This way, those auto-generated emails won’t trigger your report anymore. Calendar invites can be tricky since they're often processed by mailbox rules, so checking for that specific header is usually more reliable than solely relying on IP.
It looks like the emails might be coming in over IPv6 while your IP-based ACLs are set up for IPv4. That could definitely be causing issues!
I had a similar problem! There’s a way to force the system to drop IPv6 and only use IPv4, which might help with your situation.
When I did a message trace, I noticed the sender IP was different from what displayed in the soft fail. It might still be an IPv4 issue you should check out!
I get your point, but I’d be wary. Some phishing attempts use calendar invites to appear legit. I had an exclusion for those types before, and it backfired on me.