Executive summary: Varonis has surfaced an active phishing campaign that spoofs internal users by abusing Microsoft 365’s Direct Send feature. Because Direct Send doesn’t require authentication and is treated as “internal,” these messages often bypass the checks you rely on for outside mail. Microsoft now offers an opt-in switch, RejectDirectSend, to block the pathway, but enabling it without preparation can disrupt printers, scanners and line‑of‑business applications that still depend on Direct Send.
Key takeaways
- Direct Send lets any host inside Microsoft 365 deliver email to your users without authenticating. Threat actors are using it to spoof colleagues and slip past external-mail checks.
- The campaign, active since May 2025, has already targeted 70 + organisations across various sectors.
- Microsoft’s new RejectDirectSend switch blocks the vector, but may break devices that still depend on Direct Send. Test before enforcing.
What’s the issue?
Direct Send exists so that devices and applications can email people inside your Microsoft 365 tenant without authenticating. Think multi‑function printers that scan to email, monitoring tools that fire off alerts, or legacy apps that were never updated to use SMTP Auth.
Attackers have realised they can use the same unauthenticated route to drop phishing messages right into inboxes while impersonating real colleagues. Because the traffic stays inside Microsoft’s infrastructure, many external‑facing controls such as banners, quarantines, even some Domain based Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks never come into play. This technique has been used against over 70+ of organisations since May 2025, and there’s no sign it’s slowing down.
Why does it matter to Red Sift customers?
First, internal trust is powerful. Your users are conditioned to relax when an email appears to originate from “HR” or “IT” and uses an internal display name and address. That makes click‑through rates and credential capture far more likely.
Second, DMARC guards the perimeter; it is excellent at stopping exact domain impersonation spoofs coming from the internet, but a message injected via Direct Send can look perfectly aligned because it never leaves the Microsoft cloud. Third, many detection stacks are tuned to scrutinise external mail. If your SIEM rules, SEG policies or user training focus on “outside in,” internal‑looking traffic can slip past unnoticed. Finally, knee‑jerk remediation can hurt: if you simply block Direct Send without a migration plan, business‑critical workflows may fail quietly.
What this could mean for legitimate mail and how to avoid breakage
Blocking Direct Send without preparation can have very real side effects. Multi‑function printers may stop delivering scanned PDFs to shared mailboxes. Line‑of‑business systems could quietly fail to send invoices or support tickets. Security and monitoring tools might lose their email notification channel, creating alert blind spots. Even after migration, remember that SMTP Auth and relay connectors have their own rate and size limits; plan capacity accordingly and watch the logs for throttling or errors.
How to take action quickly and safely
Start by discovering who and what still uses Direct Send in your environment. Run message traces or log searches for traffic hitting your tenant with no authentication results, and cross‑reference that with a simple inventory: printers, scanners, monitoring tools, ERP or ticketing systems, custom scripts. Expect surprises, old workflows have a way of lingering.
Once you have that list, migrate the legitimate senders. The cleanest option is to move devices and apps to SMTP Auth client submission over port 587 with a dedicated service account. Where possible, go a step further and stand up a certificate‑bound connector that only accepts mail from known IPs or TLS identities. Both options give you authentication, logging and rate‑limit control that Direct Send never provided.
After you’ve proven those paths work, block the abuse route. Microsoft’s new tenant‑wide flag does exactly that:
Set-OrganizationConfig -RejectDirectSend $true
Roll it out in a pilot group or during a maintenance window, monitor for NDRs or sudden drops in expected mail, and keep rollback handy. Treat this like any other change that can affect business processes.
Hardening shouldn’t stop at the transport layer. Make sure your primary domains are at DMARC enforcement (p=reject) and that you actively monitor for anomalies. We recommend checking the headers of potential suspicious emails. If you need support in reaching DMARC enforcement, Red Sift OnDMARC takes the hassle out of implementation, giving you peace of mind in as little as 6-8 weeks. In addition, add detections for the specific lures seen in this campaign (for example, “new voicemail” themes or QR‑code attachments) and remind users that “internal” no longer guarantees “safe.”
Not really sure where to start? Check your DMARC status and domain security for free with Red Sift Investigate.
