Notifications
Clear all
Topic starter
27/06/2026 2:01 pm
TL;DR: Microsoft 365 Direct Send abuse lets attackers spoof internal-looking email without stolen credentials, bypassing perimeter email controls and confusing SPF, DKIM, and DMARC checks, according to Abnormal AI. The attack succeeds because legacy trust models assume internal-looking mail is safe, even when it is routed through Microsoft infrastructure.
NHIMG editorial — based on content published by Abnormal AI: Direct Send abuse and how attackers spoof internal mail through Microsoft 365
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams handle direct-send abuse in Microsoft 365?
A: Treat Direct Send abuse as an identity and trust problem, not just a mail-filter problem.
Q: Why does Direct Send abuse bypass so many email defenses?
A: It bypasses many defenses because the message can travel through legitimate Microsoft infrastructure and resemble trusted internal mail.
Q: What do organisations get wrong about internal email trust?
A: They often assume internal-looking delivery means the sender is trustworthy.
Practitioner guidance
- Rework internal-trust mail rules Remove blanket allowlisting for internal-looking traffic that arrives through Microsoft-hosted paths.
- Treat ambiguous authentication as a signal Escalate messages with none, fail, or temperror outcomes when they also show internal impersonation, self-addressed recipients, or unusual attachment formats.
- Shift detection toward tenant behaviour Use Microsoft 365 telemetry and historical communication baselines to identify messages that look internal but diverge from normal sender relationships, timing, and attachment behaviour.
What's in the full article
Abnormal AI's full research covers the operational detail this post intentionally leaves for the source:
- Campaign-level examples of Direct Send abuse across legal and other sectors, including how attackers structure internal impersonation.
- Detection logic details for SPF, DKIM, and DMARC ambiguity and how the vendor correlates these signals with message behaviour.
- Microsoft 365 API-based remediation workflow details for quarantine and post-delivery removal.
- Forensic context examples that help SOC teams trace self-addressed mail, spoofed VIPs, and QR-based lures.
👉 Read Abnormal AI's analysis of Microsoft 365 Direct Send abuse →
Direct Send abuse and the governance gap teams are missing?
Explore further
27/06/2026 3:35 pm
Direct Send abuse is a trust-boundary failure, not a phishing variant. The core problem is that organisations equate internal delivery paths with trustworthy identity, even when no authenticated sender exists. That assumption breaks when Microsoft infrastructure becomes the transport for impersonation. The implication is that mail trust can no longer be inferred from delivery origin alone.
A few things that frame the scale:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
- Another 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which shows that identity governance gaps are already operational, not theoretical.
A question worth separating out:
Q: Who is accountable when spoofed internal mail reaches users?
A: Accountability sits with the team that owns messaging trust controls, identity governance, and tenant mail rules. If internal delivery paths are being treated as safe without validation, then the control gap is organisational, not just technical. Email security, IAM, and platform teams all share responsibility for the trust boundary.
👉 Read our full editorial: Direct Send abuse exposes the limits of email trust controls
