Keeping Direct Send Safe: A Practical Guide for Microsoft 365 Admins

Attackers rarely miss an opportunity to twist a convenient feature into a phishing tool. Exchange Online’s Direct Send is the latest example: security researchers have documented campaigns that drop fake “internal” messages straight into corporate inboxes—no credentials required. Headlines warn that these messages “bypass SPF, DKIM and DMARC,” leaving IT teams wondering whether the standard defences they rely on have suddenly become useless.

The good news: they haven’t. The protocols still do exactly what they’re designed to do. The bad news: if you don’t enforce the results rigorously, criminals can still slip through. This article walks through what Direct Send is, how the abuse works, why the email-auth “bypass” claims are misleading, and—most important—how to eliminate the loophole without breaking legitimate workflows.

---

1. Direct Send in Plain English

Microsoft built Direct Send for one very specific use-case: letting on-premises devices or line-of-business applications send mail inside your tenant without modern authentication. A multifunction printer, for example, can scan a document and email it to the user who scanned it.

How it works

1. The device opens an anonymous SMTP session to your tenant’s MX host (yourdomain-com.mail.protection.outlook.com) on port 25.
2. It stamps a From address that belongs to one of your accepted domains.
3. Exchange Online treats the message as incoming internet mail and runs the normal anti-spam pipeline.
4. Delivery is allowed only to recipients in your tenant—no external relaying.

Because the connection is anonymous, Direct Send carries two key assumptions:

• You will restrict who can use it (ideally only known IP addresses).
• You will maintain strict SPF, DKIM and DMARC so forged mail is caught.

Microsoft’s documentation is blunt: Direct Send is for “advanced customers willing to accept the operational responsibilities of email server admins.”

---

2. How Criminals Twist the Feature

The attacker’s playbook is painfully simple:

1. Reconnaissance
   • Query DNS for the target organisation’s MX record.
   • Harvest one or two internal addresses from LinkedIn, GitHub commits or prior data leaks.
2. Spoof and Send
   • Point a script (Netcat, Python smtplib, PowerShell Send-MailMessage, …) at the MX host.
   • Forge the MAIL FROM and From: headers with the chosen internal address.
   • Drop a phishing lure (PDF with QR code, “missed voicemail” HTML, etc.) that routes to a fake sign-in page.
3. Exploit Trust
   • The message traverses Microsoft’s backbone, so to the recipient it looks like an ordinary internal mail.
   • If the organisation’s anti-spam settings or transport rules grant extra leeway to “inside” messages, the phish may land in the inbox unchallenged.

No credentials, no malware staging, no compromised accounts—just opportunistic use of an open door.

---

3. Why the “Bypass” Label Is Misleading

Here’s what really happens to authentication checks on one of these spoofed emails:

• SPF: fails. The attacker’s source IP is not in the domain’s SPF record.
• DKIM: fails or is missing. The attacker has no signing key.
• DMARC: fails because both SPF and DKIM fail.

So far, so good—nothing is bypassed. The failure shows up in the message headers exactly as the standards intend. The gap appears further downstream:

• Many domains still use a soft-fail (~all) in SPF to accommodate mail-forwarding scenarios. Soft-fail does not mandate rejection.
• DMARC policies are often set to p=none (monitor) or p=quarantine. Unless the recipient system is configured to quarantine strictly, the message can limp into the inbox or “Other” folder.
• Transport rules that say “If the sender’s domain equals ours, lower the spam score” inadvertently wipe out the risk signals.

In short: detection succeeds; enforcement falters.

---

4. Is Direct Send Worth Keeping?

For many organisations the honest answer is “no.” Modern printers can authenticate with SMTP AUTH or Microsoft Graph, SaaS platforms can use OAuth or a secure connector, and there are fewer and fewer reasons to allow anonymous port-25 traffic.

Microsoft evidently agrees. In April 2025 they introduced a tenant-level switch:

Set-OrganizationConfig -RejectDirectSend $true

Flip it on and Exchange Online refuses every unauthenticated Direct Send attempt within about 30 minutes. New tenants created after mid-2025 have the block enabled by default.

If you still have that one ancient line-printer in the warehouse:

• Give it a static outbound IP.
• Build an inbound connector scoped to that IP.
• Move the printer to authenticated SMTP as soon as practical.

---

5. Hardening Checklist

Whether you keep Direct Send or disable it, work through the items below. Most of them matter even if Direct Send is gone—the same settings blunt a host of look-alike phishing tactics.

Step	Action	Why
1. Audit	Review message trace or Defender Threat Explorer for mail where Received: header shows your MX host immediately followed by a public IP you don’t own.	Reveals who (or what) is still using Direct Send.
2. Tighten SPF	• List only legitimate senders and device IPs. • Prefer -all (hard fail) unless you have a forwarding edge-case you truly can’t solve. • In EOP, configure “treat SPF hard-fail as high confidence spam.”	Ensures forged external sources are rejected or quarantined automatically.
3. Enable DKIM	Publish CNAME records and enable signing for every custom domain in the tenant.	An unsigned “internal” message becomes an obvious red flag.
4. Enforce DMARC	Progress from p=none ➜ p=quarantine ➜ p=reject, monitoring reports at each stage.	A strict policy blocks domain impostors across the entire internet, not just inside M365.
5. Review transport rules	Delete or tighten any rule that blindly lowers the spam score when senderdomain == recipientdomain.	Removes the special-treatment loophole.
6. Keep anti-spoof defaults	In Defender for Office 365 leave “Spoof intelligence” and “Unauthenticated sender indicators” enabled.	Microsoft’s engine improves constantly; let it.
7. Turn on Reject Direct Send (if possible)	Set-OrganizationConfig -RejectDirectSend $true	Closes the anonymous port-25 path once and for all.
8. Monitor continuously	Forward DMARC aggregate reports to a parser (Azure Workbook, DMARCian, Postmark, etc.). Alert on any new source IP for your domain.	Early warning that someone is trying to impersonate you.
9. Train users	Emphasise that an internal display-name is not proof of legitimacy. Provide clear steps for verifying unusual requests.	Your last line of defence is an informed employee.
10. Enforce MFA everywhere	Especially on privileged accounts.	Limits the damage even if a credential phish succeeds.

---

6. Case Study: Blocking a Live Direct Send Attempt

One client I work with discovered several “missed fax” messages reaching employees overnight. Headers showed spf=softfail and dmarc=fail, yet the emails sat in primary inboxes because a years-old transport rule marked any @company-internal.com sender as “trusted.”

Fix in three moves

1. Replaced the ~all soft-fail in SPF with -all and added the factory scanner’s single static IP as an ip4: mechanism.
2. Switched DMARC from p=none to p=quarantine.
3. Deleted the blanket “lower spam score for internal domain” rule and created a new rule: “If message authentication fails and sender is internal, send to quarantine.”

Result: the next wave of spoofed faxes will hopefully hit the filter, logged as “High confidence phishing,” and never reach the users 🙂

---

7. Looking Ahead

Microsoft’s roadmap hints at further changes:

• Default-deny Direct Send for all tenants created after 2025.
• TLS enforcement on any remaining anonymous SMTP endpoints.
• Automated ML-based internal spoof detection baked into Defender for Office 365 standard licensing tiers.

In other words, the platform will get safer by default, but only if administrators avoid punching holes through the defaults for the sake of convenience. If you must override a protection, document the reason, restrict the scope and set a review date.

---

8. Final Thoughts

Direct Send is neither broken nor obsolete; it just carries the same risk as any anonymous internet-facing service: if you don’t police the entry point, someone else will exploit it. The phishing campaigns you’ve read about thrived on soft-fail SPF records, lax DMARC policies and “internal = safe” assumptions—not on any flaw in the underlying standards.

Lock down authentication, enforce failures, retire legacy rules, and the so-called “bypass” disappears. Better yet, flip the -RejectDirectSend switch and remove the attack surface entirely.

Either way, remember the golden rule of modern email security:

Never trust a message solely because it looks like it came from inside.
Verify the sender; let the system enforce the rest.

Do that, and your organisation can continue to reap the productivity benefits of Microsoft 365—without handing phishers an easy win.

Sources

BleepingComputer – Mitigations for Direct Send Phishing (Lawrence Abrams)bleepingcomputer.com

Microsoft Learn – How to Set Up a Multifunction Device or Application to Send Email (Direct Send)learn.microsoft.com

Microsoft Tech Community – “Introducing more control over Direct Send in Exchange Online” (Exchange Team Blog)techcommunity.microsoft.com

Varonis Threat Labs – Ongoing Campaign Abuses M365 Direct Send (Phishing Research)varonis.com

BleepingComputer – “Microsoft 365 ‘Direct Send’ abused to send phishing as internal users”bleepingcomputer.com

AdminDroid Blog – Why You Should Disable Direct Send in Exchange Online (Best Practices)blog.admindroid.com

Microsoft Learn – Anti-spoofing Protection in Defender for Office 365learn.microsoft.com

CIO Landing (IT Security Blog) – New Phishing Tactic Bypasses Email Security Using Direct Sendciolanding.com

Enjoy summer 🙂