Microsoft 365 Direct Send: How to Find, Restrict and Block Abuse

Direct Send lets devices and applications deliver mail straight to your Microsoft 365 MX endpoint using your own domain as the sender, and anyone who can reach that endpoint can submit messages the same way. That makes it a route for internal-looking phishing if the tenant has not decided who is allowed to use it. This guide explains how Direct Send works, how to find out who in your organisation relies on it, how to move legitimate senders to an authenticated or connector-based route, and how to turn on the RejectDirectSend setting safely. It is for Exchange Online administrators, email security engineers and SOC analysts. It complements the broader Email Security Guide and the Exchange Online Security Guide, which it does not repeat.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Direct Send is anonymous by design. Microsoft documents it as port 25 to your MX endpoint with authentication "None", for sender addresses in any accepted domain, delivering only to recipients in your own tenant.
• The tenant controls it. Set-OrganizationConfig -RejectDirectSend $true makes Exchange Online reject anonymous messages from your accepted domains that do not match an inbound connector identified by sender IP or certificate.
• Inventory before you block. Printers, scanners, line-of-business apps and third-party senders often use Direct Send quietly. Find them first, then move them to SMTP AUTH client submission or an SMTP relay connector.
• DMARC at reject backs it up. With your own domains at p=reject and "Honor DMARC record policy" on, spoofed mail that fails DMARC is rejected during SMTP.
• Watch intra-org spoof signals. Headers such as compauth=fail reason=6xx and SFTY:9.11 mark intra-org spoofing and are the starting point for detection.

How Direct Send works

Microsoft describes three ways for a device or application to send mail through Microsoft 365. The table summarises Microsoft's own comparison so you can see why Direct Send needs attention.

Because Direct Send messages arrive like anonymous internet mail, Exchange Online Protection scanning still applies. Microsoft recommends Direct Send only for advanced customers who can take on email server administration, and only when a legacy device or application supports no other method. Its documentation also notes that Microsoft is working on an option to disable Direct Send by default; check the current page for status.

Why it needs a tenant decision

An outside sender who knows your MX hostname can connect on port 25 and submit a message with a From address in one of your accepted domains, addressed to your own users. The message never touches your mail servers or a licensed mailbox, so controls that focus on account sign-in do not see it. The lure looks internal: a voicemail notice, a scanned document, an HR policy update. This maps to MITRE ATT&CK T1566 Phishing, with link and attachment variants in T1566.002 and T1566.001.

Whether a spoofed message is delivered depends on your email authentication posture and anti-spoofing settings. Microsoft's composite authentication combines SPF, DKIM and DMARC results, and a composite failure alone does not always block a message; spoof intelligence and anti-phishing policy then decide. That is why the tenant-side settings below matter. See the DMARC, SPF and DKIM Guide.

Finding who uses Direct Send today

Before changing anything, build an inventory of legitimate Direct Send senders. Typical sources:

• Multifunction printers and scanners: scan-to-email configured with the MX hostname as smart host.
• Line-of-business and monitoring applications: alerting, ticketing and building management systems that send notifications to staff.
• Third-party services: payroll, HR or marketing platforms that send to your users as your domain from their own infrastructure.
• Your SPF record: IP addresses and include mechanisms added for devices are clues; Microsoft's guidance for Direct Send recommends a static IP in SPF.

How to find them (NHI Mgmt Group approach; Microsoft does not publish a single Direct Send report procedure): use message trace in the Exchange admin centre to look for messages from your own accepted domains that arrived anonymously and did not pass through an inbound connector, and review message headers for intra-org spoof signals (below). Ask facilities and application owners which devices have the MX hostname configured. Record each sender's IP, sending address, owner and business purpose.

Moving legitimate senders to an authenticated route

Connector path: in the Exchange admin centre go to Mail flow, Connectors, Add a connector. For your own servers choose "Your organization's email server" as the source and select "Verify the subject name on the certificate" (Microsoft's recommended option) or "Verify the sending server's IP address" with addresses that belong exclusively to you. Then use the Validate step. For partners, Microsoft documents options to require TLS and restrict by sender domain or IP. RejectDirectSend only honours inbound connectors that match on sender IP or certificate, so a connector scoped by domain alone will not exempt a sender.

Turning on RejectDirectSend

RejectDirectSend is a Boolean parameter of Set-OrganizationConfig, available only in Exchange Online. When set to $true, Exchange Online rejects anonymous messages sent from your own domain to your organisation's mailboxes when both conditions are met: the message does not match an inbound connector configured to match the sender IP or certificate, and the domain in the MAIL FROM (5321.MailFrom, envelope sender) address is one of your accepted domains.

1. Check the current value: in Exchange Online PowerShell run Get-OrganizationConfig | Format-List RejectDirectSend.
2. Finish the inventory: every legitimate sender must use SMTP AUTH, or match an inbound connector by IP or certificate.
3. Announce a change window: tell device and application owners the date and what a rejection will look like (a non-delivery response to the sending system).
4. Enable: Set-OrganizationConfig -RejectDirectSend $true.
5. Monitor for a week: watch message trace and help desk tickets for failed scan-to-email and application alerts, and fix by moving the sender to a supported route.
6. Roll back if business-critical mail breaks: Set-OrganizationConfig -RejectDirectSend $false, fix the sender, then re-enable. Keep rollback windows short.

Note the scope: the setting applies to messages whose envelope sender is one of your accepted domains. Spoofing that uses a different envelope domain is handled by DMARC and anti-spoofing, which is why the next section matters too.

Layered controls: DMARC, anti-spoofing and allow lists

• DMARC at reject for your domains: Microsoft's recommended rollout is p=none with aggregate report monitoring, then p=quarantine ramped with pct, then p=reject, subdomains first and the parent last. Parked domains and the onmicrosoft.com domain should carry v=DMARC1; p=reject.
• Honour DMARC inbound: with "Honor DMARC record policy when the message is detected as spoof" turned on in the anti-phishing policy, mail failing DMARC from a p=reject domain is rejected during SMTP. Check with Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction.
• Spoof intelligence: keep it on in anti-phishing policies and review the spoof intelligence insight, which shows detected spoofed senders from the last seven days.
• Minimise allow lists: Microsoft advises avoiding allowed sender and allowed domain lists in anti-spam policies, because senders on them bypass most filtering. Remove entries that were added for your own domain to "fix" device mail.
• Tenant Allow/Block List: use spoofed-sender allow entries only as a short-term fix for a named partner while authentication is corrected.

Decision guidance

• Small organisations with a few printers: move devices to SMTP AUTH or a cloud print or scan service, then enable RejectDirectSend. The inventory is short.
• Large organisations with many devices: put an internal relay in front of devices, identify it with a certificate-based connector, then enable RejectDirectSend. This concentrates the change on one route.
• Heavy third-party senders: ask each provider to send from an aligned subdomain with its own SPF and DKIM, or scope a partner connector by IP or certificate.
• When to wait: if you cannot yet identify all senders, start with DMARC at quarantine, honour DMARC inbound and detection, and set a date for RejectDirectSend rather than leaving it open-ended (NHI Mgmt Group recommendation: within one quarter).

Where identity fits

Devices and applications that send mail are non-human identities. Moving them off Direct Send gives each one an accountable identity: a mailbox using OAuth, or a connector bound to a certificate whose private key you control. Record an owner for each, store any credentials in a secrets manager, and review them when the device or application is retired. A connector certificate needs renewal and revocation planning like any other machine credential. See the Secrets Management Guide.

Detection and measurement

Metrics:

• Number of legitimate Direct Send senders remaining, trending to zero.
• RejectDirectSend state, checked weekly as part of configuration drift monitoring.
• Intra-org spoof detections per week, before and after enablement.
• Percentage of your sending domains and subdomains at p=reject.
• Count of allow-list entries covering your own domains.

See the Microsoft 365 Unified Audit Log Guide for Detection for tracking configuration changes such as Set-OrganizationConfig.

Common failure patterns

• Enabling without an inventory. Scan-to-email and alerting stop overnight, and the setting is reverted under pressure. Inventory first.
• Domain-only partner connectors. RejectDirectSend considers only connectors that match on sender IP or certificate, so domain-scoped connectors do not exempt the partner.
• Allow-listing your own domain. Adding your domain to an anti-spam allow list to make device mail arrive also lets spoofed mail through.
• DMARC stuck at p=none. Without quarantine or reject, spoofed messages that fail DMARC are left to other filters.
• Shared IP ranges in connectors. Using a cloud provider's broad range in a connector lets other tenants of that provider match it. Use addresses that belong only to you, or certificates.
• Setting it once and forgetting it. Without drift monitoring, a later troubleshooting change can switch the setting off unnoticed.

Framework mapping

Practitioner checklist

• Run Get-OrganizationConfig and record the current RejectDirectSend value.
• Inventory every device, application and third party that sends to your users as your domain.
• Move each sender to SMTP AUTH with OAuth, a certificate or dedicated-IP connector, or an aligned subdomain.
• Remove anti-spam allow-list entries covering your own domains.
• Bring your domains to DMARC p=reject and confirm HonorDmarcPolicy is on.
• Enable RejectDirectSend in a planned window with a tested rollback.
• Alert on intra-org spoof signals and on changes to RejectDirectSend.
• Assign an owner and review date to every connector certificate and sending identity.

Standards and references

• Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365
• Microsoft Learn: Set-OrganizationConfig (RejectDirectSend parameter)
• Microsoft Learn: Set up connectors to route mail between Microsoft 365 and your own email servers
• Microsoft Learn: Set up connectors for secure mail flow with a partner organisation
• Microsoft Learn: Anti-spoofing protection in Microsoft 365
• Microsoft Learn: Set up DMARC to validate the From address domain
• MITRE ATT&CK: T1566 Phishing

Related NHI Mgmt Group resources: Email Security Guide · Exchange Online Security Guide · DMARC, SPF and DKIM Guide · Microsoft 365 Security Guide