Notifications
Clear all
Topic starter
14/07/2026 4:26 pm
TL;DR: Microsoft Direct Send lets devices and apps send email through Exchange Online without user credentials, but that convenience also lets attackers spoof domains and push phishing or fraud through trusted Microsoft infrastructure, according to Proofpoint. The security gap is not delivery, it is unauthenticated trust in non-human mail flows.
NHIMG editorial — based on content published by Proofpoint: Microsoft Direct Send and Secure Email Relay
Questions worth separating out
Q: How should security teams govern application and device email sent from Microsoft 365?
A: They should treat application and device mail as a managed non-human identity path, not as a convenience feature.
Q: Why does unauthenticated mail relay increase spoofing risk?
A: Because the receiving systems are validating delivery path more than sender identity.
Q: What breaks when Direct Send is used as the default for non-human mail?
A: The organisation loses a clear identity boundary for machine-generated email.
Practitioner guidance
- Inventory every Direct Send dependency Identify printers, scanners, apps, and legacy workflows that still use unauthenticated relay and map each one to a business owner and replacement path.
- Move non-human mail to authenticated relay Require devices and applications to use a controlled secure relay with explicit source approval, logging, and revocation capability.
- Enforce DKIM and DMARC alignment Sign all application mail with DKIM and move domains toward a reject policy so spoofed messages fail authentication instead of reaching inboxes.
What's in the full article
Proofpoint's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for replacing Direct Send with Secure Email Relay in Microsoft 365 environments
- Configuration specifics for SPF, DKIM, and DMARC alignment for application-generated mail
- Operational details on centralised visibility, relay control, and threat scanning for machine mail flows
- Implementation notes for organisations handling PII or PHI in application email
👉 Read Proofpoint's analysis of Microsoft Direct Send and Secure Email Relay →
Microsoft Direct Send and domain spoofing: what teams need to change?
Explore further
14/07/2026 4:33 pm
Unauthenticated application mail is a governance problem, not just an email problem. Direct Send creates a gap between delivery and identity assurance, which is exactly where spoofing campaigns thrive. When the sender is a device or application, the question is not whether mail can be delivered, but whether the sending identity is controlled, revocable, and auditable. Practitioners should treat this as a non-human identity boundary that requires the same discipline as other workload access paths.
A question worth separating out:
Q: Who is accountable when application mail can spoof the organisation's domain?
A: Accountability should sit jointly with email security, IAM, and the system owner for the sending application or device. Email teams control the domain policy, IAM teams define identity and access governance, and application owners must remove unsupported sending paths. If no one owns the sender, spoofing risk becomes everybody's problem and nobody's control.
👉 Read our full editorial: Microsoft Direct Send creates spoofing risk for application mail
