phishing simulation emails quarantined by anti-phishing policy instead of delivered to users

TL;DR

Deliver simulations through the channel Microsoft built for them, not through filter exceptions for real phish: configure the simulation in Attack Simulation Training or your training platform integration, register the simulation domains and senders there, and use the advanced delivery policy for phishing simulation that Defender provides. That path delivers the training mail and records user actions, while a blanket anti-phishing exception would also wave through real attacks that copy the same shape.

phishing simulation emails quarantined by anti-phishing policy instead of delivered to users

Use this when

• Authorised simulation messages are quarantined, junked, or stripped before users see them.
• User clicks and reports on the simulation are not being recorded because mail never arrived.
• The simulation is part of an approved security awareness programme with documented scope.

Not for this skill when

• Real phishing mail is being quarantined. That is the filter succeeding; do not create a delivery path for it.
• A third party test with no approval or scope is blocked. Leave the block in place and route the request through the programme owner.

Steps

1. Confirm the campaign approval, its sender domains, and its target group in the programme records before touching any policy. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the campaign scope and its domains are documented and approved
2. Check where the test messages died: quarantine reason, policy name, and whether links or attachments were stripped in transit. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the blocking policy and action are named from the quarantine record
3. Configure the phishing simulation section of the advanced delivery policy with exactly the simulation domains, sender addresses, and source IPs from the programme. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the advanced delivery entry lists only the approved simulation identifiers
4. Run a pilot send to a small test group inside the target scope and confirm delivery, rendering, and click and report tracking. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: pilot users receive the message and their test actions appear in the campaign report
5. Launch the full campaign, then review the advanced delivery entry at campaign end and remove identifiers that will not be reused. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the post campaign review shows the entry removed or confirmed for a scheduled next run

Why it happens

Defender cannot tell an authorised simulation from an attack by intent; it can only use configuration. The advanced delivery policy is the explicit signal that separates the two, scoped to named simulation infrastructure. Admins who instead weaken impersonation or spam rules for a campaign open a real hole for the exact techniques the training is meant to teach users to spot, and the hole usually outlives the campaign by months.

Variants and edge cases

phishing simulation emails quarantined anti-phishing policy not delivered

The exact delivery failure for training teams.

attack simulation training mail quarantined advanced delivery policy setup

The product feature variant naming the correct configuration.

simulation domains blocked defender configure phishing simulation delivery

The configuration search training platforms document for their customers.

Compatibility: Microsoft Defender for Office 365 Attack Simulation Training and advanced delivery policies, major awareness platform integrations.

Edge cases to check:

• Simulations sent from lookalike domains you register for training still need SPF and DKIM for those domains, or other receivers will block them.
• Tell the service desk a campaign window is running so real user reports during it are triaged with context, without telling users the exact send time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0czZ7ATM0CI7-ToLMVbebA