Whitelisting simulated phishing campaigns in Defender

K 0 Reputation points
2026-06-23T18:58:05.3433333+00:00

Hi,

I whitelisted my simulated phishing campaign platform in advanced delivery in Defender and created a Safe Link Bypass Rule in Exchange Admin Center. Even so my simulated phishing emails still get detonated by Defender and my platform logs a false positive click for the users. Defender also generates "Email reported by user as malware or phish" alerts even though it parses out the sender's domain exactly as it is whitelisted in Advanced Delivery.

What am I missing? Is there any additional whitelisting I should consider?

Thanks,

K

Microsoft 365 and Office | Microsoft 365 Defender | Other | Other
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest

  1. AI answer

    2026-06-23T18:58:45.27+00:00

    Advanced delivery plus a Safe Links bypass rule is the right direction, but there are a few Defender behaviors and configuration details that explain what is being seen.

    Key points from the documented behavior:

    1. Advanced delivery does not fully disable Safe Links detonation in all cases
      For non-Microsoft phishing simulations, advanced delivery ensures:
      • Filters take no action on the messages.
      • ZAP for spam/phish takes no action.
      • Safe Links “doesn't block or detonate the specified URLs in these messages at time of click. URLs are still wrapped, but they aren't blocked.”
      However, there are important version and policy caveats:
      • If using the Built-in protection preset or custom Safe Links policies with Do not rewrite URLs, do checks via SafeLinks API only enabled, time-of-click protection does not treat phishing simulation links as threats in:
        • Outlook on the web
        • Outlook for iOS and Android
        • Outlook for Windows v16.0.15317.10000 or later
        • Outlook for Mac v16.74 (23061100) or later
      • If using older Outlook clients, the guidance is to disable the “Do not rewrite URLs, do checks via SafeLinks API only” setting in custom Safe Links policies so that simulations are handled correctly.
      Action:
      • Verify which Outlook clients are in use.
      • Check Safe Links policies for the Do not rewrite URLs, do checks via SafeLinks API only setting and align it with the client versions as described above.
    2. Do not add simulation URLs to ‘Do not rewrite’ in Safe Links
      The documentation explicitly warns:
      • Adding phishing simulation URLs to Do not rewrite the following URLs in email can cause unwanted alerts for URL clicks.
      • Phishing simulation URLs are automatically allowed both during mail flow and at time of click.
      If the Safe Link bypass rule is implemented by adding the simulation URLs to the “do not rewrite” list, this can contribute to the false-positive click behavior and alerts. Action:
      • Remove phishing simulation URLs from the Do not rewrite the following URLs in email section in Safe Links policies.
      • Rely on advanced delivery for the simulation scenario instead of manual URL bypass entries.
    3. Advanced delivery changes how user reports and alerts behave
      For non-Microsoft phishing simulations configured in advanced delivery:
      • Admin submission generates an automatic response indicating the message is part of a phishing simulation and not a real threat; alerts and AIR are not triggered.
      • When a user reports a phishing simulation message using the built-in Report button in Outlook:
        • No alert, investigation, or incident is generated.
        • Links/files are not detonated.
        • The message appears on the User reported tab of the Submissions page.
      If alerts like “Email reported by user as malware or phish” are still being generated, it usually means:
      • The simulation messages are not being correctly matched by the advanced delivery phishing simulation configuration (for example, mismatch in sending IP, domain, or header values), or
      • The messages are not being treated as “Phishing simulation” system overrides.
      Action:
      • Re-check the advanced delivery Phishing simulation configuration in the Microsoft Defender portal (Email & collaboration → Policies & rules → Threat policies → Advanced delivery → Phishing simulation tab). Ensure the sender domain, IPs, and any header values exactly match what the simulation platform uses.
      • In Threat Explorer / Real-time detections or the Email entity page, confirm that these messages show System override source = Phishing simulation. If they do not, adjust the advanced delivery configuration until they do.
    4. Avoid using mail flow rules (SCL -1) for phishing simulations
      Documentation recommends:
      • For SecOps mailboxes or phishing simulations, use the advanced delivery policy instead of mail flow rules.
      • SCL -1 rules are risky and do not bypass malware or high confidence phishing protections.
      If any mail flow rules are being used in addition to advanced delivery (for example, to bypass spam or Safe Links), they can interfere with expected behavior and cause unexpected detections or alerts. Action:
      • Review mail flow rules in the Exchange admin center for any rules related to the simulation sender/domain/IP.
      • Remove or narrow any SCL -1 or bypass rules and rely on advanced delivery for the simulation scenario.
    5. Do not disable intra-org scanning globally
      For simulations within the same organization (DIR:INT) routed through an on-premises Exchange gateway, advanced delivery for non-Microsoft simulations is not supported. The documented workarounds are:
      • Create a dedicated Receive connector that does not authenticate the simulation messages as internal; or
      • Configure the simulation platform to bypass the on-premises infrastructure and send directly to the Microsoft 365 MX record.
      • It is not recommended to set intra-organization message scanning to None in anti-spam policies, as this affects all mail.
      If the scenario involves internal-looking mail or hybrid routing, ensure one of the supported workarounds is used so that advanced delivery can correctly identify the messages as simulations.

    Summary of what to adjust:

    1. Confirm the simulation messages are correctly matched by the Phishing simulation advanced delivery configuration and show as Phishing simulation system overrides.
    2. Remove simulation URLs from Do not rewrite in Safe Links; do not rely on Safe Link bypass rules for simulations.
    3. Align the Do not rewrite URLs, do checks via SafeLinks API only setting with the Outlook client versions in use.
    4. Remove or narrow any mail flow rules used to bypass spam/Safe Links for the simulation; rely on advanced delivery instead.
    5. If using hybrid or internal simulations, ensure the documented routing/connector workarounds are in place so advanced delivery can apply.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.