The report landed in my queue at 07:40 on a Tuesday, forwarded by someone in accounts payable. A project manager at a three-year supplier had replied mid-thread with updated bank details for an open invoice. I pulled the headers before I read the body: SPF pass, DKIM pass, DMARC pass, sender IP address inside the supplier's normal range, no link, no attachment.
The gateway's clean verdict was understandable: the message carried the technical signals of a legitimate supplier conversation. The supplier's mailbox had been compromised weeks earlier, and the fraudulent message inherited every trust signal the real conversation had built.
I keep getting asked some version of the same question by SecOps leaders and detection engineers: we pay for a secure email gateway, so why is phishing still the biggest line in our triage queue?
I've run triage behind Proofpoint and behind Defender for Office 365. My position: treat the gateway as the first decision, not the final verdict. The most damaging phishing cases often sit outside what it can evaluate, especially BEC, compromised-account abuse, and campaigns whose signals only emerge after delivery.
In brief:
- A secure email gateway reduces exposure to spam, known-malicious attachments and URLs, and some impersonation or anomaly patterns before delivery. In the environments I've worked in, mature filters have removed most commodity threat volume before an analyst ever sees it.
- SPF, DKIM, and DMARC validate that a message is authorized to use, or cryptographically associated with, the claimed sending domain. They don't establish that the domain, mailbox, or business request is trustworthy, which is how compromised vendor accounts and text-only BEC reach triage clean.
- Links scanned clean at delivery can be weaponized after the gateway has already decided.
- Post-delivery defense needs message remediation, user reporting with campaign clustering, click analysis for URL-based threats, and reply-chain and mailbox-rule signals for the BEC cases that never involve a click.
The orthodoxy: a gateway means email is covered
A traditional secure email gateway is an MX-routed filter that inspects inbound mail before delivery, blocking spam and malware and checking URLs using reputation, signatures, sandboxing, and Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks. In cloud environments, many platforms also add API integrations for post-delivery monitoring.
A delivered message has passed the controls that applied to it at that point in mail flow; not every message exercises every mechanism. I treat the gateway as the first decision point, not the whole email-security program: it reduces exposure before delivery, and it does that well against known-bad and signature-detectable threats.
Post-delivery telemetry, remediation, and incident response handle the messages whose risk only becomes visible later. Among the small fraction of malicious messages that reach the inbox, the highest-impact cases are often the ones that lacked a decisive pre-delivery signal: a compromised supplier account, a convincing lookalike domain, a thread hijack, or a URL whose destination changed later.
What a secure email gateway actually catches
The gateway is strongest against bulk threats that are known-bad or detectable by signature. Its value is the volume of commodity mail it removes before an analyst ever has to see it.
Known-bad, bulk, and signature-detectable threats
Enterprise gateways combine public blocklists, proprietary reputation data, and sender scoring, and sandbox supported attachment types, including password-protected documents and Zip files, before delivery.
In my own testing, catch rates fall sharply when the sample isn't known. Customized malware disguised as legitimate documents has produced inconsistent sandbox results, and independent sandbox testing has likewise shown materially weaker results against customized samples. First-seen URLs or file hashes give a gateway little prior history to score.
What walks past it
Trusted senders can inherit signals the gateway expects to judge, payload-less social engineering removes those signals entirely, and links can change behavior after the gateway has already decided.
Lookalike domains and account-takeover from trusted senders
Operationally, an SPF, DKIM, and DMARC pass tells me a message is authorized to use, or cryptographically associated with, the claimed sending domain. It doesn't tell me the domain, mailbox, or business request is trustworthy. In incidents I've handled, attacker-owned lookalike domains have carried valid authentication records because the attacker controlled their DNS: authentication validates domain control and alignment, not business legitimacy.
I've also seen attackers use legitimate email services to send fully authenticated messages from domains they control, a pattern reflected in Microsoft campaign reporting. Reputation engines have little history for a newly registered domain, while account takeover uses an established one.
The BEC attack chain often begins with phishing or password spraying, followed by inbox-rule manipulation, internal phishing, and email-thread hijacking. I've investigated lateral phishing sent from real employee accounts that succeeded without being reported to IT or security.
In several MX-routed deployments I've operated, internal mail didn't traverse the external gateway path, which made native tenant controls and post-delivery investigation essential for catching lateral phishing like this.
In Microsoft 365 environments, I also account for Direct Send abuse. Attackers can exploit a trusted, unauthenticated mail-flow path meant for devices like printers and scanners to deliver messages that appear to originate internally, which can change how downstream authentication and anti-phishing controls evaluate the message. Talos documented this abuse and recommends restricting or disabling Direct Send where it isn't required.
Payload-less BEC and text-only social engineering
A text-only email gives the sandbox nothing to detonate and the signature engine nothing to match. Gateways and cloud email filters can score BEC as clean because it carries none of the malicious payload signals those engines were built to detect.
Microsoft's 2025 Digital Defense Report characterized BEC as low-volume but high-impact in its data: BEC was 2% of observed threats but 21% of attack outcomes, against 16% for ransomware. That doesn't mean BEC is easy to catch at delivery; it means message volume is a poor proxy for financial risk.
I've investigated messages from legitimate domains that passed SPF, DKIM, and DMARC with no links or attachments, asked recipients to reply-all to confirm an order, and turned out to be mailbox enumeration for follow-up BEC. Gift-card fraud and simple requests for contact also remain common BEC patterns in my queue. My accounts-payable case fit the pattern: the first message in the hijacked thread asked a question, and the bank details came two replies later.
Links weaponized after delivery
A link that's benign at delivery can become malicious later. Time-of-click protection catches some of that, but coverage depends on the effective policy, URL format, mail type, and supported application path. Microsoft documents several cases where Safe Links protection is limited or unavailable.
I've also investigated redirect chains that passed through trusted providers' URL-rewriting services, so the rewritten link produced by a security product became part of the disguise. Even when the gateway rechecks at click time, I've seen destinations refuse to show themselves to a crawler: CAPTCHA-gated pages and regenerating canvas elements designed to frustrate automated inspection.
QR-code lures reduce the recipient's ability to inspect the destination before opening it and can shift the click to an unmanaged mobile device. Whether a gateway catches the code itself depends on the product and policy, and I still see them in post-delivery investigations.
Why the SOC still owns the inbox
A message filter makes its decision at delivery. That decision needs revisiting when new evidence arrives: a click, a redirect chain that resolves differently, or a suspicious sign-in.
Post-delivery is where the phishing that matters lives
In my last SOC, I pulled a month of confirmed-malicious phishing tickets and sorted them by what the gateway had done with each message. Nearly all had been delivered clean, because the evidence arrived later: a click, a redirect chain that resolved differently than at scan time, or a sign-in from an autonomous system number (ASN) the user had never touched.
I've also seen advanced threats sit inside Microsoft 365 inboxes for minutes before detection while some recipients clicked almost immediately after delivery.
Identity telemetry is often where credential phishing and adversary-in-the-middle (AiTM) investigations become visible, though malware, fraud, and SaaS-abuse cases need other evidence too.
I treat phishing triage and identity threat detection as one workflow for credential cases. Device-code phishing data in the same Microsoft Digital Defense Report cited earlier shows 93% of events occurred in the second half of the reporting year. Legitimate codes and tokens can let this activity evade traditional phishing controls entirely.
I've also seen attackers get around push-based multi-factor authentication (MFA), though that experience is naturally biased toward organizations that suffered a breach. None of that telemetry passes through the gateway; it lives in Entra sign-in logs, Identity Protection logs, and the Unified Audit Log, where I start an AiTM investigation.
I now write hunts against EntraIdSignInEvents rather than the legacy AADSignInEventsBeta table, which Microsoft is replacing.
What to run after the gateway
The post-gateway stack needs click correlation and retro-scanning for URL-based threats, reply-chain and mailbox-rule signals for BEC that never involves a click, and a user-report pipeline with explicit ownership. Together, those controls turn late-arriving evidence into a second decision on mail the gateway already delivered.
Click correlation in Microsoft 365
I've assembled the post-gateway stack from capabilities available inside Microsoft 365 (M365) and Google Workspace before buying anything else. In the Defender for Office 365 data available to my workflows, I find the click in UrlClickEvents, use UrlChain for the full redirect path, and use IsClickedThrough to identify users who clicked past a warning.
Across several tenants, clicks from Drafts and Sent items couldn't always be joined to email tables on NetworkMessageId, a limitation documented in the UrlClickEvents table, so I don't build a playbook that assumes full correlation.
For investigations, I start by correlating Safe Links click events with inbound messages Defender already classified as phishing or malware, then extend the search to user-reported and post-delivery-reclassified messages, since a clean delivery verdict is often the case I'm trying to explain. Validate field availability, action values, and tenant-specific schema behavior before operationalizing anything like this:
let RelevantClicks = UrlClickEvents
| where Workload == "Email"
| where ActionType == "ClickAllowed" or IsClickedThrough != "0"
| project ClickTime = Timestamp, NetworkMessageId, ReportId,
ActionType, IsClickedThrough, Url;
RelevantClicks
| join kind=inner (
EmailEvents
| where EmailDirection == "Inbound"
| where ThreatTypes has_any ("Phish", "Malware")
| project DeliveryTime = Timestamp, NetworkMessageId,
SenderFromAddress, RecipientEmailAddress
) on NetworkMessageId
| project ClickTime, DeliveryTime, ReportId, NetworkMessageId,
SenderFromAddress, RecipientEmailAddress,
ActionType, IsClickedThrough, Url
Investigating BEC that never involves a click
Click telemetry is essential for URL-based credential theft, but most of my highest-impact BEC cases involve no link at all. Invoice and payment-change requests, payroll diversion, gift-card fraud, and reply-chain hijacking all move through text alone.
For those, I don't wait on click data. I hunt New-InboxRule and Set-InboxRule operations that move mail to Archive, RSS, or Conversation History as a persistence tell, review external forwarding and reply-chain context, and route any request to change payment instructions through verification outside the email thread entirely.
Retro-scanning in Microsoft 365 and Google Workspace
Retro-scanning is the platform pulling back what it later judged malicious. In Microsoft 365, I use zero-hour auto purge (ZAP) for Exchange Online cloud mailboxes; it doesn't protect on-premises mailboxes, its outcome depends on the applicable anti-spam policy, and allowlists or transport rules can override it, behavior covered in Microsoft ZAP documentation.
I track the results as Phish ZAP and Malware ZAP in EmailPostDeliveryEvents, and the available search window has bitten me in practice: mail reported on Monday about Friday sometimes required a manual hunt, since the action window and the hunting-data retention aren't the same thing.
Google Workspace documents that unopened messages detected post-delivery as malware or phishing can be automatically reclassified and removed; if a recipient already opened or interacted with the message, an administrator may need to remove it manually. In one environment I worked, shared finance mailboxes needed separate remediation procedures, so validate post-delivery coverage for collaborative and delegated-mailbox workflows before relying on automation.
Owning the user-report pipeline
The user-report pipeline requires more than a once-daily abuse@ mailbox review. In Microsoft 365 deployments I've run, the built-in Report button routed to a reporting mailbox and the User reported tab. In Defender for Office 365 Plan 2 environments, a report could trigger an Automated Investigation and Response (AIR) workflow when the alert policies were configured, though message-cluster remediation still needed explicit ownership.
In my Google deployments, the Report Phishing button fed Google's filters and Alert Center, while an internal security-mailbox workflow required separate configuration. Only a minority of user reports turn out to be verified as malicious in my queues, so I cluster by structural similarity before a human opens anything: message-grouping tools can collapse 100 recipients of one lure into one alert.
The internal target I set when I rebuilt this pipeline was that every reporter gets a verdict back within the shift, and every confirmed hit runs a sign-in review alongside the click query above.
For credential-phishing cases, the click and the sign-in are usually more actionable than the original gateway verdict. Start there this week, then measure how long a reported phish sits before anyone opens it.
Frequently asked questions about secure email gateways
What is a secure email gateway?
A secure email gateway is a filter in the MX path that inspects inbound mail before it reaches the mailbox. It uses sender reputation, malware signatures, attachment sandboxing, URL rewriting, and SPF/DKIM/DMARC checks, and makes its decision when the message arrives. Anything it passes has already beaten every one of those checks at that moment, which is why post-delivery detection exists as a separate discipline.
What does a secure email gateway not catch?
Threats without a known-bad signal at delivery: attacker-registered lookalike domains with valid authentication, compromised vendor or internal accounts, text-only BEC, links weaponized after scanning, and QR-code lures that arrive as images. These are gaps in signal, not a failure of every gateway control.
Do you still need a SEG with Microsoft 365 or Google Workspace?
Fewer teams do, and the decision hinges on architecture cost as much as catch rate. Routing mail through a third-party gateway before Microsoft 365 requires careful connector configuration to preserve authentication evaluation, per Microsoft connector guidance. I've also seen it interfere with DMARC aggregate reporting, documented in Microsoft DMARC configuration guidance. For cloud-native M365 or Google Workspace environments, evaluate native protections and post-delivery capabilities first, and add a third-party gateway only when a measurable requirement justifies it.
How do you detect phishing that bypasses the gateway?
Start with the message and follow the evidence that matches the attack type. For URL-based credential phishing, correlate UrlClickEvents with EmailEvents, review EmailPostDeliveryEvents for ZAP actions, and after a confirmed click, check Entra sign-in and session data for signs of AiTM activity. For text-only BEC, don't wait for a click: hunt inbox-rule changes, unusual sender context, and external forwarding instead.