When Your Email Gateway Trusts the Wrong Sender
Your inbound email filter has a checklist. SPF pass. DKIM pass. DMARC aligned. Green checkmarks all the way down, so the message sails straight to the inbox. Now imagine an attacker who doesn't need to fake any of those signals—who gets treated as a first-party sender simply because a misconfigured feature told your tenant, "this came from inside the house."
That is what a live phishing campaign attributed to the Chinese-nexus group UNC5221 is doing right now, abusing a Microsoft 365 feature called Direct Send. The campaign was reported by BleepingComputer in late June 2025 and first observed by Varonis Threat Labs in mid-June. It is not a zero-day. It is not some exotic protocol-level exploit. It is a feature behaving exactly as designed, in a tenant configuration that most administrators never knew to question.
For security teams tracking AI cybersecurity threats in 2026, this campaign is a useful reminder: sophisticated-looking attacks do not always rely on AI. Direct Send abuse is primarily a configuration and trust-boundary problem. Knowing what AI is in cyber security—and how AI is used in cybersecurity for triage and detection—helps distinguish AI-assisted threats from conventional phishing techniques.
What Is Microsoft 365 Direct Send?
Direct Send is a Microsoft 365 feature that lets devices and applications in your organization send messages through Exchange Online using your tenant's MX endpoint, without authenticating with a mailbox username and password. Printers, scanners, line-of-business applications, and monitoring systems commonly use it to email reports or scanned documents.
The design assumption is that the sending device is on your trusted network and that messages are addressed to people in your own organization. Direct Send does not require SMTP AUTH credentials. The sender connects to the tenant's MX endpoint and identifies an internal sender address. In some configurations, Exchange Online accepts and routes the message as internal mail.
This is different from SMTP relay, which uses a connector and is intended for broader delivery scenarios, and from authenticated client submission, which requires a mailbox identity. Direct Send can be useful for legacy devices, but its trust model should be reviewed carefully.
How the Campaign Abuses Direct Send
Attackers can send crafted messages to a tenant's MX endpoint and use an internal-looking From address. If the tenant accepts the message under its Direct Send configuration, recipients may see what appears to be a message from a colleague or internal department. The campaign described by BleepingComputer used QR-code phishing lures and links intended to steal credentials.
The key issue is not that SPF, DKIM, or DMARC are universally broken. Rather, mail accepted through a tenant's own inbound path can be evaluated and presented differently from ordinary external spoofing. A passing authentication signal alone is not proof that a message is benign or that the named employee actually sent it. Organizations should inspect headers, routing, and the specific trust path.
The reported activity was attributed to UNC5221 by researchers; attribution is not the same as proof of identity for every message using this technique. Administrators should verify current Microsoft guidance and their own tenant configuration before making changes.
AI Cybersecurity Threats: What AI Does—and Doesn't Do—Here
What is AI in cyber security? It refers broadly to machine-learning and other AI techniques used to analyze security data, identify patterns, prioritize alerts, and assist analysts. How AI is used in cybersecurity includes detecting anomalous sender behavior, clustering similar phishing messages, and helping responders investigate large volumes of telemetry.
Those capabilities can help surface suspicious messages, but they do not replace secure configuration, identity controls, or user reporting. The Direct Send campaign described here is not evidence that AI generated or operated the phishing activity. It illustrates why defenders should avoid treating all emerging AI cybersecurity threats as the same: conventional abuse of trusted email pathways can still be effective, whether or not AI is involved.
Practical Defenses for Microsoft 365 Administrators
- Review whether Direct Send is needed. Identify devices and applications that depend on it before changing mail flow.
- Restrict accepted mail paths and follow current Microsoft guidance for limiting unauthenticated messages that appear to originate from your domain.
- Consider disabling or tightly limiting Direct Send if your environment does not require it; test business workflows first.
- Monitor message trace and mail-flow telemetry for unexpected sender addresses, unusual volumes, QR-code lures, and anomalous routing.
- Use layered protections: phishing-resistant MFA, safe-link and attachment controls, and clear user reporting procedures.
- Investigate suspicious messages using full headers and authentication results rather than relying on the display name or a single pass/fail indicator.
What Security Teams Should Take Away
Direct Send is a legitimate feature, but broad trust in unauthenticated messages that appear internal can create an opportunity for phishing. Review the feature against actual business requirements, apply Microsoft's current configuration guidance, and monitor for unexpected use. AI-powered analysis may help prioritize signals, but it cannot compensate for an unnecessarily permissive mail-flow design.
