How To
Summary
Phishing emails continue to be delivered into Microsoft 365 despite Direct Send being disabled. Although many unwanted emails are blocked, a few still bypass filters, often containing QR codes or attachments, possibly due to phishing or internal email impersonation.
Cause:
The root cause is usually tied to some phishing emails being sent via methods that bypass filtering, such as through an ESMTP server or PowerShell, indicated by the source IP being the loopback address (127.0.0.1). These emails are treated as internal submissions and thus evade filtering services and transport rules. Additionally, mail flow through third-party filtering services without strict inbound connector restrictions allows unauthorized emails to be delivered
Objective
In the message headers, you will identify the bypass method. The recommendation is enabling the RejectDirectSend setting in Exchange Online to block direct send relay usage. Microsoft also advise configuring a Partner Inbound Connector to accept mail only from trusted third-party filtering services by restricting sender IP addresses or certificates.
Steps for blocking Direct Send Relay Method to prevent unauthorized use of the direct send relay method, Microsoft recommend enabling the RejectDirectSend setting in your Exchange Online organization.
Environment
Steps
This can be done using PowerShell with the following commands:
Get-OrganizationConfig | Select-Object Identity, RejectDirectSend
Then, Set-OrganizationConfig -RejectDirectSend $true
This configuration ensures that messages sent using direct send are rejected, helping to prevent spoofing and unauthorized relay.
Securing Mail Flow via Third-Party Filtering Services
Example: If your MX records point to a third-party filtering service (not Microsoft), it's important to ensure that only mail routed through this trusted service is accepted by Exchange Online.
To mitigate risks and enforce this routing, we recommend creating a Partner Inbound Connector. This connector should be configured to accept mail only from your trusted third-party service using either:
TlsSenderCertificateName (preferred), or
SenderIpAddresses
Additionally, set the corresponding parameters RestrictDomainsToCertificate or RestrictDomainsToIPAddresses to $true to enforce the restriction.
Here's an example command using IP address restriction:
New-InboundConnector -Name "Reject mail not routed through MX (third-party service name)" ` -ConnectorType Partner ` -SenderDomains * ` -RestrictDomainsToIPAddresses $true ` -SenderIpAddresses <#static list of on-premises IPs or IP ranges of the third-party service#>
You can reference Microsoft’s article pertaining to, “use connectors to configure mail flow/manage mail flow using third-party-cloud”
Additional Information
NOTE: You can continue using the existing connector if it already includes all the IPs you intend to add with the new configuration.
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
08 August 2025
UID
ibm17241856