The vulnerability: why Direct Send is a spoofing magnet

Direct Send was built for convenience. It lets devices such as printers and scanners, as well as legacy applications, send email without a dedicated account. The catch is in that last part: no account means no authentication. Anything that can reach your tenant’s MX endpoint on port 25 can hand it a message, and Exchange Online will deliver it.

Exploiting it doesn’t take much. Your MX endpoint follows a predictable pattern (contoso-com.mail.protection.outlook.com), so an attacker only needs your organization’s domain and a valid recipient to send phishing mail, without ever logging in to the tenant. They don’t need a compromised mailbox, stolen credentials, or malware. A one-line Send-MailMessage from any internet-connected box is enough, and defenders have seen this in the wild.

Why it works so well:

  • It looks internal. The From address is your own domain, so the message reads like it came from HR, payroll, or the CEO.
  • It rides Microsoft’s infrastructure. Because messages are routed through Microsoft’s own systems, they can evade initial filters by being treated as internal email.
  • Users trust internal mail. People are trained to be suspicious of external senders, not their coworkers.

This is actively exploited. Varonis Threat Labs uncovered a campaign targeting more than 70 organizations, where emails looked like voicemail notifications with PDF attachments containing QR codes that led to credential-harvesting pages. The QR code is deliberate: it pushes victims onto their phones, outside managed endpoint protections. KnowBe4’s Threat Lab observed 29,785 confirmed phishing emails abusing Direct Send across July and August 2026.

Here’s what Direct Send abuse looks like in message headers:

X-MS-Exchange-Organization-AuthAs: Anonymous
received-spf: Fail (protection.outlook.com: domain of <domain> does not designate <ip> as permitted sender)
authentication-results: spf=fail smtp.mailfrom=<domain>; dkim=none; dmarc=fail action=none
x-ms-exchange-crosstenant-fromentityheader: Internet

The sender is your domain, but the connecting IP is external and unknown. SPF, DKIM, and DMARC fail. No inbound connector is attributed. That combination means someone outside your tenant is spoofing your domain.

Microsoft’s answer is the RejectDirectSend switch, introduced in April 2025. Here’s how to roll it out without breaking the equipment that actually needs it.

1. Check where you stand

Connect-ExchangeOnline
Get-OrganizationConfig | Select-Object Name, RejectDirectSend

False means you’re still accepting anonymous mail spoofed as your domain. True means you’re already protected.

2. Find out who’s actually using Direct Send

Before you flip the switch, inventory your legitimate senders: the copiers, scanners, and LOB apps that rely on Direct Send. In Defender Advanced Hunting, run this query across the past 30 days:

let myDomains = dynamic(["contoso.com", "contoso.mail.onmicrosoft.com"]);
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where SenderFromDomain in~ (myDomains)
| where isempty(Connectors)
| summarize Count=count(), Senders=make_set(SenderFromAddress, 25) by SenderIPv4
| sort by Count desc

The results show inbound mail spoofing your domain without an inbound connector. The IPs you recognize are your devices. The ones you don’t are the problem.

Pay attention to the sender addresses too. If you see scanner@contoso.com or printer-hq@contoso.com repeatedly from the same IP, that’s a Direct Send appliance. If you see random mailboxes from odd IPs, that’s abuse.

3. Give legitimate senders a front door

For each known sender IP, create an inbound connector so the tenant can attribute its mail and bypass the Direct Send block:

New-InboundConnector -Name "DirectSend-Allow-Scanner-HQ" `
    -ConnectorType Partner `
    -SenderDomains * `
    -SenderIPAddresses 203.0.113.10 `
    -RestrictDomainsToIPAddresses $true `
    -RequireTls $false

Keep the IP list tight. A connector covering a /24 or wider just reopens the hole you’re closing.

If the device also needs to send mail to external recipients, use -ConnectorType OnPremises instead, which lets it relay through the tenant to internet destinations. If the appliance can present a TLS certificate, use cert-based authentication instead of IP:

# TlsSenderCertificateName = the SMTP domain on a publicly trusted cert, not a CN= subject
# RestrictDomainsToCertificate = only mail presenting that cert can use the connector
New-InboundConnector -Name "DirectSend-Allow-Printer-Cert" `
    -ConnectorType Partner `
    -SenderDomains * `
    -TlsSenderCertificateName "printer.contoso.com" `
    -RestrictDomainsToCertificate $true `
    -RequireTls $true

-TlsSenderCertificateName takes the SMTP domain on the certificate (wildcards such as *.contoso.com work), so an internal .local name won’t match. Without -RestrictDomainsToCertificate, the certificate doesn’t decide which senders can use the connector. With it, cert-based connectors are stronger than IP pinning because the appliance has to prove its identity on every connection.

4. Flip the switch

Set-OrganizationConfig -RejectDirectSend $true
Get-OrganizationConfig | Select-Object RejectDirectSend

Give the change about 30 minutes to propagate across all edge servers. Any unauthorized sender will now bounce with:

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

5. Verify the fix

Send a test from a device behind an allowed IP:

Send-MailMessage -SmtpServer "contoso-com.mail.protection.outlook.com" -Port 25 `
    -From "scanner@contoso.com" -To "you@contoso.com" `
    -Subject "Direct Send test" -Body "If you see this, the connector works."

Check Advanced Hunting to confirm the Connectors column shows your connector name. If you get a 5.7.68 bounce instead, the egress IP the tenant sees doesn’t match the connector—usually NAT on your network. Work with your infrastructure team to find the real public IP the appliance uses.

If something critical breaks, rolling back takes one line:

Set-OrganizationConfig -RejectDirectSend $false

But don’t stop there.

Don’t leave the door cracked open

RejectDirectSend only covers spoofing of your accepted domains. While you’re in there, tighten your mail authentication:

  • Audit and remove legacy allow lists. Transport rules that set SCL to -1 (skip spam filtering) or allow lists that include your own domain weaken your defenses. Remove them.
  • Lock down SPF. Make sure your SPF record ends with -all, not ~all. The tilde is a soft fail; the dash is a hard fail.
  • Move DMARC to enforcement. Change p=none to p=quarantine (safer for a first rollout) or p=reject (if you’re confident in your SPF and DKIM). Monitor rua reports for a few weeks before you reject.
  • Enable anti-phish impersonation protection. Make sure Microsoft’s anti-phishing rules cover lookalike domains and unusual mailbox activity from your own domain.

Direct Send made sense when every office had a copier and spoofing wasn’t a threat. That time is over. Turn it off, keep your printers working, and move on.

Key takeaways

  1. Direct Send is unauthenticated SMTP to your tenant’s MX endpoint, and it’s actively exploited for internal-looking phishing.
  2. Find your legitimate senders first in Defender Advanced Hunting before you enable RejectDirectSend.
  3. Inbound connectors let you whitelist specific IPs or certificates so your devices can still send mail.
  4. IP-based connectors are good; cert-based connectors are better.
  5. RejectDirectSend is one layer. SPF, DKIM, DMARC, and anti-phish rules are the rest.

References