1. Purpose

This document explains the email delivery flow for phishing simulation emails sent to users hosted on Microsoft 365 (Exchange Online) and read in Outlook, the different points at which an email can be blocked or delayed, what needs to be whitelisted, and how to troubleshoot delivery issues.

The objective is to ensure that authorized phishing simulation emails are delivered to the intended users' inboxes reliably and with minimum delay while keeping the simulation limited to the approved sender, domain, IP and recipient scope.

2. What Needs to Be Whitelisted

Before starting a phishing simulation campaign, obtain the following information from the simulation platform.

A. Sending Domain

Example: securebankupdate.com

If multiple sending domains are used, all approved domains should be reviewed.

B. Sending IP Address

The actual public IP address used by the simulation platform to send the email should be identified and reviewed for allow-listing.

Example: 82.25.108.185

The required IP is the mail-sending server IP, not the user's IP address after clicking the phishing link.

C. Simulation URLs / Tracking Domains

If the simulation contains:

• tracking links
• phishing landing pages
• redirect URLs
• image-hosting domains
• click-tracking domains

the relevant approved domains should also be reviewed with the customer's security/network team.

3. The Advanced Delivery Policy (Phishing Simulation)

Microsoft 365 Defender includes a policy specifically for third-party phishing simulation platforms and SecOps mailboxes: Advanced delivery → Phishing simulation. For a message that matches the configured sending domain and IP, it results in the following:

• Anti-spam and anti-phishing filters take no action on the message, and Zero-hour auto purge (ZAP) does not remove it after delivery.
• Safe Links does not block the URLs or run time-of-click detonation on them - the links are still wrapped for tracking, but clicking them is not blocked.
• Safe Attachments does not detonate (sandbox) attachments in the message.
• Default system alerts are not triggered, and an admin submission for the message auto- responds that it is part of a recognized phishing simulation.

Important: unlike the SecOps mailbox scenario, the phishing-simulation configuration does not bypass core anti-malware filtering. If a simulation ever carries a real attachment of a type Microsoft 365 blocks by default, that attachment can still be stripped or the message quarantined - see Section 15.

Caution: because this policy lets messages skip real protection, enter only the verified simulation vendor's sending domain(s) and IP address(es) here - never the organization's own domain, and never a broad range added “just in case.” Review the entries after the campaign and remove any that are no longer needed.

Note: if the organization's MX records point to a third-party Secure Email Gateway (SEG) in front of Microsoft 365, that gateway needs its own, separate exclusion in addition to - not instead of - this policy. See Section 12.

4. Detailed Microsoft 365 Whitelisting Steps

This section expands each whitelisting action into a full click-by-click procedure. Exact menu labels can shift slightly as Microsoft updates the Defender portal - if a label has moved, the underlying setting is still under Email & collaboration → Policies & rules → Threat policies in the Microsoft 365 Defender portal (security.microsoft.com).

Step 1 - Sign In to the Microsoft 365 Defender Portal

1. Go to security.microsoft.com (or open the Microsoft 365 admin center and choose Show all → Security).
2. Sign in with an account that holds Global Administrator, Security Administrator, or an equivalent Defender for Office 365 role. A standard mailbox user cannot edit organization-wide policies.
3. In the left-hand navigation, expand Email & collaboration.
4. Select Policies & rules, then Threat policies.
5. The Threat policies page lists Policies (Anti-spam, Anti-phishing, Anti-malware, Safe Links, Safe Attachments, DKIM…) and, further down, Rules (Advanced delivery, Tenant Allow/Block Lists, Quarantine policy).

Step 2 - Configure the Advanced Delivery Policy for the Simulation

1. From Threat policies → Rules, select Advanced delivery (direct link: security.microsoft.com/advanceddelivery).
2. Select the Phishing simulation tab.
3. If a configuration already exists, select Edit; otherwise select Add.
4. Domain: enter every sending domain the vendor publishes, e.g. securebankupdate.com.
5. Sending IP: enter every published sending IP address or range, e.g. 82.25.108.185. Get the complete, current list from the vendor's sending-infrastructure documentation, not by inspecting a single sample header.
6. Simulation URLs to allow: add the vendor's tracking/landing root domains, typically formatted as a wildcard such as *.simulation-domain.com/*.
7. Select Add (or Save), then Close.
8. Allow a short propagation delay, then send a test simulation.

Step 3 - Add the Sender to the Anti-Spam Allowed List (Supplementary Layer)

1. From Threat policies → Policies, select Anti-spam.
2. Open the inbound anti-spam policy that applies to the pilot or target recipients (or the default policy).
3. Edit the allowed and blocked senders and domains for that policy. Add the simulation sender address(es) under Allowed senders, and the sending domain(s) under Allowed domains.
4. Save.
5. This list is ignored for any recipient covered by a Standard or Strict preset security policy - use the Advanced Delivery policy (Step 2) and, if necessary, the Tenant Allow/Block List (Step 6) for those recipients instead.

Step 4 - Add the Sending IP to the Connection Filter Policy (Only If Steps 2-3 Are Insufficient)

1. From Threat policies → Policies → Anti-spam, select Connection filter policy (Default) (direct link: security.microsoft.com/antispam).
2. Select Edit connection filter policy.
3. Under Always allow messages from the following IP addresses or address range, add the verified sending IP(s).
4. Save, then re-test.
5. Caution: this bypasses spam filtering for every message from that IP, not just the simulation. Treat it as a last resort, scope it as narrowly as possible, and review the entries after the campaign.

Step 5 - Exclude Simulation URLs from Safe Links Rewriting (Only If the Vendor Requires Unwrapped URLs)

1. From Threat policies → Policies, select Safe Links.
2. Open the policy that applies to the target recipients and select Edit protection settings.
3. Under Do not rewrite the following URLs in email, select Manage URLs, then Add URLs.
4. Enter the vendor's root tracking domain(s), typically as *.domain.com/*, and save.
5. Messages allowed through the Advanced Delivery policy already have Safe Links “wrap but don't block or detonate at click,” which is sufficient for most simulations. Only add this exclusion as well if the vendor's click-tracking specifically requires the raw, unwrapped URL - doing it unconditionally can also make simulation links easier for users to spot as a test.

Step 6 - Check the Tenant Allow/Block List and Blocked Senders for Conflicts

1. From Threat policies → Rules, select Tenant Allow/Block Lists (direct link: security.microsoft.com/tenantAllowBlockList).
2. On the Domains & addresses tab and the URLs tab, search for the simulation sender's address, domain, and tracking/landing URLs.
3. Also check the Blocked senders / Blocked domains lists in the anti-spam policy from Step 3.
4. A block entry always overrides an allow entry, an Advanced Delivery entry, or a Connection Filter allow entry for the same sender - if present, delivery fails regardless of Steps 2-5.
5. Remove or modify a conflicting block only with the customer's approval, then re-test.

Step 7 - Check User-Level Safe Senders / Blocked Senders Lists

1. Individual mailboxes can carry their own Safe Senders and Blocked Senders lists (Outlook's Junk Email settings), which layer on top of the organization-wide policies for that mailbox only.
2. As an admin, review or set this remotely with Exchange Online PowerShell - for example, Get-MailboxJunkEmailConfiguration and Set-MailboxJunkEmailConfiguration.
3. Ask pilot users to check Outlook's Junk Email options themselves, or add the simulation sender to their own Safe Senders list, with their and the customer's awareness that this is a controlled test.

Step 8 - Review Mail Flow Rules, Anti-Phishing Policy, and Preset Security Policies

1. From Threat policies → Rules → Rules (or the Exchange admin center → Mail flow → Rules), look for any rule that moves, rejects, quarantines, or modifies messages based on sender, domain, subject keywords, or content patterns - phishing-style subject lines and links are exactly what many such rules are built to catch.
2. From Threat policies → Policies → Anti-phishing, open the applicable policy and check the phishing threshold, spoof intelligence, and impersonation settings (see Section 11).
3. Check whether the target recipients are included in a Standard or Strict preset security policy - preset policies ignore the custom allow lists from Steps 3–4 and require the Advanced Delivery policy, or a scoped Tenant Allow/Block List entry, instead.
4. Add a scoped, approved exception - limited to the simulation sender and the pilot recipient group - rather than disabling a rule or policy organization-wide.

Step 9 - Check Quarantine

1. From Email & collaboration, select Review, then Quarantine (direct link: security.microsoft.com/quarantine).
2. Filter the Email tab by sender, recipient, or subject.
3. Open the message and check the Quarantine reason shown (Spam, Phishing, Bulk, Malware, Transport rule…) - this indicates which layer actually caught it.
4. If confirmed as the authorized simulation, select Release (or approve a user's release request), and adjust the underlying setting from Steps 2-8 so future sends don't need a manual release. Messages quarantined as Malware or High confidence phishing generally cannot be released on the strength of an ordinary allow list - this is why Step 2 matters, since Advanced Delivery is the mechanism designed to keep a verified simulation out of that classification in the first place.

5. Microsoft 365 Blocking / Filtering Methods

A phishing simulation email can be blocked or delayed through multiple independent mechanisms.

1. IP / Connection Filtering & Reputation

The sending IP may have poor reputation or fail connection-level checks.

Symptom: rejection, delay, SMTP error.

Action: check the connection filter policy and the sending IP's reputation.

2. Anti-Spam (Content) Filtering

Microsoft 365's spam filter can classify the message based on content, structure, and sender signals.

Symptom: message goes to Spam, is quarantined, or delivery is delayed.

Action: review the anti-spam policy and allowed senders/domains.

3. Anti-Phishing / Spoof Intelligence

Basic anti-phishing protection, included with every mailbox, evaluates spoofing signals and authentication results.

Symptom: quarantine, an “unauthenticated sender” indicator on the message.

Action: review the anti-phishing policy and the spoof intelligence insight.

4. Impersonation Protection

Because phishing simulation emails intentionally resemble real attacks, Defender for Office 365 may flag display-name or domain impersonation.

Symptom: warning banner, quarantine.

Action: add a trusted sender/domain exception in the anti-phishing policy (Section 11).

5. Safe Links (URL Protection)

Safe Links rewrites and, at time of click, re-checks URLs in the message.

Symptom: click warning, blocked landing page, delay while a link is checked.

Action: confirm Advanced Delivery is configured; add a Safe Links exclusion only if the vendor's tracking needs an unwrapped URL.

6. Safe Attachments

Defender for Office 365 can detonate (sandbox) attachments before delivery.

Symptom: attachment delayed or stripped, message quarantined.

Action: confirm Advanced Delivery is configured; use only approved, low-risk attachment types (Section 15).

7. Mail Flow Rules (Transport Rules)

An organization rule may route, modify, or reject the message before it reaches filtering.

Symptom: unexpected routing, an added banner or subject tag, rejection.

Action: review Rules for matches against the simulation sender or content.

8. Quarantine

Any of the filters above can route the message to quarantine instead of blocking it outright.

Symptom: message never appears in the Inbox but is visible in Quarantine.

Action: review the quarantine reason and release if confirmed safe.

9. External Gateway / Firewall / Proxy

The customer may have additional security infrastructure before or around Microsoft 365.

Symptoms: connection failure, blocked link, landing page unavailable.

See Sections 12-13.

6. SPF

SPF verifies whether the sending server is authorized to send email for the domain in the message's return-path.

Symptoms of SPF Problems

• Spam placement
• Quarantine
• Authentication failure
• DMARC failure
• Rejection

If the simulation platform sends using a dedicated simulation domain, that domain needs a valid SPF record authorizing the vendor's own sending servers - this record lives on the vendor's domain and is normally the vendor's responsibility, not something configured inside the Microsoft 365 tenant. The tenant's own SPF record (typically v=spf1 include:spf.protection.outlook.com -all) is unrelated to a third-party simulation domain and does not need to change for a campaign.

7. DKIM

DKIM adds a cryptographic signature to the email that receiving systems can verify against a public key published in DNS.

Symptoms of DKIM Problems

• Authentication failure
• Spam placement
• Quarantine
• DMARC failure

The tenant's own DKIM configuration is managed from Threat policies → DKIM in the Defender portal, where each accepted domain shows the two CNAME records (selector1/selector2) it needs and a toggle to enable signing. As with SPF, the DKIM signature that matters for a simulation is the vendor's, published against their own sending domain - configure this correctly with the vendor if the simulation uses a dedicated domain.

8. DMARC

DMARC works with SPF and DKIM to validate whether the email is authorized and aligned with the domain shown to the recipient.

DMARC policies can instruct receiving systems to: monitor, quarantine, reject.

If the vendor's DMARC policy on the simulation domain is set to quarantine or reject and their SPF/DKIM alignment isn't correct, Microsoft 365's composite authentication check can fail the message even when the domain and IP are allow-listed elsewhere in this guide. The Advanced Delivery policy (Section 4) is one of the few mechanisms that can still let the message through in that situation, but for reliable long-term delivery, ask the vendor to fix authentication alignment on their end rather than relying on the bypass indefinitely.

9. Display Name Spoofing / Impersonation Protection

Defender for Office 365 can identify emails where the display name appears to impersonate an internal user or executive.

Example: From: CEO Name  [email protected]

The actual sender is external, but the display name matches an internal employee.

Symptoms

The user may see: an impersonation warning, a caution/security banner, an external sender warning, a sender-name mismatch warning, or other anti-phishing indicators.

What to Check

1. Sign in to the Microsoft 365 Defender portal.
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Anti-phishing.
3. Open the applicable policy and go to the Phishing threshold & protection page.
4. Check whether user impersonation or domain impersonation protection is turned on and whether the simulation sender is being identified as an impersonation attempt.
5. Select Manage trusted senders and domains, then add the simulation sender under the Sender tab or the simulation domain under the Domain tab.
6. Save, and run a test campaign.

Important

Impersonation protection is part of Defender for Office 365 (Plan 1 or 2) - organizations on Exchange Online Protection alone do not have this feature to configure; see Section 22 for licensing tiers.

Caution: do not turn off impersonation protection organization-wide just to make the phishing simulation look realistic. The objective should be a controlled, scoped exception for the authorized simulation while keeping normal anti-impersonation protection active for everything else.

10. Mail Server / Secure Email Gateway

Microsoft 365 may not be the only email-security layer in the path.

A typical customer environment may look like: internet → secure email gateway or firewall → Microsoft 365 (Exchange Online Protection / Defender for Office 365) → Outlook. Possible additional controls include: email security gateways, firewalls, DNS filtering, secure web gateways, third-party anti-spam systems, and endpoint security.

What to Check

Confirm that the organization's MX records actually point to Microsoft 365 and not to a third-party gateway first. If a gateway such as Proofpoint, Mimecast, or Barracuda sits in front of Microsoft 365, it needs its own allow-list entry for the simulation sender/domain/IP, independent of everything configured in Sections 4–5. If the organization runs Exchange in a hybrid configuration with an on-premises server, check on-premises transport rules and connectors too.

11. Proxy Settings

Proxy or secure web gateway settings can affect the phishing simulation landing page.

The email may reach the Inbox correctly but the user may be unable to open the simulation link.

Symptoms

• email received
• link does not open
• security warning
• redirect fails
• landing page does not load

Solution

Review and, if approved, allow: the simulation landing-page domain, tracking domain, redirect domain, and required HTTPS URLs.

Do not disable proxy security globally.

12. Browser Plugins / Endpoint Security

Browser security extensions, antivirus, and EDR can interfere with the simulation - including Microsoft's own endpoint controls, such as Microsoft Defender SmartScreen in Edge, in addition to third-party products.

Possible controls: browser security, antivirus, EDR, anti-phishing extensions, web filtering, DNS protection.

Symptoms

• link blocked
• landing page blocked
• browser phishing warning
• redirect blocked
• tracking not working

Solution

Create a scoped exception for the authorized simulation where required.

Do not disable antivirus, EDR, or browser security globally.

13. Malware / Attachment Filtering

Anti-malware policies and Safe Attachments can inspect attachments for malicious content.

This is especially relevant when a simulation contains: executable files, scripts, macros, suspicious archives, unusual file types.

Symptoms

• attachment removed
• email quarantined
• warning shown
• email rejected

Recommended Approach

Use safe simulation content wherever possible. Remember that the Advanced Delivery policy's phishing-simulation configuration does not bypass core anti-malware filtering the way it bypasses spam and phishing verdicts (Section 4) - avoid attachment types Microsoft 365 blocks by default (for example .exe, .js, or .vbs) unless specifically approved with the customer. If an attachment is required, confirm the approved file type and security handling with the customer, and check the Anti-malware policy under Threat policies for the common-attachment-type block list.

14. The “External” Tag

Microsoft 365 can display an External tag/banner on messages received from outside the organization.

How It Works

The native tag is controlled tenant-wide with the Set-ExternalInOutlook cmdlet in Exchange Online PowerShell - there is no toggle for it in the Defender portal or the Exchange admin center. The cmdlet also accepts an allow list of trusted domains that should not receive the tag.

Some organizations instead use an older, custom mail flow rule that prepends [External] to the subject line or adds a disclaimer for messages from outside the organization - if both are in use at once, the customer should disable one to avoid duplicate labeling.

How to Handle It

If the customer wants to exclude the simulation domain from the External tag, or remove/customize the tag altogether, the organization's email administrator needs to review the Set-ExternalInOutlook configuration (or the equivalent mail flow rule).

Only modify it if the customer has explicitly approved the change - removing the External tag for a domain also removes it for every future message from that domain, not just the simulation.

15. External Images

Outlook can block automatic loading of external images.

Symptoms

The email reaches the Inbox but: the logo does not appear, a tracking pixel does not load, images are hidden, or the user sees an “images were blocked” bar.

Solution

• Log in: Open your browser and go to the Microsoft 365 Apps Admin Center (://office.com).
• Create a plan: Go to Policy Management and click Create to make a new policy configuration.
• Name it: Give your policy a name (like "Force Outlook Images") and choose who gets it (all users or a specific group).
• Search the rule: In the settings search bar, type "block external content" or "automatic picture download".
• Configure it: Look for the policy named "Display pictures and external content in HTML email".
• Set it: Set the configuration to Disabled (which unblocks the pictures).
• Publish: Click Save and Publish. It will automatically push to your users' laptops over the internet.

16. Symptoms When Whitelisting Is Not Done Properly

Issue	Possible Symptom
Sending IP not allow-listed	Rejection / delay / SMTP error
Domain not in Advanced Delivery	Spam / quarantine
Sender not in Advanced Delivery / anti-spam list	Spam / quarantine
Advanced Delivery policy not configured	Full spam, phishing, Safe Links & Safe Attachments checks apply
SPF failure	Authentication issue / Spam
DKIM failure	Authentication issue / Spam
DMARC failure	Quarantine / rejection
Impersonation detected	Warning / caution banner
Mail flow rule match	Spam / quarantine / rejection / rerouting
Preset security policy in scope	Custom allow lists ignored
Rate limiting	Partial delivery / delay
Firewall block	Connection failure
Secure Email Gateway block	Quarantine / rejection
Proxy block	Link does not open
EDR / AV block	Link or attachment blocked
Browser plugin / SmartScreen	Phishing warning / page blocked
External images disabled	Images not displayed
External tag / sender policy	External banner / label

17. Recommended Customer-Side Checklist

Sender Configuration

☐     Simulation sender email identified

☐     Sending domain identified

☐     Sending IP identified

☐     Tracking domain identified

☐     Landing page domain identified

Microsoft 365 Configuration

☐     Advanced Delivery – Phishing simulation configured (domain, IP, URLs)

☐     Sender / domain added to anti-spam Allowed senders / domains

☐     Connection filter IP Allow List reviewed (only if needed)

☐     Safe Links “do not rewrite” list reviewed (only if needed)

☐     Tenant Allow/Block List reviewed for conflicts

☐     Anti-spam Blocked senders / domains reviewed

☐     Mail flow rules reviewed

☐     Anti-phishing policy / impersonation trusted senders reviewed

☐     Preset security policy membership checked

☐     Quarantine reviewed

Network

☐     Firewall checked

☐     Secure Email Gateway checked

☐     Proxy checked

☐     DNS filtering checked

☐     URL filtering checked

Endpoint

☐     Antivirus checked

☐     EDR checked

☐     Browser security checked

☐     Browser plugins checked

Simulation

☐     Test campaign completed

☐     Inbox delivery confirmed

☐     Spam checked

☐     Quarantine checked

☐     External tag checked

☐     External images checked

☐     Links tested

☐     Landing page tested

☐     Tracking tested

☐     Large-campaign sending rate reviewed against Microsoft 365 receiving limits

18. Troubleshooting

Case 1 – Email Does Not Arrive. Check: simulation platform delivery status, message trace (Section 21), sending IP/domain reputation, Quarantine, Tenant Allow/Block List block entries, Secure Email Gateway/firewall, SPF/DKIM/DMARC.

Case 2 – Email Arrives in Spam. Check: Advanced Delivery configuration, anti-spam allowed senders/domains, Connection Filter IP Allow List, preset security policy membership, user-level Safe Senders, SPF/DKIM/DMARC, mail flow rules. An allow-list entry does not necessarily guarantee Inbox placement in every situation.

Case 3 – Email Is Quarantined. Check: the quarantine reason shown in the portal, authentication failure, Tenant Allow/Block List match, anti-malware/Safe Attachments verdict, anti-phishing verdict.

Case 4 – Some Users Receive the Email and Others Do Not. Check: per-user Safe Senders/Blocked Senders lists, group-based policy assignment, preset security policy scope, mailbox-level rules, endpoint/security controls on that specific device.

Case 5 – First Batch Arrives but Later Emails Are Delayed. Check: Microsoft 365 receiving limits (Section 7), 4xx non-delivery reports, message trace for deferrals, the vendor's sending pace.

Case 6 – Email Reaches Inbox but Link Does Not Work. Check: Safe Links (wrapped vs. blocked), proxy, DNS filtering, firewall, browser security/SmartScreen, landing-page domain reachability.

Case 7 – Email Reaches Inbox but Images Do Not Appear. Check: Outlook → File → Options → Trust Center → Trust Center Settings → Automatic Download, and the mailbox's Safe Senders list.

Case 8 – Email Reaches Inbox but Shows an Impersonation or External Warning. Check: Defender portal → Anti-phishing policy → trusted senders and domains (Section 11), and/or the Set-ExternalInOutlook allow list (Section 16).

19. Message Trace, Delivery Reports & Header Analysis

This section supports Section D (Delivery Logs & Evidence) of the Diagnostic Questionnaire, which the core whitelisting steps in Section 5 did not previously cover.

Running a Message Trace

1. Sign in to the Exchange admin center at admin.exchange.microsoft.com (direct link to the trace page: admin.exchange.microsoft.com/#/messagetrace).
2. In the left-hand navigation, select Mail flow, then Message trace.
3. Select Start a trace.
4. Set the sender, recipient, and time range - up to 90 days of history is available, though a downloadable report is needed for ranges beyond 10 days.
5. Select Search, then open a specific message to view its full delivery timeline: received, filtered, quarantined, delivered, or rejected, along with the responsible component.

Reading the Message Headers

For a message that arrived but landed somewhere unexpected, the full internet headers usually explain why faster than the portal alone. In Outlook (desktop), open the message and select File → Properties to view Internet headers; in Outlook on the web, use View message details from the message menu.

Within the X-Forefront-Antispam-Report header, the SFV field indicates which component made the filtering decision:

• SFV:SKA – allowed by the anti-spam policy's allowed sender/domain list
• SFV:SKB – blocked by the anti-spam policy's blocked sender/domain list
• SFV:SKI – the connection filter's IP Allow List bypassed filtering
• SFV:SKN – a mail flow rule bypassed filtering (SCL - 1)
• SFV:SPM – the content filter marked the message as spam

The IPV field similarly shows whether the connection filter recognized the source IP (for example, IPV:CAL means the IP matched the Connection Filter Allow List). Comparing the headers of one blocked or delayed message against one that delivered successfully is usually the fastest way to isolate exactly which control point diverged.

20. Safe Links & Safe Attachments - Licensing Tiers and Sandboxing

This section supports Section C (Proxy, URL Rewriting & Sandboxing) and the related items in Section E (Whitelisting Checklist) of the Diagnostic Questionnaire.

Unlike mailbox platforms where URL rewriting and attachment sandboxing are a separate add-on bolted onto the core mailbox product, Microsoft 365 offers this natively - but only at certain licensing tiers, so whether it applies to a given tenant depends on what the organization is licensed for:

• Exchange Online Protection (EOP) - included with every Exchange Online / Microsoft 365 mailbox. Provides anti-spam, anti-malware, and basic anti-phishing (spoof intelligence). Does not include Safe Links, Safe Attachments, or impersonation protection.
• Defender for Office 365 Plan 1 - adds Safe Links (real-time URL rewriting and time-of-click sandboxing), Safe Attachments (attachment detonation/sandboxing), and impersonation protection in anti-phishing policies.
• Defender for Office 365 Plan 2 (included in Microsoft 365 E5) – adds Threat Explorer, automated investigation and response, and attack simulation training, on top of everything in Plan 1.

Practical implication for simulation whitelisting: if the tenant only has EOP, Section 11 (impersonation) and the Safe Links/Safe Attachments portions of Sections 5, 6, and 15 don't apply - those checklist items should be answered “N/A - EOP only, no Defender for Office 365.” If the tenant has Defender for Office 365 Plan 1 or 2, the Advanced Delivery policy (Section 4) is what suppresses Safe Links and Safe Attachments action on the simulation; a separate manual Safe Links “do not rewrite” entry (Section 5, Step 5) is only needed on top of that if the vendor's tracking specifically requires an unwrapped URL.

If a third-party Secure Email Gateway with its own URL-rewriting or sandboxing sits in front of Microsoft 365 (Section 12), it needs a separate exclusion inside that product, in addition to - not instead of - the Microsoft 365 steps in Section 5.

\n