P
Paul B
We're an MSP managing Huntress EDR, ITDR, and SAT/Phishing Testing across multiple M365 tenants, several of which also run Microsoft Defender's native protections or Check Point Avanan (Harmony Email & Collaboration) as the primary mail security layer. We've hit a structural conflict between Huntress SAT reporting and real-world phishing response, and we don't believe we're the only MSP or customer in this position.
The conflict:
By default, M365's native "Report" button sends reported messages to Microsoft, which uses that signal to improve detection for the tenant (similar phishing attempts get filtered going forward). That's the correct behavior for real threats.
Huntress SAT requires reports to reach Huntress instead, so simulated phishing clicks and reports register in campaign stats and trigger the "nice catch" feedback loop that reinforces training.
These two requirements point the same button at two different destinations, and neither of Huntress's documented paths resolves it:
  1. Redirecting the native Report button to Huntress
    (via mail flow rule, per Huntress's own setup guidance) means every report, real or simulated, goes to Huntress instead of Microsoft or Avanan. Real phishing reports no longer reach the actual security tooling. There is no supported mechanism for Huntress to conditionally pass real (non-simulated) reports on to the customer's security stack in a format that stack can ingest. For Avanan specifically, redirecting the native button silently overwrites Avanan's own auto-provisioned reporting mailbox, breaking Avanan's phishing ingestion with no warning.
  2. Using the Huntress Outlook add-in button alongside the native button
    requires the end user to correctly judge, before reporting, whether the email is a real phishing attempt or a Huntress simulation. Reporting through the wrong button means nothing happens for a real threat (Huntress confirms it's "not phishing" and the process ends), or nothing happens for a simulation reported to Microsoft (no training credit, no stats). This asks the least security-literate users, the exact population SAT training targets, to make the one judgment call that determines whether their report has any effect.
The same conflict applies identically to any customer running Avanan (or presumably other third-party mail security products) alongside Huntress SAT.
What we're asking:
A supported way for a single report action (native button or Huntress add-in, your call) to reliably reach both destinations correctly: the customer's actual mail security stack, unconditionally, so real threats always get security-side action, and Huntress, so simulation attribution and training stats work, without requiring the customer to build custom mail-flow forwarding per client, without silently breaking third-party ingestion (as it does with Avanan today), and without requiring the end user to pre-classify the email before reporting it.
We're not tied to a specific mechanism: API-based dual submission, a documented forwarding format per security vendor, native support for Bcc-style fan-out, whatever fits your architecture. We just need reported emails to reliably reach real security response and SAT tracking at the same time, for any customer running a third-party mail security product.