Microsoft Direct Send creates spoofing risk for application mail

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Proofpoint's blog post: Microsoft Direct Send creates spoofing exposure because unauthenticated application mail can travel through trusted Exchange Online infrastructure.

Why it matters: IAM, PAM, and NHI teams should treat application mail flows as governed identity pathways, because unauthenticated relay can undermine trust, DMARC alignment, and fraud controls.

Context

Microsoft Direct Send is an unauthenticated outbound mail path for devices and applications that cannot use a normal user mailbox or credential flow. That convenience is useful for scanners, printers, and line-of-business systems, but it also weakens the trust model because the sending source is not proving identity in the way modern email security expects.

The governance problem is that non-human mail often sits outside the same controls used for human messaging, even though it can reach the same internal users and external recipients. In practice, this creates an identity boundary problem for NHI governance, email security, and fraud prevention, because application-generated mail can become a trusted delivery channel without strong sender assurance.

Key questions

Q: What breaks when application mail uses Direct Send without authentication?

A: The sender identity control breaks, because the message can arrive through trusted infrastructure without proving that the application or device was authorised to send it. That weakens anti-spoofing checks, confuses recipients, and creates an exception path that attackers can abuse for phishing or fraud. The operational fix is to treat the mail flow as a governed non-human identity.

Q: Why does unauthenticated mail relay increase spoofing risk?

A: Because the receiving systems are validating delivery path more than sender identity. If a platform accepts mail without proving who initiated it, attackers can exploit the same path to impersonate internal systems or brands. That makes phishing and fraud easier to scale, especially when recipients trust messages that appear to come from familiar infrastructure.

Q: How can security teams tell whether application mail is properly governed?

A: Look for a single approved relay, documented ownership, authenticated sending sources, signed messages, and the ability to disable a sender centrally. If application mail is still sent from scattered exceptions with no audit trail, the governance model is weak. Properly governed non-human mail should be measurable, revocable, and visible end to end.

Q: Should organisations replace Direct Send with a secure relay for all non-human mail?

A: Where messages matter for brand trust, internal deception risk, or compliance, yes. A secure relay does not just change a technical route, it establishes sender accountability, policy enforcement, and consistent signing for application and device mail. Direct Send may remain convenient, but convenience is a poor control when spoofing is the threat.

Technical breakdown

Why unauthenticated relay is a spoofing problem

Direct Send works by allowing a device or application to submit mail through Microsoft 365 Exchange Online without authenticating as a user mailbox. That removes a security proof point, because the receiving environment sees mail that originated from Microsoft infrastructure but did not go through a sender identity check. In email security terms, the transport path is legitimate while the sender identity is not. That is why spoofing becomes practical: the attacker does not need account takeover if the mail flow itself accepts messages without proving who sent them. The problem is architectural, not simply procedural.

Practical implication: treat any unauthenticated application mail path as a sender-identity control gap, not just a delivery convenience.

How trusted infrastructure can be abused for phishing and fraud

When mail originates from a trusted cloud service, internal recipients are more likely to accept it at face value, especially if the message appears to come from an organisation domain they recognise. This creates a trust inversion: infrastructure that should help deliver legitimate mail becomes a vehicle for impersonation. In this pattern, the attacker is not defeating mailbox authentication directly. Instead, they are exploiting the organisation’s reliance on a mail path that lacks sender authentication, signing discipline, and central oversight. That makes it harder for downstream controls to distinguish legitimate application mail from abuse.

Practical implication: align application mail with DKIM, SPF, and DMARC controls so trust is established at the message level, not assumed from transport.

Why centralised relay changes the control model

A secure relay model changes the control point from dispersed application mail sources to a single governed relay with authentication, policy enforcement, and logging. That matters because non-human mail often grows organically across printers, line-of-business tools, and cloud workflows, which makes inventory and enforcement inconsistent. Centralisation does not just improve visibility. It creates a manageable lifecycle for approval, revocation, encryption, and content scanning. For identity teams, the important shift is that application mail becomes an explicitly governed non-human identity flow rather than an implicit exception to email policy.

Practical implication: route device and application mail through a controlled relay so approval, revocation, and monitoring can be applied consistently.

Threat narrative

Attacker objective: The attacker aims to send convincing spoofed mail through a trusted Microsoft path without compromising a legitimate user account.

1. Entry occurs when an attacker abuses a Direct Send path that accepts mail without authenticating a user mailbox or approved sender identity.
2. Credential harvesting is not required, because the abuse comes from the mail flow itself rather than from stolen mailbox credentials.
3. The attacker uses trusted Microsoft infrastructure to impersonate a domain and deliver phishing or fraud messages that are more likely to be trusted by recipients.
4. Impact is domain spoofing and deceptive mail delivery that can bypass normal suspicion, weaken DMARC protections, and support downstream compromise or fraud.

Breaches seen in the wild

• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

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

NHI Mgmt Group analysis

Direct Send is a non-human identity governance problem, not just an email transport choice. The article shows that application-generated mail can bypass the sender assurance expected in modern controls. That means the real issue is whether non-human mail flows are inventoried, authenticated, and lifecycle-managed like other machine identities. Practitioners should treat every application mail path as part of identity governance.

Trusted infrastructure can create a false sense of legitimacy that fraudsters exploit. When messages come through Microsoft infrastructure, users are more likely to trust them, even if the sending source was never authenticated. This is the same governance weakness seen whenever delivery trust is mistaken for sender trust. Security teams need controls that validate origin, not just transport.

Mail relay centralisation is the named concept this article surfaces: governed non-human mail routing. The control shift is from ad hoc Direct Send exceptions to a single policy-enforced relay with auditability, signing, and revocation. That aligns application mail with the broader NHI discipline, where ungoverned service flows are the risk, not merely the technology used to move messages.

DMARC, DKIM, and SPF only help when the organisation commits to message-level accountability. The article makes clear that outbound hygiene and inbound impersonation defense are linked. If internal application mail is allowed to bypass signing or central policy, the organisation weakens its own authentication posture and complicates fraud detection. Practitioners should make sender authenticity a default requirement for non-human email.

The bigger signal is that email security and identity security are converging around non-human workflows. As more business systems send messages automatically, the attack surface shifts from users to service-driven communication paths. That requires IAM, NHI, and messaging teams to govern these flows together, because the control failure is shared. Organisations that separate them will keep leaving spoofable exceptions in production.

What this signals

Governed non-human mail routing is becoming a baseline control for Microsoft 365 environments. The practical question is no longer whether a scanner or application can send mail, but whether that sender is tied to an authenticated, revocable, and auditable control path. Organisations that leave Direct Send in place without governance are effectively expanding their spoofing surface.

Email security teams should stop treating application mail as an exception to message authentication policy. The same controls that protect human-generated email, especially signed mail and domain alignment, need to extend to device and application flows if internal users are to trust what they receive.

For practitioners

• Audit all Direct Send usage Inventory scanners, printers, line-of-business apps, and scripts that still send through Exchange Online without authenticated sender identity. Classify each flow as approved, replaceable, or high risk, then remove exceptions that cannot be governed.
• Route application mail through a controlled relay Move device and application messages to a secure relay that enforces authentication, policy checks, logging, and revocation for non-human senders. Use the relay as the single enforcement point for outbound application mail.
• Enforce SPF, DKIM, and DMARC alignment Require signed application mail and configure sending domains so outbound messages can be validated and inbound spoofing can be rejected. Prioritise flows that currently depend on Microsoft infrastructure trust alone.
• Create ownership for non-human mail flows Assign a business and technical owner to each application sender so changes, approvals, and shutdown decisions are accountable. Include these senders in periodic access and configuration reviews alongside other non-human identities.

Key takeaways

• Direct Send exposes a governance gap where non-human mail can travel through trusted infrastructure without proving sender identity.
• The article’s core risk is spoofing, phishing, and fraud enabled by an unauthenticated application mail path rather than by mailbox compromise.
• A secure relay model gives organisations a way to centralise approval, signing, logging, and shutdown for device and application senders.

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.
• DNS Spoofing: DNS spoofing is the manipulation of name resolution so a victim is sent to a fake destination instead of the intended service. In identity security, it matters because users may trust the right brand while unknowingly sending credentials or tokens to an attacker-controlled endpoint.
• Secure Email Relay: A secure email relay is a controlled outbound mail path that applies policy, inspection, and trust checks before delivery. It centralises governance for application, device, and partner email so security teams can enforce authentication, data protection, and reporting consistently across multiple senders.
• DMARC: DMARC is an email authentication policy mechanism that uses DNS-published records to tell receiving mail systems how to handle messages that fail alignment checks. It helps reduce impersonation risk, but it only works when the published policy is accurate, current, and governed as part of the domain's security state.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security, IAM, and platform teams build the governance model that non-human workflows now require.