Direct Send abuse exposes the limits of email trust controls

At a glance

What this is: This is an analysis of Microsoft 365 Direct Send abuse and how it lets attackers impersonate internal mail without authenticated access.

Why it matters: It matters because IAM, email security, and identity governance teams need controls that do not rely on where a message appears to come from or on static indicators alone.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Abnormal AI's analysis of Microsoft 365 Direct Send abuse

Context

Direct Send abuse is a Microsoft 365 trust problem, not a mailbox takeover problem. Attackers exploit a convenience feature that allows internal devices to send email without normal authentication, then route messages through Microsoft infrastructure so they look internally sourced.

For IAM and email governance teams, the important issue is that trust decisions are being made on origin assumptions, internal IP allowlists, and weak message authentication signals. That combination creates a control gap when legitimate infrastructure is used to impersonate legitimate identities.

Key questions

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. Tighten internal mail exceptions, validate tenant-side telemetry, and investigate messages that appear internal but lack normal sender behaviour. The safest control is one that checks behaviour and identity context, not only transport path.

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. Perimeter gateways may never see it clearly, and static indicators such as URLs or body text may be missing. That leaves rule-based tools with too little evidence to classify the message correctly.

Q: What do organisations get wrong about internal email trust?

A: They often assume internal-looking delivery means the sender is trustworthy. In Direct Send abuse, the opposite is true: the message may be unauthenticated, spoofed, and still delivered through trusted infrastructure. Organisations should base trust on identity evidence and behavioural context, not just mail origin.

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.

Technical breakdown

Direct Send and internal email impersonation

Microsoft Direct Send exists to let internal devices and applications send mail without standard credentials. That design works only when the sending source is truly controlled and the receiving organisation trusts the internal IP path. In abuse scenarios, threat actors spoof internal addresses and push mail through Microsoft’s SMTP relay so the message inherits the appearance of legitimate enterprise traffic. The receiving system may see no obvious login event, only an email that fits existing delivery rules. This is a governance failure because the trust boundary is mail flow, not identity proof.

Practical implication: review any mail flow rule that treats internal-looking traffic as trustworthy just because it comes from Microsoft-hosted infrastructure.

Why SPF, DKIM, and DMARC become ambiguous

Direct Send abuse often produces authentication outcomes such as none or temperror rather than a clear fail. Those states are not the same as a verified legitimate identity, but many rule-based systems treat them as inconclusive rather than hostile. Attackers benefit because the message can avoid the crisp signal that older filters depend on. When the campaign also uses blank bodies, encrypted attachments, or QR codes, static indicators become even less useful. The result is a detection environment built for obvious phishing, not for infrastructure-level impersonation.

Practical implication: tune detection logic to treat ambiguous authentication results as risk signals when they combine with internal impersonation or unusual sending patterns.

Why perimeter email security misses Direct Send

Secure email gateways inspect inbound traffic at the edge, but Direct Send abuse can enter through Microsoft 365 pathways that never pass through those external checkpoints in a useful way. That means the control plane is looking in the wrong place. Because the messages may also appear to originate from trusted Microsoft infrastructure, perimeter tools can safelist them or classify them as benign. Behavioral context becomes more important than content scanning, especially when attackers use spoofed executives, self-addressed mail, or attachment-based lures that contain no visible payload.

Practical implication: extend inspection into the tenant and validate internal-like messages against historical communication behaviour, not just gateway rules.

Threat narrative

Attacker objective: The attacker aims to exploit internal trust so that a message delivered through legitimate Microsoft infrastructure can drive credential theft or broader phishing success.

1. Entry occurs when an attacker spoofs an internal address and routes the message through Microsoft SMTP relay without using stolen credentials or a mailbox login.
2. Escalation follows when the recipient opens a QR code, encrypted attachment, or impersonated system notice that bypasses static filtering and steers them toward credential theft or malicious interaction.
3. Impact lands when the attacker uses the trusted internal-looking message to harvest credentials, gain broader account access, or seed a wider phishing campaign inside the organisation.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Static email controls are structurally mismatched to infrastructure-level impersonation. SPF, DKIM, DMARC, and signature-based filtering were built to sort obvious external abuse from normal mail. Direct Send campaigns exploit the fact that these controls often return ambiguous rather than definitive results, which leaves legacy tooling without a clear decision point. Practitioners should treat ambiguity as a risk state, not a safe default.

Internal impersonation now behaves like an identity governance problem. The attacker is not simply sending email, they are borrowing the organisation's trust model to impersonate executives, helpdesk staff, and even the recipient. That makes sender identity, tenant behaviour, and message context part of the same control surface. Security teams need to govern who can appear internal, not just who can log in.

Direct Send abuse creates a hidden identity blast radius. Once an attacker can piggyback on legitimate infrastructure, a single spoofed message can bypass multiple layers of perimeter logic and reach users at scale. The danger is not only delivery, but the downstream effect on user trust, helpdesk exposure, and follow-on account compromise. The practical conclusion is that message path and identity context must be analysed together.

Identity controls for email need to move from provenance to behaviour. The article shows that infrastructure provenance is no longer enough when attackers can manufacture it. A named concept emerges here: trusted-path impersonation, which describes abuse of legitimate transport to simulate internal identity. That concept matters because it changes the question from 'is this mail internal?' to 'does this mail behave like our internal population?'.

From our research:

• 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.
• For a broader lifecycle view, see The 52 NHI breaches Report for the patterns that emerge when trust assumptions outlive control design.

What this signals

Trusted-path impersonation: Direct Send abuse shows that attackers do not need to break authentication if they can borrow the organisation's internal delivery trust. Teams should expect more abuse of legitimate cloud transport, especially where controls still assume that internal routing is equivalent to sender legitimacy.

The practical signal for programmes is that mail governance, IAM, and tenant telemetry can no longer be managed as separate silos. If your organisation still treats perimeter email controls as sufficient, the Direct Send pattern will keep exposing gaps between transport trust and identity assurance.

The next control shift is toward behavioural verification inside the tenant, with message context, sender history, and user relationship patterns taking priority over static indicators. That change aligns with the direction of modern identity security, where provenance alone no longer answers the trust question.

For practitioners

• Rework internal-trust mail rules Remove blanket allowlisting for internal-looking traffic that arrives through Microsoft-hosted paths. Tie exceptions to validated device identity, sender behaviour, and tenant-specific message patterns rather than to source IP alone.
• 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. Build this into triage so ambiguity is investigated instead of ignored.
• 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.
• Validate QR and attachment handling paths Test how your environment handles QR-code PDFs, encrypted files, and blank-body messages that bypass content filters. Confirm that tenant-side controls still inspect and quarantine these payloads after delivery.

Key takeaways

• Direct Send abuse turns Microsoft 365 trust assumptions into an attack surface, letting spoofed internal mail bypass the controls many teams still rely on.
• The scale of the problem is broadening across industries, which means this is now a governance issue rather than an isolated phishing trick.
• Practitioners need tenant-side behavioural verification, tighter mail exceptions, and better identity context to stop messages that look internal but are not trustworthy.

Key terms

• Direct Send: Microsoft 365 Direct Send is a mail flow feature that lets internal devices and applications send email without standard user authentication. It is useful for operational systems, but it also creates a trust boundary that can be abused when organisations allow internal-looking traffic too broadly.
• Trusted-path impersonation: Trusted-path impersonation is abuse of legitimate infrastructure to make malicious communication look internal and safe. In practice, the attacker does not need to own a mailbox if they can borrow the platform's delivery trust and bypass controls that equate origin with legitimacy.
• 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.
• Tenant-side telemetry: Tenant-side telemetry is the activity and message data available inside the cloud email environment rather than only at the perimeter. It is essential for spotting internal-looking abuse because it shows sender patterns, recipient relationships, and abnormal behaviour that external gateways may never observe.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: Direct Send abuse and how attackers spoof internal mail through Microsoft 365. Read the original.