What is phishing simulation whitelisting?

Phishing simulation whitelisting is the set of mail-platform configuration changes that allow simulated phishing messages from your vendor's sending infrastructure to bypass your spam filter, junk folder routing, link-rewriting protections and attachment scanning - while keeping every other inbound email subject to those same protections. Without whitelisting, simulation messages get blocked, sent to junk or rewritten by Advanced Threat Protection, which both invalidates the test and makes click metrics meaningless. The whitelisting process is operationally distinct from the simulation campaign itself and is the most common source of phishing-program rollout delays.

Why won't my phishing simulation emails reach the inbox?

Three common reasons. One: the spam filter (Exchange Online Protection in Microsoft 365 or the Workspace equivalent in Google) is blocking the sending IP because it's flagged as bulk or suspicious. Two: the message is reaching the inbox but is being routed to the junk folder by user-level rules or per-tenant scoring - this is a separate fix from the spam filter. Three: Office 365 Advanced Threat Protection is rewriting links or detonating attachments before the user sees them, which produces false clicks in the simulation data and makes the metrics unusable. Each failure mode has a different whitelisting fix and the right path depends on your existing mail-policy posture.

How do I whitelist phishing simulations in Google Workspace?

Google Workspace uses a different admin model than Microsoft 365 but supports the same conceptual approach. Add the simulation vendor's sending IPs or sending domain to the inbound gateway whitelist in the Google Workspace admin console, then create a content-compliance rule that allows messages from the vendor through any additional spam/phishing filters. Workspace's link-scanning (similar in function to Office 365 Safe Links) has its own bypass configuration. The Workspace setup typically requires fewer custom rules than Office 365 because the spam-filter posture is simpler, but the gotcha is that user-level Gmail rules can still route simulations to spam regardless of admin-level whitelisting - so Workspace deployment includes verifying that user-level rules aren't overriding the admin allowlist.

Can I run a phishing simulation without whitelisting?

Technically yes, but the data is unusable. Without whitelisting, you don't know whether non-click outcomes reflect users recognizing the phish, the spam filter blocking it, the junk folder hiding it, or ATP rewriting the link before the user saw it. The simulation becomes a test of your spam filter rather than your workforce. Mature phishing-simulation programs treat whitelisting as a deployment prerequisite, not an optional step. Some vendors will tell you whitelisting is unnecessary because their domains have high reputation - this is misleading; high domain reputation reduces filter-blocking but does not address ATP rewriting or junk-folder routing. Verify whitelisting is documented and working before the baseline test.

Phishing Simulation Whitelisting Guide 2026: Microsoft 365, Exchange & Google Workspace

Q: Which whitelisting method should I use?

Three methods are commonly supported: IP-based (allowlist the vendor's sending IP range in your spam-filter bypass list), email-header (mail-flow rule that detects a vendor-specific custom header and bypasses filtering for messages carrying it), and SPF-record (add the vendor's sending domain to your SPF record so messages pass authentication on your behalf). IP-based is the simplest for organizations that don't want custom headers in production mail flow. Email-header is the most precise - only messages carrying the exact header bypass filtering, which limits the scope of the whitelist. SPF-record is the lowest-friction option and works well when the vendor sends from a stable set of domains. Modern phishing-simulation platforms document all three so you can pick the path that fits your existing mail-policy posture.

Q: Does Office 365 ATP block phishing simulations?

Yes, often. Office 365 Advanced Threat Protection (also called Microsoft Defender for Office 365 in current branding) does two things that interfere with simulation: it rewrites URLs through Safe Links so clicks get pre-processed by Microsoft's URL reputation service (producing false clicks in the simulation data), and it detonates attachments in a sandbox before delivery (which can trigger false attachment-open events). Both behaviors require dedicated ATP bypass rules - typically a transport-rule exception that excludes the vendor's sending domain from Safe Links rewriting and attachment processing. Without these rules, the click metrics produced by the simulation are unreliable because they reflect ATP scanning, not user behavior.

Phishing Simulation Whitelisting Guide 2026: Microsoft 365, Exchange & Google Workspace

Whitelisting is the single most-cited operational pain point in a phishing simulation rollout. Done well, it completes in a single admin session and the program runs reliably for years. Done badly, it consumes days of trial-and-error on transport rules, ATP bypass exceptions, junk-folder routing and SPF-record edits before the baseline campaign can even fire. This guide covers the three documented whitelisting methods (IP-based, email-header, SPF-record), the platform-specific configurations for Microsoft 365 / Exchange 2013 / Exchange 2016 / Google Workspace, the gotchas you'll hit with Office 365 Advanced Threat Protection and junk-folder routing, and how to verify the whitelist is working before the baseline test.

The goal is a configuration where simulated phishing messages from your vendor bypass spam-filter blocking, junk-folder routing, ATP link-rewriting and attachment processing - while every other inbound email stays subject to those protections. That's a narrow exception, not a general bypass. The right method depends on your existing mail-policy posture.

The three documented whitelisting methods

IP-based whitelisting adds the vendor's sending IP range to the spam-filter bypass list. This is the simplest approach for organizations that don't want custom headers in production mail flow. The configuration is one admin-center change. The trade-off is that any future change to the vendor's sending IP range requires a corresponding update on your end.

Email-header whitelisting uses a mail-flow rule that detects a vendor-specific custom header (typically applied at the sending edge) and bypasses filtering only for messages carrying that exact header. This is the most precise method - it limits the whitelist scope to messages that explicitly carry the simulation marker and prevents an attacker who manages to send through the vendor's IP from inheriting the bypass. Organizations with restrictive transport-rule postures usually pick this method.

SPF-record whitelisting adds the vendor's sending domain to your SPF record so simulation messages pass authentication on your behalf. This is the lowest-friction option and works well when the vendor sends from a stable set of domains. Some organizations combine SPF with IP-based or header-based for layered confidence.

Microsoft 365 and Exchange Online

Microsoft 365 (and Exchange Online inside it) is the most common deployment target and has the largest gotcha surface. The IP-based path: add the vendor's sending IP range to the IP Allow List in the Anti-Spam policy of Microsoft Defender for Office 365 (or Exchange Online Protection if you don't have Defender). The header-based path: create an inbound mail-flow rule in Exchange Online that detects the vendor's custom header value and sets the spam-confidence-level to bypass. Both methods work; pick based on your existing rule discipline.

Exchange 2013 and Exchange 2016 on-premise use the same conceptual model but a different admin tooling. The IP-based path applies to the Edge Transport server or the hub transport's connection-filter agent; the header-based path uses an Exchange Management Shell rule on the transport service. The configurations are documented separately because the on-premise admin model is materially different from the cloud admin model. Hybrid deployments need both paths configured because messages can route through either edge.

Office 365 Advanced Threat Protection bypass

This is where most rollouts trip up. If you have Office 365 ATP active (also called Microsoft Defender for Office 365 in current branding), two ATP behaviors interfere with simulation data: Safe Links URL rewriting pre-processes every link through Microsoft's URL reputation service, which produces false clicks in the simulation data because ATP's reputation check looks like a user click to the tracking pixel; and Safe Attachments detonates attachments in a sandbox before delivery, which can trigger false attachment-open events.

Both behaviors require dedicated bypass rules - typically transport-rule exceptions that exclude the vendor's sending domain from Safe Links rewriting AND from Safe Attachments processing. These rules are separate from the IP-allowlist or header-whitelist used for the spam-filter bypass. Skipping the ATP bypass produces a simulation that runs without errors but reports inflated click and open rates because every message has been pre-clicked by ATP itself. That corruption is not visible to the program operator without comparing simulation data to user-survey self-reports.

Google Workspace

Workspace uses a different admin model but supports the same conceptual approach. Add the vendor's sending IPs or sending domain to the inbound gateway whitelist in the Workspace admin console, then create a content-compliance rule that allows messages from the vendor through any additional spam or phishing filters. Workspace's URL-scanning (similar to Office 365 Safe Links in function) has its own bypass configuration in the Workspace admin's Gmail security settings.

The Workspace gotcha is user-level Gmail rules. Even when admin-level whitelisting routes the message correctly, an individual user's spam rule, filter or block list can still route simulations to spam or trash. Workspace deployment should include verifying on at least three users in different cohorts (executive, IT, end-user) that the admin allowlist actually delivers to the inbox.

Junk-folder bypass

Sometimes the message gets past the spam filter but still routes to the junk folder. This is a separate fix - typically a transport rule that explicitly sets the message's spam-confidence-level to "not junk" or a per-user safe-sender list applied at the admin level. The junk-folder bypass is most visible in Office 365 / Exchange Online because the default junk-folder routing is aggressive; Google Workspace has a similar pattern at the per-user filter level.

SPF record method

The SPF-record method works at a different layer than the IP-allowlist or header-whitelist. By adding the vendor's sending domain to your SPF record, you authorize the vendor to send mail on your behalf - which both passes SPF authentication and reduces the likelihood of the message being marked as spam or phishing by reputation-based filters. SPF is the lowest-friction option for organizations whose vendor sends from a stable set of domains. It does not replace the ATP bypass rules (Safe Links and Safe Attachments scan regardless of SPF) but it eliminates one of the three common failure modes.

How to verify whitelisting is working

Run a single test message through the configured whitelist before the baseline campaign. Confirm: (1) the message arrives in the recipient's inbox, not the junk folder; (2) the link is not rewritten by Safe Links (check the URL on hover - if it goes through nam01.safelinks.protection.outlook.com or equivalent, the ATP bypass isn't working); (3) attachments are delivered without sandbox detonation latency. If any of those three checks fail, the corresponding configuration needs adjustment. Most rollout-delay incidents trace back to one of those three checks not being verified before the baseline.

Where Bait & Phish fits

Bait & Phish provides documented whitelisting guides for each method (IP-based, email-header, SPF-record) across each platform (Microsoft 365, Exchange 2013/2016, Google Workspace), plus dedicated bypass guides for Office 365 ATP link-rewriting, ATP attachment processing and junk-folder routing. Deployment typically completes in a single admin session rather than the days of transport-rule iteration that enterprise-tier platforms commonly require before simulations land in the inbox reliably. Start a free trial covering up to 25 users to walk through whitelisting with our setup documentation, or contact us for environment-specific configuration help. Pricing is on the pricing page; the free trial is a real trial, not a sales-gated demo.

Blog

Phishing Simulation Whitelisting Guide 2026: Microsoft 365, Exchange & Google Workspace

The three documented whitelisting methods

Microsoft 365 and Exchange Online

Office 365 Advanced Threat Protection bypass

Google Workspace

Junk-folder bypass

SPF record method

How to verify whitelisting is working

Where Bait & Phish fits

Related reading