The Email That Couldn’t Possibly Be Fake (But Was)
Your CFO gets an email from your HR manager with a voicemail notification. Same domain, same email format, no external sender warning. She clicks the attachment—a PDF with a QR code—scans it with her phone, and lands on what looks like your company’s voicemail portal. She types in her credentials.
Two minutes later, an attacker in another country logs into her Microsoft 365 account with those credentials and starts downloading financial records.
Here’s the part that makes this particularly frustrating: the email really did appear to come from your domain. Your spam filter didn’t catch it because, from Microsoft’s perspective, it looked like legitimate internal email. Your HR manager’s account wasn’t compromised—she never sent anything. The attacker didn’t need to breach your network or phish anyone first.
They just knew your domain name and how Microsoft 365 works.
If your users have been getting suspicious emails that appear to come from inside your own company—from colleagues they know, using your actual domain, with no external sender warnings—you’re not imagining things, and your email security isn’t necessarily broken. There’s a good chance you’re looking at the fallout from a Microsoft 365 feature called Direct Send, and the attackers abusing it have been busy.
We’ve seen a noticeable uptick across our client base over the past several months. Here’s what’s happening, what Microsoft is doing about it, and—most importantly—what you need to do to close the gap.
What Direct Send Is (And Why It Exists)
Direct Send is a Microsoft 365 feature built for a reasonable purpose: letting on-premises devices like multifunction printers, scanners, and older line-of-business applications send email through your tenant without needing a mailbox or modern authentication.
If you’ve ever hit “Scan to Email” on your office copier and had the scanned document land in your inbox, there’s a decent chance Direct Send was involved. It’s a practical solution for legacy equipment that can’t handle OAuth or app passwords but still needs to send email.
Every Microsoft 365 tenant has a public endpoint for Direct Send—something like yourcompany-com.mail.protection.outlook.com—that accepts these unauthenticated email submissions. The endpoint isn’t secret. It’s predictable, it’s publicly discoverable through DNS lookups, and it’s enabled by default on every Microsoft 365 tenant ever created.
That last part is where the problem starts.
Why Attackers Love Direct Send
Direct Send doesn’t require credentials. It doesn’t require an authentication token. It doesn’t require anyone inside your organization to have been phished first.
An attacker who knows your domain name (public information—it’s on your website) and can guess a valid email format like first.last@yourcompany.com (also usually public information, or easily guessable from LinkedIn) has everything they need to send email into your Microsoft 365 tenant with your own domain on the From line.
Because the message is delivered through Microsoft’s own infrastructure and appears to originate internally, it often slides past the filters that would normally catch external phishing attempts:
- Microsoft’s own spam and phishing protection may treat it as internal-to-internal traffic and give it the benefit of the doubt
- Third-party email security gateways generally aren’t analyzing this traffic because it bypasses your MX record entirely—it goes straight to the Direct Send endpoint
- End users see an email from a known colleague with no external warning banner, no red flags, and no reason to be suspicious
The result: users click attachments and links they would normally question, because the email looks completely legitimate.
This Isn’t Theoretical—It’s Happening Now
Security researchers at Varonis publicly documented an active campaign that began in May 2025 and hit more than 70 organizations. Victims were concentrated in financial services, manufacturing, construction and engineering, and healthcare.
The typical attack pattern: a spoofed voicemail notification email with a PDF attachment, a QR code inside the PDF pointing to a credential-harvesting page, and the whole thing appearing to come from the user’s own email address or a colleague’s address. Cisco Talos and Mandiant reported similar activity through the end of 2025 and into early 2026.
We’ve seen it firsthand with clients in the Denver metro area. The attacks are real, they’re active, and they’re effective because they exploit a feature most businesses don’t even know exists.
What Microsoft Is Doing—And What They’re Not
Microsoft has acknowledged the issue and taken two meaningful steps.
Step 1: A New Control to Block Direct Send
Microsoft introduced a new Exchange Online setting called RejectDirectSend. When enabled, it blocks unauthenticated Direct Send traffic outright. Messages that hit this block bounce with a clear error message:
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources.
This control works. Turn it on, and attackers can no longer abuse Direct Send to spoof your domain.
Step 2: Blocking Direct Send by Default for New Tenants
Microsoft announced that new Microsoft 365 tenants provisioned starting in early 2026 will have Direct Send rejected by default. Those new tenants won’t be able to turn it back on.
This is good news for organizations setting up Microsoft 365 for the first time in 2026. It does exactly nothing for everyone else.
The Catch That Matters for Almost Everyone
This change is not retroactive.
If your Microsoft 365 tenant was created before early 2026—which is virtually every existing customer—Direct Send is still wide open by default. Microsoft is not going to flip the switch for you retroactively. You or your IT provider have to do it manually.
This means that right now, unless you’ve specifically disabled it, attackers can spoof your domain through Direct Send with no technical barriers.
What You Should Do
Closing this gap isn’t a massive project, but it does require some preparation. The worst outcome is enabling the block without first accounting for legitimate Direct Send traffic, which can break printer scan-to-email, monitoring alerts, and older business applications overnight.
Here’s the sequence we recommend and follow with our clients:
Step 1: Inventory What’s Legitimately Using Direct Send
Start with message trace in the Exchange admin center. Look for anything submitting email to your tenant’s Direct Send endpoint from your known office IP addresses or cloud services—copiers, scanners, monitoring tools, backup systems, custom applications.
Anything you find here needs a migration plan before you pull the plug. Document what’s sending email, from where, and to whom.
Step 2: Migrate Legitimate Senders to Authenticated SMTP
For modern devices that support it, authenticated SMTP submission on port 587 with OAuth is the right answer. This is how email is supposed to work—the sender authenticates, Microsoft verifies their identity, and the message is delivered with proper authentication headers.
For devices that can’t do modern authentication (older copiers, legacy applications), you have two options:
- Inbound connector scoped to a specific public IP address or certificate. This tells Exchange Online “trust email from this specific source.”
- Third-party SMTP relay service (like SendGrid, Mailgun, or similar). For small environments, this can be easier to manage and gives you better visibility into what’s being sent.
The goal is to move every legitimate email sender off Direct Send and onto an authenticated path before you close the door.
Step 3: Verify Your Email Authentication Posture
Direct Send abuse succeeds most dramatically against organizations whose DMARC policy is set to p=none, which means “tell me about authentication failures but deliver the mail anyway.”
If that’s where you are, you should be moving toward p=quarantine or p=reject. Make sure SPF and DKIM are properly configured for every legitimate sending source.
Proper email authentication won’t stop Direct Send abuse by itself, but it reduces the blast radius and makes spoofed emails easier to detect and block.
Step 4: Tighten Anti-Phishing Policy
Confirm that your Microsoft 365 anti-phishing policy has:
- Spoof intelligence enabled (it usually is by default, but verify)
- Action for detected spoofing set to Quarantine rather than just moving it to the Junk folder
- Unauthenticated sender indicators turned on so users see a visual warning on suspect messages
These settings help catch spoofed email that makes it past other controls.
Step 5: Enable the Block
Once legitimate senders are accounted for and migrated to authenticated paths, you can flip the switch. It’s a single PowerShell command:
Set-OrganizationConfig -RejectDirectSend $true
The change takes about 30 minutes to propagate across Microsoft’s infrastructure. Monitor your message trace closely for the first week to catch anything you missed during inventory.
Step 6: Lock Down Your Inbound Connector (If You Use a Third-Party Filter)
If your MX record points to a third-party email security gateway (Barracuda, Proofpoint, Mimecast, etc.) instead of directly to Microsoft, make sure your Exchange Online inbound connector is locked down to only accept mail from that service.
Use either IP address restriction or certificate-based restriction. Otherwise, attackers can bypass your expensive email security gateway by sending directly to the Exchange Online endpoint—rendering your third-party filter useless.
Why This Matters for Compliance-Focused Organizations
If your business operates under HIPAA, CMMC, SOC 2, PCI-DSS, or any similar framework, an incident where an attacker successfully spoofs internal email and harvests credentials is not just a bad day—it’s a reportable event with real regulatory consequences.
The fact that the attacker never actually compromised an account through traditional means doesn’t change the analysis. What matters is that sensitive information was accessed or could have been accessed, and that your controls failed to prevent it.
During a compliance audit or cyber insurance review, “we didn’t know Direct Send could be abused” is not an acceptable answer. The vulnerability has been publicly documented since mid-2025. The remediation is straightforward. The expectation is that you’ve closed the gap.
The good news: this specific risk is one of the cheaper and faster hardening steps available in Microsoft 365. For most small businesses, it’s a one-to-two-hour project with proper preparation. That’s a remarkably good return on investment for closing a actively-exploited attack vector.
Why Hasn’t This Been Fixed Already?
Fair question. Microsoft had two options: break backward compatibility for millions of existing tenants by forcibly disabling Direct Send (and breaking every copier, scanner, and legacy app that depends on it), or give administrators the tools to fix it themselves and hope they do.
They chose the second option, which is probably the right call from a “don’t break the entire installed base” perspective. But it means the burden falls on IT teams and managed service providers to actually implement the fix.
Most small businesses don’t have dedicated IT security staff reading Microsoft security advisories and proactively hardening their tenants. That’s where managed service providers come in—or should, anyway.
We’re Working Through This With Our Clients
We’ve been systematically addressing Direct Send across our managed client base over the past few months. We’ve built a standard assessment and remediation workflow:
- Inventory current Direct Send usage through message trace analysis
- Migrate legitimate senders (copiers, scanners, monitoring tools) to authenticated SMTP or inbound connectors
- Tighten email authentication records (SPF, DKIM, DMARC)
- Enable the Direct Send block
- Monitor for a week to catch any edge cases
The whole process takes one to two hours for a typical small business tenant, and it closes an attack vector that’s being actively exploited right now.
If you’re a current client, we may have already reached out to schedule this work. If you’re not a client and you’d like us to take a look at your Microsoft 365 tenant, get in touch.
Don’t Wait for Microsoft to Do This for You
The attackers are not going to wait until some hypothetical future when Microsoft might retroactively enable Direct Send blocking for existing tenants. They’re sending phishing emails from your domain right now, today, using a feature you probably didn’t know existed.
Closing this gap is straightforward, low-risk, and protects against an attack pattern that’s already being used in the wild. If you manage Microsoft 365 for your business and you haven’t addressed Direct Send yet, it should move to the top of your security to-do list.
Get Your Microsoft 365 Tenant Hardened
Direct Send is just one of many security configurations in Microsoft 365 that are set to “open by default” and require proactive hardening. At Castle Rock Sky, we help Denver metro businesses lock down their Microsoft 365 environments without breaking the features they actually use.
We can:
- Audit your current Direct Send usage and identify legitimate senders
- Migrate devices and applications to authenticated email paths
- Harden your email authentication (SPF, DKIM, DMARC)
- Close the Direct Send loophole safely
- Review your broader Microsoft 365 security posture for other gaps
If you’re concerned about Direct Send abuse or want a comprehensive Microsoft 365 security review, we can help.
