1. Purpose

This document explains the email delivery flow for phishing simulation emails sent to users hosted on Google Workspace and read in Gmail, the different points at which an email can be blocked, delayed, or flagged, 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.

Important: Whitelisting can significantly improve deliverability, but it does not guarantee instant Inbox delivery or a banner-free inbox. Google Workspace layers several independent checks - spam filtering, Security Sandbox, Safety settings (attachments, links, spoofing), content compliance rules, and any third-party gateway placed in front of it - and a change to one layer does not override the others.

2. What Needs to Be Whitelisted

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

A. Sending Email Address

Example: [email protected]

The exact sending address should be added to the appropriate Google Workspace allow-listing layer where required (see Section 3).

B. Sending Domain

Example: securebankupdate.com

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

C. 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.

D. 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. Google Workspace - Email Allow-Listing Layers

Google Workspace spreads allow-listing across three mechanisms on one settings page (Spam, phishing, and malware), plus separate Safety settings and Compliance rules. Knowing the difference between “not marked as spam” and “no warning banner” matters more here than on some other platforms.

3.1 Email Allowlist (IP-Based)

An organization-wide list of IP addresses whose mail skips spam-folder placement. Per Google's own documentation, mail from an allow-listed IP can still show a Gmail warning banner - the allowlist affects spam classification only, not phishing/spoofing heuristics.

3.2 Approved Senders List (Address/Domain-Based)

Configured as a custom rule in the Spam row of the same settings page. It has two independent checkboxes: one that bypasses spam filtering, and a separate one that bypasses spam filtering and hides warning banners. Only the second option suppresses the phishing-style warning. This is the closest equivalent to a purpose-built “trusted sender” bypass and is covered in full in Section 4.

3.3 Inbound Gateway

A more advanced, connection-level designation for a trusted relay or gateway IP, with an option to mark the source as “internal” (which skips SPF/DMARC authenticity checks) and an option to disable Gmail's own spam evaluation entirely in favor of a custom trusted header. See Step 4 in Section 5.

3.4 Safety Settings & Content Compliance

Independent of the three lists above, and not bypassed by any of them by default. Covered in Sections 6, 11, and 15.

Important: because these lists live on different settings and behave differently - spam-folder bypass vs. warning-banner bypass vs. full evaluation bypass - the most common cause of “it's not in Spam but users still see a warning” is Step 2 (Email allowlist) being configured without Step 3 (Approved senders list with hide warnings also checked).

4. The Approved Senders List (Bypass Spam Filters and Hide Warnings)

An approved senders list is an address list - individual email addresses or entire domains - attached to a custom spam rule. Each entry has an Authentication required toggle, which should be cleared for a simulated sender, since a simulation domain typically won't pass real SPF/DKIM/DMARC checks for the address it's spoofing. When both Bypass spam filters and Bypass spam filters and hide warnings are checked for that list, matching mail is delivered to the inbox without the phishing-style warning banner, and Gmail instead shows a short banner reading approximately: “This message wasn't sent to Spam because of your organization's settings.”

Important: Google's own documentation notes that a message from an approved sender is still blocked from delivery if it's confirmed to carry a virus or be part of a larger email attack - so this is not an unconditional bypass in every case, but it should still be treated as a strong one and scoped as narrowly as possible.

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

5. Detailed Google Workspace Whitelisting Steps

This section expands each whitelisting action into a full click-by-click procedure. Exact menu labels can shift slightly as Google updates the Admin console - if a label has moved, the underlying setting is still under Apps → Google Workspace → Gmail in the Google Admin console (admin.google.com).

Step 1 - Sign In to the Google Admin Console

1. Go to admin.google.com.
2. Sign in with a Admin account, or an account delegated the Gmail Settings administrator privilege. A regular Workspace user cannot edit organization-wide settings.
3. In the left-hand navigation, select Apps, then Google Workspace, then Gmail.
4. Most of the settings in this guide are on the Spam, phishing, and malware page (direct link: admin.google.com/ac/apps/gmail/spam) and the Safety page.
5. If the organization uses multiple organizational units (OUs), select the correct OU - top-level, or the one covering the pilot group - before editing a setting. Gmail settings apply per OU, and child OUs inherit from the parent unless overridden.

Step 2 - Add the Sending IP(s) to the Email Allowlist

1. On the Spam, phishing, and malware page, find Email allowlist and select Edit.
2. Enter the simulation platform's public sending IP address(es). Use CIDR notation for a range, or separate multiple individual IPs with commas.
3. Select Save.
4. Changes can take up to 24 hours to apply, though they're often faster; check the Admin console audit log to confirm the change saved.
5. Get the complete, current IP list from the vendor's sending-infrastructure documentation, not from a single sample header - this setting only accepts public IP addresses.

Step 3 - Create an Approved Senders List (Bypass Spam Filters and Hide Warnings)

1. On the Spam, phishing, and malware page, find the Spam row and select Configure (or Add another rule if one already exists).
2. Give the rule a descriptive name, e.g. “Phishing simulation – [vendor].”
3. Select Bypass spam filters for messages received from addresses or domains within these approved senders lists.
4. Also select Bypass spam filters and hide warnings for messages from senders or domains in selected lists - this second option is what suppresses the phishing-style warning banner.
5. Under each option, select Create or edit list, then Add address list, and add the simulation sender's address(es) or domain(s).
6. For each entry, clear Authentication required, since a simulated sender typically won't pass real SPF/DKIM/DMARC for the spoofed domain.
7. Save the address list, then save the rule.
8. Allow up to 24 hours for the rule to propagate, then send a test simulation.

Step 4 - Configure the Inbound Gateway (Only If Steps 2-3 Are Insufficient)

1. On the Spam, phishing, and malware page, find Inbound gateway and select Edit.
2. Select Enable.
3. Under Gateway IPs, add the verified sending IP address(es).
4. Leave Reject all mail not from gateway IPs unchecked, since the simulation vendor is not the organization's only source of mail.
5. Select Require TLS for connections from the email gateways listed above.
6. Optional, advanced: if the vendor publishes a custom trusted header, a matching expression can be set under Message is considered spam if the following header regexp matches, together with Disable Gmail spam evaluation on mail from this gateway; only use header value - this hands the spam/not-spam decision entirely to the vendor's header rather than Gmail's own evaluation.
7. Save.

Step 5 - Check Content Compliance and Routing Rules for Conflicts

1. In the left-hand navigation under Gmail, select Compliance.
2. Review any Content compliance or Routing rules that match on sender, domain, subject keywords, attachment type, or IP metadata - phishing-style subject lines and links are exactly what many such rules are built to catch.
3. A matching compliance rule can quarantine, reject, or reroute a message regardless of the allow-listing done in Steps 2–4.
4. Add a scoped exception - limited to the simulation sender and the pilot recipient group - rather than disabling a rule organization-wide.

Step 6 - Check Organization-Level Blocked Senders and Denylists

1. On the Spam, phishing, and malware page, review the organization's blocked senders/denylist settings for any simulation sender address, domain, or relevant sending IP.
2. Check for any organization-level configuration that explicitly blocks or rejects messages from the simulation sender or domain.
3. If a conflicting organization-level block is identified, remove or modify it only with the customer's approval, then re-test the simulation.

Step 7 - Review Safety Settings

1. In the left-hand navigation under Gmail, select Safety.
2. Review the Attachments, Links and external images, and Spoofing and authentication sections (detailed in Sections 11 and 15) for the organizational unit covering the pilot group.
3. Each offers a choice of action - warning banner, move to spam, or quarantine. Confirm which action is set, since a quarantine action here will hold the message even if Steps 2-4 are configured correctly.
4. Add a scoped trusted-sender exception where the setting supports one, rather than turning the whole category off.

Step 8 - Check Quarantine

1. From the Admin console, go to Apps → Google Workspace → Gmail → Manage quarantines, or navigate directly to admin.google.com/ac/moderation.
2. Review all quarantines you have access to; the default view shows messages with a Pending triage status.
3. Open the message to see which quarantine - and therefore which rule - caught it.
4. If confirmed as the authorized simulation, select Allow to release it, and adjust the underlying setting from Steps 2-8 so future sends don't need a manual release.

6. Google Workspace Blocking / Filtering Methods

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

1. IP / Connection-Level Filtering

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

Symptom: rejection, deferral, SMTP error.

Action: check the Email allowlist / Inbound Gateway and the sending IP's reputation.

2. Spam (Content) Filtering

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

Symptom: message goes to Spam.

Action: review the Approved senders list (Section 4).

3. Spoofing and Authentication Checks

Basic protection, included on every edition, evaluates spoofing signals and authentication results.

Symptom: a question-mark icon next to the sender's name, a warning banner, quarantine.

Action: review Safety → Spoofing and authentication (Section 11).

4. Security Sandbox (Attachment Detonation)

On supported editions, attachments can be detonated in an isolated environment before delivery.

Symptom: delivery delayed by up to about 3 minutes, message sent to Spam or quarantined.

Action: review Security Sandbox rules (Section 15).

5. Links and External Images Scanning

Gmail can scan linked images and re-check URLs, including behind short links, at time of click.

Symptom: click warning, delayed link check, images not shown.

Action: review Safety → Links and external images.

6. Content Compliance / Routing Rules

An organization rule may quarantine, reject, or reroute the message based on content or metadata.

Symptom: unexpected quarantine, rejection, rerouting.

Action: review Compliance rules (Section 5, Step 5).

7. Quarantine

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

Symptom: message never appears in the Inbox but is visible under Manage quarantines.

Action: review and release if confirmed safe.

8. Bulk Sender Requirements / Rate Limiting

Large campaigns can trigger receiving-side throttling or Google's bulk sender requirements.

Symptoms: 4xx/4.7.x deferrals, partial delivery, delayed batches.

See Section 7 for Google Workspace's specific limits.

9. Email Denylist / Blocked Senders

A denylist entry, or a block rule, always overrides an allow-listing entry for the same sender.

Symptom: hard rejection regardless of other settings.

Action: check Email denylist and the approved-senders rule's block list (Section 5, Step 6).

10. External Gateway / Firewall / Proxy

The customer may have additional security infrastructure before or around Google Workspace.

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

See Sections 12-13.

7. Rate Limiting and Temporary Deferrals

Google Workspace Receiving Limits

Google Workspace applies receiving-side limits and sender requirements that exist independently of any allow list:

• Google Workspace documents an incoming rate of roughly 60 messages per minute per receiving account; consistently exceeding it can cause temporary delays or deferrals on inbound mail.

• If the simulation platform sends 5,000 or more messages a day to Gmail/Google Workspace addresses - common for a large-organization campaign - Google's bulk sender requirements apply to that traffic regardless of allow-listing: valid SPF and DKIM, a DMARC record with at least a policy of none, forward and reverse DNS (PTR) records, TLS for the connection, and, for messages Google classifies as marketing/promotional, one-click unsubscribe. Non-compliant mail can receive temporary (4.7.x) or permanent (5.7.x) rejection codes.

  (https://knowledge.workspace.google.com/admin/gmail/gmail-sending-limits-in-google-workspace)

Exceeding a limit or missing a requirement typically returns a deferral or rejection code to the sending platform rather than silently dropping the message - see Section 21 for reading those codes.

Recommended Solution

For large campaigns:

• avoid sending all emails simultaneously
• use the simulation platform's own throttling/scheduling if available
• monitor 4xx and 4.7.x deferral codes
• check Email Log Search (Section 21) for deferrals
• confirm the vendor's sending domain meets the bulk sender requirements above if the campaign is large
• identify whether failures are temporary or permanent before changing any allow-listing configuration

8. 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 Google Workspace tenant.

9. 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 Apps → Google Workspace → Gmail → Authenticate email in the Admin console, where a key can be generated (2048-bit recommended), the resulting TXT/CNAME record published at the given selector (the default is google._domainkey), and signing started once DNS has propagated. 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.

10. 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, Gmail's authentication checks can flag or quarantine the message even when the domain and IP are allow-listed elsewhere in this guide. The Approved Senders List with hide warnings enabled (Section 4) is one of the few mechanisms that can still let the message through cleanly 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.

11. Display Name Spoofing / Impersonation Protection

Google Workspace can identify emails where the display name or domain appears to impersonate an internal user, executive, or the organization's own domain.

Example: From: CEO Name  [email protected]

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

Symptoms

The user may see: a question-mark icon in place of the sender's photo, a warning banner (for example, flagging a display name that looks similar to someone the user knows, or a sender Gmail can't verify), or the message may be quarantined.

What to Check

1. Sign in to the Google Admin console.
2. Navigate to Apps → Google Workspace → Gmail → Safety → Spoofing and authentication.
3. Review whether protection is turned on for: domain spoofing (similar-looking domain names), employee name spoofing, spoofing of the organization's own domain, and unauthenticated email - and which action (warning, spam, or quarantine) is set for each.
4. These settings apply per organizational unit; confirm the pilot group's OU is selected before changing anything.
5. There is no separate “trusted sender” exception list specific to this page the way Section 4's approved senders list works - the practical fix for a phishing simulation is usually the approved-senders-with-hidden-warnings configuration in Section 4, since that is what suppresses the resulting banner, rather than turning off spoofing protection itself.

12. Mail Server / Secure Email Gateway

Google Workspace may not be the only email-security layer in the path.

A typical customer environment may look like: internet → secure email gateway or firewall → Google Workspace (Gmail) → end user. 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 Google Workspace (the aspmx.l.google.com family of records) and not to a third-party gateway first. If a gateway such as Proofpoint, Mimecast, or Barracuda sits in front of Google Workspace, it needs its own allow-list entry for the simulation sender/domain/IP, independent of everything configured in Sections 4-5.

13. 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.

14. Browser Plugins / Endpoint Security

Browser security extensions, antivirus, and EDR can interfere with the simulation - including Google's own Safe Browsing warnings in Chrome, 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.

15. Malware / Attachment Filtering

On supported editions, Security Sandbox can detonate attachments in an isolated virtual environment before delivery to check for malicious behavior.

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

Symptoms

• attachment delayed
• email sent to Spam or quarantined
• warning shown
• email rejected

16. Warning Banners & the Unauthenticated Sender Icon

Google Workspace does not have a persistent “External” tag on incoming mail the way some platforms do. What it has instead:

• a small question-mark icon in place of the sender's photo, shown when a message fails authentication.
• one of several warning banners - for example, flagging a display name that looks similar to someone the user knows, or a sender Gmail can't verify - driven by the Safety → Spoofing and authentication settings from Section 11.
• the “This message wasn't sent to Spam because of your organization's settings” banner, which appears specifically on mail that reached the inbox via the Section 4 approved-senders bypass.

17. External Images

Gmail routes and caches all images through Google's own proxy servers, and displays them automatically by default for every user - there is no per-domain, Admin-console-level image toggle to configure the way some platforms have.

Symptoms

The email reaches the Inbox but: the logo or tracking pixel does not load, images are hidden, or Gmail shows a “Display images below” prompt instead of loading them automatically.

Solution

This is a personal, per-mailbox Gmail setting, not a tenant-wide admin console toggle. In Gmail:

Settings (gear icon) → See all settings → General tab → Images

Set this to Always display external images. The alternative, Ask before displaying external images, requires a click on every new sender's first message before images load.

Note: even with Always display external images selected, Gmail's own documentation confirms that if a specific sender or message looks suspicious, images still won't load automatically for that message. This is a per-message override driven by the same spoofing/authentication signals covered in Section 11, not a separate setting to fix.

18. Symptoms When Whitelisting Is Not Done Properly

Issue	Possible Symptom
Sending IP not in Email allowlist	Deferral / delay / SMTP error
Sender/domain not in Approved senders list	Spam folder
Approved senders list missing “hide warnings”	Delivered, but shows a warning banner
Inbound Gateway not configured	Full spam and authentication checks apply
SPF failure	Authentication issue / Spam
DKIM failure	Authentication issue / Spam
DMARC failure	Quarantine / rejection
Spoofing detected	“?” icon / warning banner / quarantine
Content compliance rule match	Quarantine / rejection / rerouting
Bulk sender requirements not met	Temporary or permanent rejection (4.7.x / 5.7.x)
Rate limiting	Partial delivery / delay
Firewall block	Connection failure
Secure Email Gateway block	Quarantine / rejection
Proxy block	Link does not open
Security Sandbox detonation	Delayed delivery / Spam / quarantine
Browser plugin / Safe Browsing	Phishing warning / page blocked
Sender flagged as suspicious	Images not displayed automatically

19. Recommended Customer-Side Checklist

Sender Configuration

☐     Simulation sender email identified

☐     Sending domain identified

☐     Sending IP identified

☐     Tracking domain identified

☐     Landing page domain identified

Google Workspace Configuration

☐     Email allowlist configured (sending IP)

☐     Approved senders list configured with Bypass spam filters

☐     Approved senders list configured with Bypass spam filters and hide warnings

☐     Authentication required unchecked for the simulation entries

☐     Inbound Gateway reviewed (only if needed)

☐     Content compliance / routing rules reviewed

☐     Email denylist / blocked senders reviewed

☐     Safety settings (Attachments, Links & external images, Spoofing & authentication) reviewed

☐     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

☐     Warning banners checked

☐     External images checked

☐     Links tested

☐     Landing page tested

☐     Tracking tested

☐     Large-campaign sending rate and bulk sender compliance reviewed against Google Workspace limits

20. Troubleshooting

Case 1 - Email Does Not Arrive. Check: simulation platform delivery status, Email Log Search (Section 21), sending IP/domain reputation, Manage quarantines, Email denylist, Secure Email Gateway/firewall, SPF/DKIM/DMARC.

Case 2 - Email Arrives in Spam. Check: the Approved senders list's Bypass spam filters checkbox (Section 4), Email allowlist, Inbound Gateway, SPF/DKIM/DMARC, content compliance rules.

Case 3 - Email Reaches Inbox but Shows a Warning Banner. Check: the hide warnings checkbox in the Section 4 approved-senders rule, and the Safety → Spoofing and authentication settings (Section 11).

Case 4 - Email Is Quarantined. Check: which quarantine caught it (Manage quarantines), the matching content compliance rule or Safety action, the Security Sandbox verdict.

Case 5 - Some Users Receive It and Others Don't. Check: whether the pilot group's organizational unit differs from the one that was configured, per-user filters/blocked senders (Section 5, Steps 6-7), endpoint/security controls on that specific device.

Case 6 - First Batch Arrives but Later Emails Are Delayed. Check: the roughly 60-messages-per-minute receiving guideline (Section 7), the bulk sender requirements if the campaign is large, Email Log Search for deferrals, the vendor's sending pace.

Case 7 - Email Reaches Inbox but Link Does Not Work. Check: Safety → Links and external images, proxy, DNS filtering, firewall, a Safe Browsing warning, landing-page domain reachability.

Case 8 - Email Reaches Inbox but Images Do Not Appear. Check: the per-user Always display external images setting (Section 17), and whether Gmail is treating that specific sender as suspicious.

21. Email Log Search, Quarantine Review & 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 an Email Log Search

1. Sign in to the Admin console and go to Reporting → Audit and investigation → Email log search. On Enterprise Plus and Education Plus editions, the more advanced Security Investigation Tool's Gmail messages view offers additional filters and the ability to act on results directly.
2. Add search conditions for sender, recipient, subject, and/or date range.
3. Run the search and review each message's status - delivered, spam, quarantined, rejected, or bounced - along with the reason recorded for that state.
4. Where available, export results for the customer's records.

Reading the Message Headers

Open the message in Gmail, select the three-dot menu, and choose Show original - this displays the raw headers, plus a summary line for SPF, DKIM, and DMARC results.

Within the headers, the standard Authentication-Results field records the per-check verdicts (spf=pass/fail, dkim=pass/fail, dmarc=pass/fail) and which domain each check evaluated. For a large campaign hitting deferrals, the specific SMTP response code is usually the fastest way to isolate the cause — several point to a fix on the vendor's side rather than anything to reconfigure in the Admin console:

• 4.7.26 - unauthenticated mail rate-limited
• 4.7.28 - unusual sending rate detected
• 4.7.29 - missing TLS for a bulk sender
• 4.7.30 - DKIM authentication failed
• 4.7.32 - From header doesn't match the authenticated SPF/DKIM domain
• 4.7.40 - sending domain has no DMARC record or policy

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.

22. Security Sandbox & Advanced Safety Features - Licensing Tiers

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

Not every Google Workspace edition includes the same protection layers, so whether certain checklist items apply depends on what the organization is licensed for:

• Business Starter and the base Frontline/Education tiers - include core spam, phishing, and malware filtering, the Email allowlist and approved-senders mechanisms (Sections 3-4), and the full Safety settings (Sections 6, 11). Do not include Security Sandbox.

• Business Standard, Business Plus, Frontline Plus - add Security Sandbox (attachment detonation, Section 15).

• Enterprise Standard, Enterprise Plus - add Security Sandbox plus S/MIME encryption and the Security Investigation Tool for deeper log search and direct remediation (Section 21). Enterprise Plus additionally adds client-side encryption and enterprise data regions, which don't affect simulation delivery directly.

  \