You launch a phishing simulation, and the report comes back clean - 100% delivered, 0% opened. Nobody opened it because Microsoft 365 quarantined every simulation email, or buried it in Junk, or stripped the link. The programme is not running; you are generating numbers. Whitelisting simulation emails in Microsoft 365 is a five-minute admin task that decides whether your phishing programme measures humans or measures your mail filter.
TL;DR
- Use the advanced delivery policy in the Microsoft Defender portal - not the Tenant Allow/Block List - for third-party phishing simulations.
- You need two things from your simulation platform: the sending domains and the sending IP addresses.
- Simulation URLs in email are automatically allowed during mail flow and at time of click - do not add them to Safe Links' do-not-rewrite list.
- Microsoft deliberately blocks bypasses for malware and high-confidence phishing, so whitelisting means delivery, not a security hole in general.
- Test with a single mailbox before the full campaign, and confirm the message lands in the Inbox.
Why this matters
Microsoft 365 is aggressive with email by design. Messages that look like phishing - which well-built simulations do, on purpose - get filtered, quarantined, rewritten or sent straight to Junk. When that happens the click rate reads as a zero and the programme quietly stops producing signal: staff are never tested, no one is coached, and the compliance report says training ran while the risk stayed untouched.
The other failure is worse: the admin, frustrated, adds the simulation sender to every allowlist they can find, including blanket allow rules that apply to real mail too. That trades programme accuracy for a real hole in mail security. Microsoft's own guidance exists precisely to prevent this - there is a dedicated mechanism for simulation mail, and using it correctly means only messages from the known simulation infrastructure get the override.
Who this is for
MSPs running phishing simulations for Microsoft 365 clients, and internal IT admins launching a first campaign. If your simulations vanish into Junk or never arrive, this is the fix.
What Microsoft provides: the advanced delivery policy
Microsoft 365 documents a purpose-built mechanism for non-Microsoft phishing simulations in the advanced delivery policy. Microsoft's guidance is explicit that allowlists and filtering bypasses are normally forbidden in secure-by-default tenants, and the advanced delivery policy is the narrow exception: it marks identified messages with a Phishing simulation system override instead of filtering them.
In the Microsoft Defender portal, the path is:
- Go to the Microsoft Defender portal at security.microsoft.com.
- Navigate to Email & collaboration > Policies & rules > Threat policies > Advanced delivery (you can go directly to the Advanced delivery page).
- Select the Phishing simulation tab.
- Select Add (or Edit if entries already exist) and fill in the simulation's infrastructure details.
Messages identified by the policy arrive unfiltered, are not quarantined as phishing, and show up in admin experiences with the Phishing simulation override tag - which also means your security reporting can distinguish simulation clicks from real incidents later.
What you need from your simulation platform
The advanced delivery policy for phishing simulations requires three inputs, and Microsoft caps each:
- Domain - the email domains your simulation mail is sent from. You can add up to 50. Microsoft matches on at least one domain and one sending IP; there is no association kept between specific values, so the pair (any listed domain, any listed IP) qualifies.
- Sending IP - the IPv4 addresses the simulation platform sends from, up to 10 entries. Take these from a real simulation message's Authentication-Results header - the docs show exactly how to read the sender IP, MAIL FROM domain and DKIM domain out of a sample header.
- Simulation URLs to allow - up to 30 entries, and this one is optional: it is for links in non-email simulations (links in Teams messages or Office documents) that should not be treated as real threats at time of click. For links inside simulation emails, nothing is needed.
Get the domain and IP values from your simulation vendor's sending infrastructure - most simulation vendors publish their sending domains and IPs for exactly this purpose. Guessing them from the From address alone is the most common misconfiguration, because the visible From domain and the envelope (MAIL FROM) domain are often different.
Step by step
- Send one test simulation to a test mailbox before configuring anything.
- Read the headers of the delivered (or blocked) message and note the Authentication-Results values: sending IP, smtp.mailfrom domain, DKIM domain.
- Open the advanced delivery policy in the Defender portal, Phishing simulation tab, and add those domains and IPs.
- Save, then resend the test simulation to the same mailbox.
- Confirm the result: the message lands in the Inbox, unfiltered, carrying the Phishing simulation system override.
- Then launch the real campaign and check the first delivery report before announcing it.
What NOT to do
Microsoft's docs call out several shortcuts that cause more problems than they solve:
- Do not add simulation URLs to the Tenant Allow/Block List. Microsoft's guidance on the Tenant Allow/Block List says directly: to allow phishing URLs from non-Microsoft phishing simulations, use the advanced delivery policy, not URL allow entries. Allow entries there expire anyway - 30 to 45 days by default - and your campaign outlives them.
- Do not add simulation URLs to the do-not-rewrite list in Safe Links policies. Microsoft notes this might result in unwanted alerts for URL clicks, and it is unnecessary: phishing simulation URLs in email messages are automatically allowed both during mail flow and at time of click.
- Do not build a transport rule that allowlists a sender domain for everyone. That rule applies to real mail from a spoofed or lookalike domain too. The advanced delivery policy applies only to identified simulation infrastructure.
- Do not add your on-premises or third-party gateway IPs to the simulation entries to work around mail-routing quirks. Microsoft warns this effectively bypasses spam filtering for any internet sender who impersonates the listed domain. If your MX records do not point straight at Microsoft 365, the correct fix is configuring Enhanced Filtering for Connectors so Microsoft sees the true source IP.
Troubleshooting
- Still landing in Junk after configuring. The sending IP is missing or wrong - IP and domain both must be listed, and IPv6 is currently supported only via PowerShell. Re-read the test message's headers.
- Works for one client, not another. The policy is per-tenant. Each Microsoft 365 tenant you simulate against needs its own advanced delivery entries.
- Messages delivered but links blocked at click time. Check whether a custom Safe Links policy with do-not-rewrite rules is interfering - with the setting do not rewrite URLs, checks via SafeLinks API only, Microsoft confirms time-of-click protection does not treat simulation links as threats in current Outlook versions; older versions should drop the custom rewrite rules.
- Mail routed through a gateway to on-premises and back. This in-and-out routing scenario breaks the IP detection the policy relies on - Microsoft documents it as unsupported for enhanced filtering; use the documented workarounds or route simulation mail differently.
- Nothing arrived at all. Check quarantine and the message trace first - if the simulation mail never reached the transport pipeline (direct injection bypasses it), the advanced delivery policy does not apply.
What to do next
Whitelisting is plumbing; the programme is what matters. Set the sending domains and IPs once per client, verify with one test mailbox each, and then run the actual measurement with phishing simulations on top of security awareness training. If you are standardising delivery across a client base and want the operational reporting to match, human risk reporting turns the click and report data into something you can put in front of a board.
FAQ
Where is the whitelist setting for phishing simulations in Microsoft 365?
The Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Advanced delivery > Phishing simulation tab. This advanced delivery policy is the documented mechanism for non-Microsoft simulation mail.
Can I just add the simulation sender to the Tenant Allow/Block List?
No. Microsoft's guidance says to use the advanced delivery policy for simulation URLs, not the Tenant Allow/Block List, and allow entries there expire after 30-45 days anyway.
Do I need to whitelist the simulation links too?
No. Phishing simulation URLs in email are automatically allowed during mail flow and at time of click. Only add URL entries for links in non-email simulations, such as Teams messages or documents.
What values do I enter?
The sending email domains (up to 50) and sending IPv4 addresses (up to 10) from your simulation platform's infrastructure. Read them from a real test message's Authentication-Results header to be sure.
Does this weaken our email security?
Marginally and deliberately: identified simulation mail is exempt from filtering, which means a real attacker who somehow compromised the simulation platform's infrastructure could reach inboxes - which is why the values should be exact and minimal. Everything else, including malware and high-confidence phishing, stays blocked.
How do I verify it worked?
Send a test simulation to a test mailbox and confirm it lands in the Inbox carrying the Phishing simulation system override, visible in the message's admin view.
One last thing
Whitelisting removes the filter's protection exactly where you are testing people - so make sure your simulation platform's reporting distinguishes simulation clicks from real phishing reports. If your human risk reporting cannot tell the two apart, fix that before the next campaign, or the numbers will not survive contact with an auditor.