Microsoft and IRONSCALES Crack Down on the Direct Send Exploit

Back in Part 1, we walked through how attackers are using Microsoft 365’s Direct Send feature to spoof internal emails, making those messages look like they’re coming from a trusted domain.

Now, Microsoft is tightening the screws with new controls and clearer guidance on how to shut that door before someone walks through it.

This post breaks down what’s changed, what you need to do, and how to keep legitimate mail flowing while keeping the bad actors out.

What’s New from Microsoft?

  1. New 'RejectDirectSend' Feature

Microsoft has released a new tenant-wide control (in public preview) called RejectDirectSend. When enabled, it blocks unauthenticated emails from your own accepted domains—emails that don’t flow through a trusted connector.

This is a big deal. Previously, attackers could spoof your domain and send messages straight to Exchange Online using port 25, bypassing SPF, DKIM, and other checks. Now, Exchange will reject that traffic automatically.

You can turn it on with a single PowerShell command:

Set-OrganizationConfig -RejectDirectSend $true

Once enabled, Exchange will block unauthenticated internal spoof attempts and return this error to the sender:

550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

  1. Connector-Based Exceptions

If you have printers, scanners, line-of-business apps, or external services sending mail on your behalf, you’ll need to make sure those senders are authenticated. Microsoft recommends using an inbound partner connector with either IP or certificate-based authentication.

  1. SPF & DMARC Still Matter

Even with the new feature, Microsoft emphasizes continuing to enforce SPF, DKIM, and DMARC correctly. Use ~all (soft fail) in your SPF policy if you need flexibility for legitimate third-party senders. Misconfigurations still cause both false positives and missed threats.

  1. Better Logging and Visibility

For now, Microsoft’s RejectDirectSend control doesn’t show up in standard logs unless you’re looking. You’ll need to inspect traffic using Audit Logs or advanced queries (filtering by sender domain, authentication status, etc.). Make sure you have eyes on the metrics so you don’t accidentally block something important.

What IRONSCALES Has Done to Protect Our Clients

While Microsoft has tightened Direct Send controls, our team has already deployed targeted updates to protect customers against these attacks and the techniques threat actors rely on to sneak past basic authentication checks.

Here’s what’s new in your IRONSCALES environment:

  • New Detection Logic Deployed – Covers “Direct Send” impersonation attempts, where attackers bypass traditional relay checks and pose as trusted internal users.
  • Enhanced Attachment Scanning – Added specific rules for prominent extensions including but not limited to SVG and HTML payloads, which are frequently used to hide phishing links or embedded malicious code.
  • Improved Cross-Module Consistency – Detection modules now share results more effectively, reducing situations where one module spotted suspicious activity but the verdict wasn’t reflected in the final classification.
  • Ongoing Tuning – Our Security Research team continuously fine-tunes detection logic to maximize catch rates while keeping false positives low.

What this means in practice:
These updates allow us to automatically detect and remediate emails that previously had a higher chance of slipping through — including internal impersonation attacks via Direct Send and phishing attempts hidden in less common attachment types like SVG or HTML.

You don’t need to take any action — these protections are already live and active across your mailboxes.

Action Items: What You Should Do Today

  Steps To Take

1

Inventory all systems or apps using Direct Send (like printers, email alerts, Azure Comm Services, etc.)

2

Update your SPF record with the IPs of legitimate senders; use soft fail (~all) to avoid bouncebacks

3

Enable RejectDirectSend: Set-OrganizationConfig -RejectDirectSend $true

4

Create inbound connectors for authenticated traffic using IP or certificate validation

5

Monitor rejected mail for the 550 5.7.68 error to catch misconfigured systems

6

Coordinate with app/device owners to migrate away from anonymous port 25

7

Stay ready — Microsoft will eventually enable this control by default for all new tenants


Q&A: What You Need to Know

Q: What happens if a printer or line-of-business app sends mail after I enable RejectDirectSend?
A: If that traffic isn’t authenticated through a connector, Exchange will block it with the 550 5.7.68 error. This means the sender is trying to impersonate your domain without permission. The fix is simple: set up an inbound connector that validates via IP or certificate. You get to define who’s allowed to speak for your domain.

Q: Is Direct Send the same as regular email delivery?
A: Not quite. Direct Send means sending email from your accepted domain to Microsoft 365 without authentication. Microsoft has clarified that not all unauthenticated mail is Direct Send—but when it comes from your domain, it should be protected. Otherwise, it’s a spoof waiting to happen.

Q: Can SPF or DMARC catch this kind of spoofing without the new control?
A: Sometimes—but not always. SPF only works if the receiving server checks it and the sending IP is on your allowlist. DMARC depends on SPF/DKIM passing and domain alignment. If an attacker sends mail directly via port 25 with a forged header, SPF and DKIM checks often aren't enforced. That’s why Microsoft introduced RejectDirectSend—to cut this loophole off entirely.

Q: I’m not sure what’s using Direct Send in our environment. How do I avoid breaking things?
A: Start with monitoring. Look for emails coming from your domain without authentication or connector attribution. Microsoft recommends auditing sender traffic by IP and filtering on the SenderMailFromAddress field. Once you’ve identified your legit sources, build connectors and test before flipping the switch.

Final Thoughts

Microsoft’s new RejectDirectSend feature is an important step toward closing a loophole that attackers have exploited for years. But it’s only part of the picture. Threat actors move fast, and no single control — whether SPF, DMARC, or tenant-wide settings — is enough to keep pace on its own.

That's why IRONSCALES has already gone further. With new detection logic, enhanced attachment scanning, and continuous tuning from our security research team, we’re making sure these same tactics are detected and remediated automatically at the inbox level. You don’t need to wait for policies to roll out either. This protection is already live and active.

We’re here to help if you want to talk through how these changes impact your environment, or if you’d like a deeper look at how IRONSCALES complements Microsoft 365 to shut down advanced impersonation and phishing techniques before they reach your users.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.