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.
Editorial analysis by NHI Mgmt Group, based on content published by Abnormal AI: “Microsoft Direct Send Abuse: Why Legacy Defenses Fall Short”.
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.
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.
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.
Practitioner guidance
- Tighten Direct Send exceptions Review every rule that allows unauthenticated internal-looking mail from known IP ranges or Microsoft-routed sources.
- 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.
- Shift detection from signatures to behaviour Look for blank bodies, encrypted attachments, QR codes, self-addressed mail and unusual internal impersonation patterns.
Bottom line: Direct Send abuse exposes a governance gap where delivery infrastructure is treated as proof of trust, even when no authenticated user session exists.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
27/06/2026 3:35 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Direct Send abuse exposes the limits of email trust controls