Direct Send: The Phishing Vector You May Have Missed

During a recent red team engagement, we uncovered an unexpected gap in a client’s Microsoft 365 mail flow. While testing external ingress routes, we found that their Exchange Online Protection (EOP) service would happily accept unauthenticated SMTP traffic, a behaviour commonly referred to as Direct Send.

Direct Send is a method that allows devices and applications (like printers, scanners, or line-of-business apps) to send email through Microsoft 365 without authentication, as long as the email is sent to recipients within your own Microsoft 365 organisation.

Direct Send isn’t a new phishing vector; it’s been around for years. The technique has long been known to red teamers and attackers alike, primarily because of how it allows email delivery without authentication as long as the message originates from the right region and targets an accepted domain. What makes it relevant today isn’t novelty, but persistence: many organisations still overlook it, and it continues to crop up during assessments as a way to get mail delivered that looks like it came from inside the tenant.

The Basics

By walking through a simple SMTP handshake (EHLO → MAIL FROM → RCPT TO), we were able to demonstrate that spoofed internal addresses could be accepted by the tenant’s mail servers, and this could be abused by sending phishing emails.

From the perspective of an unauthenticated external attacker, the goal is simple:

Can I talk directly to your tenant’s mail servers without logging in or being on your network?

To simulate this, we connected straight to the organisation’s MX records (the public-facing mail exchangers published in DNS) via telnet. These are the same servers that accept inbound email from the internet. These are smart hosts created with the default Exchange Online instance and are usually found on

company-com[.]mail[.]protection[.]outlook[.]com

Once connected on port 25 (SMTP), we ran through the initial stages of a conversation that any mail server expects:

EHLO attacker.example – introducing ourselves.

MAIL FROM:<spoofed.internal@yourdomain.com>  - pretending to be a trusted sender inside the organisation.

RCPT TO:<target.user@yourdomain.com> - nominating a real employee as the recipient.

At this point, if the server accepts both commands without complaint, we’ve already learned something critical: the tenant is prepared to relay mail as if it came from itself, without any authentication. We deliberately stopped at this point before the DATA command (which would deliver content). This ensures no email was actually sent.... Yet.

From an attacker’s view, that’s all the encouragement they’d need. They now know they can attempt to deliver spoofed phishing messages that appear internal, greatly increasing the chance of user trust.

Some Caveats

When testing Direct Send, there are a few practical issues worth keeping in mind:

• Residential IP addresses are often blocked instantly by SPAMHAUS, making them unreliable for testing. Below is a response you will see if this is the case.

The server response was: 5.7.1 Service unavailable, Client host [x.x.x.x] blocked using Spamhaus. To request removal from this list see https://www.spamhaus[.]org/query

• Regional mismatches can cause problems. For example, connecting from the UK into a European ingress point (like Oslo) may trigger an ATTR35 error (wrong Office 365 region).

451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35.

• Cloud environments (Azure VMs, Azure Cloud Shell, and many VPS providers) generally block outbound port 25, so they’re not viable for Direct Send.

  
  

To avoid ATTR35 we needed an egress IP in the same Office 365 region as the tenant. I determined that region by analysing message headers from benign OSINT emails, the EHLO response and the PTR/reverseDNS pointed to Oslo (Norway).

I used Microsoft's own Message Header Analyser to do this.

Here is a sample of the Antispam Headers disclosing location:

HELO/EHLO String
OSPPR0XXXXXX[.]outbound[.]protection[.]outlook[.]com
PTR Record
mail-norwayeastazlpXXXXXXX[.]outbound[.]protection[.]outlook[.]com

After switching my exit node to an IP from that region via VPN, the ATTR35 routing rejection disappeared.

Another key observation: tenants with DMARC set to "none" were far more permissive. Where policies like p=quarantine were present, spoofed messages often landed in quarantine instead of inboxes.

From POC to delivery

With everything in place, I wrote a PowerShell script that uses .NET classes like System.Net.Mail.MailMessage to send emails. This approach allowed me to format the email body in HTML.

The script worked against a list of recipients, and we built in a delay between sends to avoid overwhelming the mail server. Without throttling, we quickly hit errors like:

The server response was: 4.7.500 Server busy. Please try again later

By slowing things down, delivery became far more reliable and messages consistently were sent to recipients’ inboxes rather than being deferred or rejected.

One interesting observation was how bounce-backs were handled. Any undeliverable message, Out of Office or failure notification wasn’t just lost; it went straight to the inbox of the sender account we had specified. This is worth bearing in mind when deciding which mailbox you use as the "from" address, especially in larger campaigns or during Red teams, where you may get a lot of invalid addresses or auto-responses, which could burn the attack vector or campaign.

The messages that were accepted looked very credible, which underscores how convincing Direct Send abuse can be. That said, they’re still subject to the usual anti-phishing controls (spam filters, Safe Links, Safe Attachments, DMARC/DKIM/SPF checks), so you must be deliberate when crafting content. For the Red Team campaign, I fed an HTML file into the PowerShell script as the email body, which made it easy to generate polished, realistic layouts while still keeping the test controlled and non-malicious.

Overall, this exercise was a useful way to understand how PowerShell can be extended with .NET for email automation, and it highlighted some of the practical considerations (like throttling and handling non-delivery reports) that come up when moving from a proof-of-concept to something approaching a production-ready workflow.

Recommendations

Apply a reject-level DMARC policy (p=reject).

Configure the Exchange Admin Center to block direct send.

Closing Thoughts

Direct Send is not sophisticated, but that’s exactly why it persists. Many organisations overlook it, and attackers continue to abuse it. By enforcing strong SPF/DMARC policies and shutting down unnecessary relay paths, defenders can close this gap and make it much harder for spoofed internal messages to reach inboxes.