Microsoft 365 Direct Send spoofing: how it works and how to block it

Some phishing emails look as if a colleague sent them: your own domain in the From address, a familiar name, delivered straight to the inbox. One way attackers do this is by abusing Microsoft 365 Direct Send, a legacy route for printers and apps that needs no sign-in. This guide explains how the abuse works, what Microsoft's Reject Direct Send setting does and doesn't block, and what to check before you turn it on.

What is Direct Send in Microsoft 365?

Direct Send is one of the ways Microsoft lets devices and applications send email when your mailboxes are in Microsoft 365. Microsoft describes it as "Send unauthenticated email as an external email server directly to Microsoft 365 or Office 365."

The device connects on port 25 to your tenant's MX endpoint, which follows the pattern contoso-com.mail.protection.outlook.com, and sends from any address in one of your accepted domains. The address doesn't need a mailbox. Microsoft lists these limits:

• It "can't deliver email to external recipients."
• Messages "are just like anonymous email from the internet (all scanning and protections apply)."
• No credentials are needed. Microsoft recommends an SPF entry for the sending IP, plus DKIM and DMARC, because "misconfiguration can lead to security gaps."

Microsoft is direct about who should use it: "Most customers don't need to use Direct Send," and it's recommended "only for advanced customers willing to take on the responsibilities of email server admins." The same page says Microsoft is "working on an option to disable Direct Send by default to protect customers."

If you're choosing how a scanner or app should send, our guide to scan to email with Microsoft 365 compares the options.

How do attackers abuse Direct Send?

The weakness is simple: anything a printer can do, an attacker can do too.

1. The attacker looks up your MX record, or simply guesses your tenant endpoint. Microsoft's own post says the endpoint "is not supposed to be a secret, and anyone can guess what it is" (Microsoft Tech Community).
2. From any server on the internet, they connect on port 25 and send a message with a MAIL FROM and From address in your domain, such as payroll@yourdomain.com.
3. The recipient is one of your staff. Because Direct Send only delivers to your own organization, that's exactly where the attacker wants it.
4. The message arrives looking internal: a voicemail notice, a payroll update, a shared document or an MFA reset, often with a link, QR code or attachment.

No account is compromised and no password is stolen to send it. That's why this route appeals to attackers: it produces spoofed "internal" mail without any of your credentials.

Doesn't SPF, DKIM and DMARC stop this?

They should stop much of it, which is why your authentication setup matters. The spoofed message comes from an IP that isn't in your SPF record and carries no valid DKIM signature for your domain, so it fails DMARC. Microsoft calls this intra-org spoofing: sender and recipient in the same organization. Spoof intelligence and your anti-phishing policy then decide what happens to it. Messages that fail composite authentication for this reason carry compauth=fail reason=6xx and SFTY:9.11 in their headers (Microsoft Learn).

Microsoft's FAQ on Direct Send says that "with a properly configured tenant and domain, spoofed emails will fall foul of existing authentication checks that are in place to deflect suspicious messages away from inboxes to junk folders or quarantine depending on settings."

The gaps appear when:

• DMARC isn't enforced. With p=none, or no DMARC record, Microsoft has to decide on its own, and Microsoft notes that "a composite authentication failure doesn't directly result in blocking a message." Our DMARC setup for Microsoft 365 guide shows how to reach enforcement.
• Allow lists bypass checks. Microsoft warns that senders in user allowlists "bypass parts of the filtering stack, including spoof protection," and allowed domain lists in anti-spam policies bypass most of it. An entry allowing your own domain is a classic mistake.
• Junk isn't safe enough. Even a message filtered to Junk Email can be opened by a curious user.

Reject Direct Send closes the gap by refusing these messages at the door.

What does RejectDirectSend do?

Microsoft announced the setting as a Public Preview on April 28, 2025. As of the post's last update (May 2026), it still calls the feature a Public Preview and says a separate communication will announce general availability. The cmdlet reference says that with $true, Exchange Online "rejects anonymous messages sent from your own domain to your organization's mailboxes" when both of these are true:

• The anonymous incoming messages "don't match any inbound connectors." Only connectors "configured to match the sender IP or certificate" count.
• The domain in the MAIL FROM address (the 5321.MailFrom, P1 sender or envelope sender) "is an accepted domain in your organization."

Details from Microsoft's announcement:

Microsoft also says it plans "to enable this feature in the future for new tenants by default," and that new tenants won't be able to turn it off. At the time of writing (October 2026), check the announcement's change log for the current status before you rely on either point.

You can confirm your current value with Get-OrganizationConfig | Format-List RejectDirectSend.

What RejectDirectSend doesn't do

• It doesn't stop spam from other domains delivered straight to your tenant. Microsoft's FAQ is explicit: if your MX points to another service and someone bypasses it, RejectDirectSend "will only reject emails where the P1 sending domain (envelope sender), is an accepted domain in the tenant."
• It doesn't check the visible From. A message with a stranger's envelope sender and your domain in the header From is still left to anti-spoofing and DMARC.
• It doesn't stop lookalike domains like yourdomain-hr.com. See lookalike domain phishing.
• It doesn't replace authentication. Microsoft says the parameter "joins many layers of protection," and you still need SPF, DKIM and DMARC.

If your MX points to a filtering service, the main control is locking your tenant so it only accepts mail from that service. Our guide to blocking direct-to-tenant bypass covers the restricted Partner connector. RejectDirectSend is a useful extra on top.

What should you check before enabling it?

The risk is rejecting something legitimate. Work through this list first.

1. Find current Direct Send traffic. Microsoft suggests a historical message trace report of inbound mail received without a connector, available for the last 90 days:

   Start-HistoricalSearch -ReportTitle DirectSendMessages -StartDate <start> -EndDate <end> `
     -ReportType ConnectorReport -ConnectorType NoConnector -Direction Received -NotifyAddress <you@yourdomain>
   

   The Inbound messages report under Exchange admin center > Reports > Mail flow shows the same view. Microsoft also added a Change Optics Report, in public preview, that shows Direct Send traffic. If your MX points straight to Microsoft 365, these reports include all internet mail, so filter for envelope senders in your own domains.

2. List the usual suspects. Multifunction printers and scanners, line-of-business apps, alerting and monitoring tools, on-premises servers, website forms, and SaaS services that send "as" your domain to your staff, such as HR, payroll, ticketing or e-signature platforms.

3. Check your SPF record. Microsoft suggests it as "a good place to start": senders listed there are often the ones using Direct Send.

4. Give each legitimate sender a proper route. Options are SMTP client submission with a mailbox, an SMTP relay connector, or a partner inbound connector that matches the sender's certificate (preferred) or static IP. Our guide to Microsoft 365 connectors explains the connector types. Microsoft says messages that hit the 5.7.68 error "need a partner connector created to authenticate their source as an approved sender."

5. Handle senders that can't use a connector. If a vendor has no fixed IPs or dedicated certificate, Microsoft suggests a mail flow rule that quarantines or redirects Direct Send traffic, with an exception for that vendor, instead of RejectDirectSend. Our mail flow rules for security guide covers the building blocks.

6. Know the forwarding edge case. Microsoft lists one known issue: a message you send to an outside party that they forward back to your organization, without Sender Rewriting Scheme, arrives with your own address as the envelope sender and "will be rejected outright."

How do you turn it on and test it?

1. Connect to Exchange Online PowerShell with an account that has the Organization Configuration role.
2. Run Set-OrganizationConfig -RejectDirectSend $true.
3. Wait at least 30 minutes.
4. From a server outside your network that isn't covered by a connector, send a test message to one of your mailboxes with a MAIL FROM in your domain. It should be rejected with 550 5.7.68.
5. Test each legitimate sender you moved to a connector. For a partner connector, Microsoft suggests checking attribution with Get-MessageTraceV2 -MessageId "<id>" | Get-MessageTraceDetailV2 | Format-List and looking for the connector name.
6. Watch for 5.7.68 rejections and helpdesk tickets for a week. To roll back, run Set-OrganizationConfig -RejectDirectSend $false.

How can you tell if a message came through Direct Send?

Open the message headers in the Email Header Analyzer and check:

• The first external Received line. Is the connecting IP one of yours or your filter's, or an unknown server?
• Authentication-Results. A spoof will show SPF failing for your domain, no aligned DKIM, and dmarc=fail. Look for compauth=fail reason=6xx.
• X-MS-Exchange-Organization-AuthAs. Microsoft's example rule treats a value of Internal as authenticated; anonymous Direct Send messages won't have it.

If you find spoofs that reached inboxes, treat it as an incident: search for the same message across mailboxes, remove it, and check whether anyone clicked. Our guide to someone sending email from my address covers telling spoofing apart from a hacked account.

Next steps

• Check whether your domain's DMARC policy is enforcing with the DMARC Checker, and review your SPF record with the SPF Checker.
• Run the no-connector inbound report and list every legitimate Direct Send sender.
• Move those senders to a connector or authenticated submission, then turn on RejectDirectSend.
• If your MX points to a filter, lock your tenant to that filter as described in blocking direct-to-tenant bypass. The iBlockSpam setup wizard shows the IP ranges and certificate name for that connector.

Browse our other phishing and threat guides.