Direct Send abuse exposes the limits of email trust controls

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Abnormal AI's blog post: Microsoft 365 Direct Send abuse lets attackers imitate internal email without logging in, and perimeter email controls miss it.

Why it matters: IAM and security teams need to treat mail trust as an identity problem, because internal-looking traffic can bypass controls that assume authentication and source reputation are enough.

Context

Direct Send is a Microsoft 365 email path that was built for devices and applications that need to send mail without a normal authenticated user session. That design creates a governance gap when organisations let internal-looking messages inherit trust simply because they arrive from Microsoft infrastructure or from known internal IP ranges.

The control failure is not only about phishing content. It is about where trust is assigned, how mail flow exceptions are written, and whether email security tooling can still inspect messages that originate inside the tenant boundary. When the policy model assumes internal equals safe, Direct Send abuse becomes a low-friction impersonation channel.

Abnormal AI says the abuse has expanded beyond an initial legal-sector concentration into multiple industries, which means the underlying trust model is now the problem, not a niche campaign pattern.

Key questions

Q: What fails when Microsoft 365 Direct Send is allowed to inherit internal trust by default?

A: The failure is that delivery provenance starts acting like authentication. Once internal-looking mail is trusted because it comes from Microsoft infrastructure or an approved internal range, attackers can impersonate users without a login. That breaks the assumption that only authenticated senders can generate trusted internal communications and creates a policy gap, not just a spam problem.

Q: Why does Direct Send abuse create so much risk even without stolen credentials?

A: It works because the attacker does not need to compromise a mailbox to gain credibility. The message arrives through a path recipients already trust, so the adversary can use brand, role or internal context to trigger clicks and responses. That makes the risk structural: trust is granted before identity is verified.

Q: What are the signs that email trust controls are failing?

A: Repeated replies to suspicious requests, high forward rates, weak reporting discipline, and inconsistent escalation around vendor changes are all warning signs. If analysts see lots of noise but few confirmed reports, attackers may be succeeding because the organisation is not distinguishing routine messages from risky ones quickly enough.

Q: Should organisations disable Direct Send or govern it more tightly?

A: Most organisations should govern it more tightly first, because some internal devices and applications still depend on the feature. The practical choice is to restrict who can use it, document every exception and add tenant-native inspection and identity-based monitoring. Blanket disablement may be ideal in some environments, but it is not always operationally realistic.

Technical breakdown

How Direct Send turns infrastructure trust into an impersonation channel

Microsoft 365 Direct Send allows unauthenticated systems such as printers or applications to send mail through Microsoft infrastructure. That convenience becomes a control gap when recipients and downstream filters infer legitimacy from the transport path rather than from a real authenticated identity. Attackers can spoof internal-looking addresses, route messages through Microsoft’s SMTP relay, and land in inboxes with the appearance of trusted internal mail. The key failure is that delivery infrastructure and identity assurance are being conflated. Practical implication: email trust decisions should not rely on origin infrastructure alone.

Practical implication: Separate transport trust from identity trust in mail policy and inspection logic.

Why SPF, DKIM and DMARC do not fully solve Direct Send abuse

SPF, DKIM and DMARC are authentication signals, but Direct Send often returns ambiguous results such as none, fail or temperror because the sender is not behaving like a standard authenticated mailbox. That does not automatically stop delivery when business rules allow internal or Microsoft-routed traffic to pass. Rule-based tooling then has to decide with partial evidence, which is exactly where attackers want the control boundary to sit. The result is not a broken standard, but a standards-only model applied to a context it was never meant to govern. Practical implication: detection logic must handle ambiguous authentication outcomes as risk signals, not as noise.

Practical implication: Treat none, fail and temperror outcomes as investigation triggers when mail claims internal origin.

Why static indicators fail when attackers remove the usual artifacts

Direct Send campaigns often strip away the signals legacy tools expect, using blank bodies, encrypted attachments, QR codes and obfuscated files. That forces scanners that depend on URLs, known malicious language or payload signatures into a blind spot. When the message itself is thin and the delivery path looks trusted, traditional secure email gateways have little to anchor a decision on. This is why behavioural context and tenant-native inspection matter more than perimeter heuristics. Practical implication: build detection around communication patterns, attachment behaviour and tenant visibility, not just content signatures.

Practical implication: Base email detection on behaviour and tenant context instead of static indicators alone.

Threat narrative

Attacker objective: The attacker wants to use trusted Microsoft-delivered mail to bypass email controls, win user trust and harvest credentials or execute follow-on compromise.

1. Entry occurs when attackers abuse Microsoft 365 Direct Send to send mail that appears to come from internal users or internal systems without any stolen credentials.
2. Escalation follows when recipients trust the internal-looking message and interact with QR codes, encrypted attachments or cloned login pages that drive credential capture.
3. Impact is achieved when harvested credentials or user action provide a foothold for broader phishing, account access or follow-on compromise across the organisation.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Direct Send abuse is a trust-boundary failure, not just a phishing variant. The attack works because organisations still let delivery path substitute for identity assurance. Once mail routed through Microsoft infrastructure is treated as inherently internal, the email programme stops testing whether the sender is actually authenticated or merely convenient to trust. The practitioner lesson is that internal-looking mail needs governance, not just filtering.

Perimeter email security is structurally misaligned with tenant-native abuse. Secure email gateways were designed to inspect inbound traffic before it reaches the cloud tenant, but Direct Send abuse can live inside the Microsoft 365 trust zone that those tools never fully see. That means the blind spot is architectural, not a tuning issue. The implication is that inspection must move closer to the identity and mail flow controls that decide whether a message is accepted at all.

Static phishing indicators are no longer a sufficient detection model. Direct Send campaigns remove the very artifacts many legacy tools depend on, such as obvious URLs, malicious language or simple attachment signatures. When the message is minimal and the transport looks legitimate, the detection problem shifts from content matching to behavioural anomaly analysis. That is a material change in how email security has to be governed.

Internal email trust now behaves like a privileged access control problem. The organisation is effectively granting a high-trust delivery path to messages that may be attacker-controlled, which makes mail trust closer to entitlement governance than to simple spam filtering. That is a useful concept because it forces security teams to ask who can originate internal-looking communications, under what conditions, and with what inspection. Practitioners should manage internal mail trust as an access decision, not as a formatting problem.

Identity trust in email needs to be continuously revalidated across the communication chain. Internal impersonation, ambiguous authentication outcomes and tenant-local delivery create a compound risk that crosses mail transport, user behaviour and identity verification. The signal here is that email security is no longer separable from identity governance and access policy. Teams that still treat these as disconnected domains will keep missing the abuse pattern.

What this signals

Internal-looking email has to be governed like an access path. Direct Send shows that mail trust is not simply a filtering problem. When a message can be delivered through a legitimate cloud relay without a normal authenticated sender session, the organisation needs controls that decide who may originate trusted-looking communication and under what conditions.

Identity-aware inspection is becoming more important than perimeter heuristics. The practical lesson for email programmes is that transport provenance and message content are no longer enough on their own. Teams need tenant-native visibility, behavioural analysis and explicit policy ownership for any mail flow that is treated as internal by default.

For practitioners

• Tighten Direct Send exceptions Review every rule that allows unauthenticated internal-looking mail from known IP ranges or Microsoft-routed sources. Remove broad allowlists, narrow the approved sender scope, and require a documented business owner for any exception that remains.
• Treat ambiguous authentication results as risk signals Flag SPF, DKIM and DMARC outcomes such as none, fail and temperror when the message claims internal origin or carries privileged language. Route those messages into higher-scrutiny workflows instead of letting default trust decisions handle them.
• Shift detection from signatures to behaviour Look for blank bodies, encrypted attachments, QR codes, self-addressed mail and unusual internal impersonation patterns. These are the cues that replace static indicators when attackers deliberately remove obvious phishing artifacts.
• Move inspection closer to tenant-native controls Validate that your mail security stack can see and act on Direct Send traffic inside Microsoft 365, not only on messages entering from the internet. If it cannot, define compensating controls at the tenant and identity layers.
• Reclassify internal email trust as a governance control Assign explicit ownership for internal mail trust rules, review them alongside identity and access policies, and measure which sources are allowed to present as internal without interactive authentication.

Key takeaways

• Direct Send abuse exposes a governance gap where delivery infrastructure is treated as proof of trust, even when no authenticated user session exists.
• The attack succeeds because legacy email controls depend on static indicators and perimeter inspection that Direct Send traffic can evade.
• Security teams should narrow Direct Send exceptions, treat ambiguous authentication results as risk signals and move trust decisions closer to tenant-native controls.

Key terms

• Direct Send: Direct Send is a Microsoft email delivery method that can allow messages to be routed in a way that looks internal or trusted to some controls. Security teams need to understand that trusted routing does not automatically mean trusted content, especially when adversaries are abusing the path.
• Mail flow exception: A mail flow exception is a rule that allows certain messages to bypass normal filtering because they come from a presumed safe source. These exceptions are necessary for business operations, but they become dangerous when they are based on broad network or transport assumptions rather than identity evidence.
• Authentication ambiguity: Authentication ambiguity occurs when security checks do not return a clear pass or fail state, leaving the system with incomplete assurance. For email programmes, outcomes like none, fail or temperror should be treated as risk signals, not as harmless uncertainty, because attackers can operate inside that grey zone.
• Impersonation: Impersonation is a controlled administrative action that lets an authorised operator assume a user context for debugging or support. In a well-governed setup it preserves audit logging, limits exposure of credentials, and keeps production authentication separate from local troubleshooting.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.