Home/Questions/Email security and phishing/Email security with detonation
Email security and phishing

Is inbound email security (SEG) deployed with sandbox attachment detonation?

Detonation is the part of this question that separates a spam filter from an email security control, and it is the part most often assumed rather than enabled.

Verifiable from your tenant

What the carrier is actually asking

The carrier is asking whether inbound mail is filtered by a product that does more than reputation and signature checks: specifically, whether attachments are opened in an isolated environment to observe what they do, and whether links are evaluated at the time the user clicks rather than at the time the mail arrived.

Why it is underwritten

Attackers deliver payloads that are unknown at the moment of delivery and links that are benign when scanned and malicious ten minutes later. Detonation and time-of-click evaluation exist because static scanning was defeated systematically. Since email remains the primary delivery route for both business email compromise and ransomware, this is a control carriers weight heavily.

Where the answer lives in Microsoft 365, Entra ID, and Azure

In a Microsoft 365 estate this is directly measurable. The capability is licensed at a specific plan level and each component is switched on separately, so licence ownership does not imply protection.

PlatformWhere the setting livesWhat has to be true
Microsoft 365Safe Attachments policy in Defender for Office 365A policy exists, applies to all recipients, and its action is block or dynamic delivery rather than monitor
Microsoft 365Safe Links policy, including the setting for links in email and in Office documentsTime-of-click rewriting enabled, with click tracking on and user override disabled
Microsoft 365Safe Attachments for SharePoint, OneDrive, and TeamsEnabled, since files delivered through collaboration bypass the mail path entirely
Microsoft 365Anti-phishing policy with impersonation and spoof protectionConfigured with your executives and domains protected, rather than left at the default policy
Microsoft 365Mail flow connectors and the presence of a third-party gatewayWhere a gateway sits in front, its configuration is attested, and enhanced filtering is set so Microsoft still sees the true source address
Monitor mode protects nobody

Safe Attachments has a monitor action that delivers the message and records the verdict afterwards. It is useful during a pilot and it is not protection. The same is true of anti-phishing policies left in their default state, which apply a much lower bar than a configured policy.

What a defensible yes requires

  • Attachment detonation is enabled with a blocking action, covering every recipient rather than a pilot group.
  • Link protection evaluates at click time and covers collaboration platforms as well as mail.
  • Anti-phishing impersonation protection names your executives and domains.
  • Where a third-party gateway is used, mail routing is configured so both layers see accurate sender information.
  • Policy coverage is verified against the recipient list, since scoped policies leave populations uncovered silently.

How this answer goes wrong

The licence is present, the feature was enabled for a test group during deployment, and the scope was never widened. Everything reports as configured. The second failure is routing: a third-party gateway in front of Microsoft without enhanced filtering, which makes every message appear to originate from the gateway and degrades the platform's own spoof detection.

Frequently asked

Is the built-in Microsoft 365 filtering enough?

Exchange Online Protection handles spam and known malware. Detonation and time-of-click link protection require Defender for Office 365, which is a separate plan. Carriers asking this question mean the second.

Do we need a third-party gateway as well?

Not necessarily. A properly configured Defender for Office deployment answers this question. If you run both, configure the routing so neither layer is blinded by the other.

What about internal mail?

Internal-to-internal messages from a compromised mailbox are a real attack path, and several protections apply only to inbound external mail by default. Worth checking, since compromised-account phishing is the most convincing kind.

How do we evidence this?

Export the policy configuration and the recipient scope. The scope is the part that matters and the part a screenshot of the policy list does not show.

Related questions

Stop answering this from memory

Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.

Assess your posture