Microsoft 365 Direct Send Exploit: How Attackers Bypass Email Authentication

A concerning Microsoft 365 feature known as Direct Send has become a favorite tool for attackers looking to bypass email authentication and impersonate organizations.

What is Direct Send?

Direct Send is a legitimate Microsoft 365 feature designed for:

• Internal applications sending automated emails
• Multifunction printers and scanners
• LOB (Line of Business) applications
• IoT devices sending notifications

How It's Supposed to Work

Direct Send allows applications to send email without authenticating by connecting directly to Microsoft's mail servers. It's intended for:

1. Internal relay scenarios
2. Devices that can't store credentials
3. Legacy applications

The legitimate use case: Your office printer scans a document and emails it to you using your organization's domain, without needing a full mailbox license.

The Security Problem

The Exploit

Attackers discovered they could abuse Direct Send to:

1. Send emails appearing to come from any Microsoft 365 domain
2. Bypass SPF checks (because Microsoft's servers ARE authorized senders)
3. Avoid DKIM failures (Direct Send emails often aren't DKIM-signed)
4. Evade detection (emails originate from Microsoft infrastructure)

Why It Works

When an attacker sends via Direct Send:

• The email comes from Microsoft's IP addresses
• SPF passes because Microsoft is in most organizations' SPF records
• The "From" address can be spoofed to any domain using M365
• Recipients see a legitimate-looking email from a trusted organization

Real-World Attack Scenario

1. Attacker creates a free Microsoft 365 trial
2. Uses Direct Send to send email claiming to be from victim-company.com
3. Email passes SPF because it's from Microsoft's infrastructure
4. Recipient sees email from victim-company.com in their inbox
5. Attacker uses this for phishing, BEC, or credential theft

Who Is Vulnerable?

Your organization is vulnerable if:

• You use Microsoft 365 for email
• Your SPF record includes Microsoft's servers (most M365 users)
• You don't have DMARC at enforcement (p=quarantine or p=reject)
• You don't have strict DKIM alignment requirements

Check Your Vulnerability

Use our free scanner to check:

• Is your SPF record including Microsoft servers?
• Do you have DMARC configured?
• Is your DMARC policy at enforcement level?

Protection Strategies

1. Implement DMARC with Enforcement

DMARC is the primary defense against Direct Send exploitation:

v=DMARC1; p=reject; rua=mailto:[email protected]

With p=reject, emails that fail DKIM alignment will be rejected, even if SPF passes.

2. Enable DKIM Signing

Ensure all legitimate email from your domain is DKIM-signed:

• Enable DKIM in Microsoft 365 Admin Center
• Configure DKIM for third-party senders
• Monitor DMARC reports for unsigned emails

3. Restrict Direct Send in Your Tenant

If you use Microsoft 365, restrict Direct Send:

1. Exchange Admin Center → Mail Flow → Connectors
2. Create an inbound connector restricting Direct Send to specific IPs
3. Only allow known internal devices/applications

4. Enhanced Filtering for Connectors

Enable Enhanced Filtering for your connectors to preserve original sender information:

1. Security Admin Center → Policies → Enhanced Filtering
2. Enable for relevant connectors
3. This helps detect spoofed Direct Send emails

Technical Deep Dive

How Direct Send Differs from SMTP Relay

Why SPF Alone Doesn't Protect You

SPF verifies that the sending server is authorized, not the From address. When Microsoft sends on someone's behalf:

1. Email comes from Microsoft's servers
2. SPF checks Microsoft's IP → Pass
3. From address could be any domain → Not checked by SPF

This is exactly why DMARC alignment is critical.

Microsoft's Response

Microsoft has acknowledged the issue and recommends:

• Using authenticated SMTP submission where possible
• Implementing DMARC with enforcement
• Restricting Direct Send via connector rules
• Monitoring for abuse in audit logs

However, they haven't disabled Direct Send due to legitimate business use cases.

Action Items

Immediate (Today)

1. Scan your domain to check current authentication status
2. Review your SPF record for Microsoft inclusion
3. Check if DMARC is at enforcement level

Short-Term (This Week)

1. Enable DKIM signing in Microsoft 365
2. Create DMARC record if missing
3. Move DMARC to p=quarantine if currently at p=none

Medium-Term (This Month)

1. Review Direct Send usage in your tenant
2. Create connector rules to restrict unauthorized Direct Send
3. Move DMARC to p=reject after monitoring

---

Don't let a legitimate feature become your security vulnerability.

Check your Microsoft 365 configuration now or contact us for help securing your email infrastructure.