Blog Post

Exchange Team Blog

8 MIN READ

Introducing more control over Direct Send in Exchange Online

Platinum Contributor

Apr 28, 2025

Update 8/12/2025: Added the FAQ to the post. Also, to help shed more light on the Direct Send feature, we published a newer post called Direct Send vs sending directly to an Exchange Online tenant.

Direct Send is a method used to send emails directly to an Exchange Online customer’s hosted mailboxes from on-premises devices, applications, or third-party cloud services using the customer’s own accepted domain. This method does not require any form of authentication because, by its nature, it mimics incoming anonymous emails from the internet, apart from the sender domain.

The Direct Send method assumes that customers have properly configured SPF, DKIM, and DMARC for their tenants. It is critical that an administrator updates their SPF record by adding the source IP address where the device, application, or third-party service will send from to prevent emails from being flagged as spam. If SPF is not properly configured, any email sent using Direct Send will likely be flagged as spam.

While SPF provides protection from spoofing of your domains, we recommend customers use a Soft Fail SPF configuration due to the possibility of valid routing scenarios falling foul of SPF failures. As such, no feature existed to block Direct Send traffic for the many customers who have no need to use it. To this end we have developed the Reject Direct Send setting for Exchange Online and are announcing the Public Preview for this feature today.

Reject Direct Send setting

By its definition, Reject Direct Send covers anonymous messages sent from your own domain to your organization’s mailboxes. Enabling this setting will block any email sent to your tenant that is sent anonymously using an address that matches one of your accepted domains. The sending domain being an accepted domain in your tenant is a straightforward and easy condition to evaluate. For the sending domain, we are talking specifically about the P1 Mail From envelope sender address here. The P2 From header is not checked by this feature. “Anonymous” in this context means that the messages are not attributed to any mail flow connector when they are sent to Exchange Online.

Direct Send traffic may include 3rd party services that you have given permission to use your domain or one of your own email applications hosted on-premises. To avoid having these messages rejected when this feature is enabled, they need to be authenticated. This is done by creating a partner mail flow connector that matches the certificate (recommended) or IPs used to send the messages. Learn more about partner connectors here: Configure mail flow using connectors in Exchange Online.

Admins may currently not be tracking all senders who currently use Direct Send, but a good place to start would be with your domain’s SPF record. Any senders using Direct Send without being a part of the accepted domain’s SPF record will already be having a tough time getting messages delivered successfully into recipients’ inboxes.

How to enable this setting

By default, the new opt-in RejectDirectSend setting is set to False. To enable the Reject Direct Send feature, Exchange Online administrators can run the following PowerShell cmdlet:

Set-OrganizationConfig -RejectDirectSend $true

The change should propagate out to our entire service within 30 minutes. With the feature enabled, any received Direct Send messages will see the following message:

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

Unless Direct Send is re-enabled again, any messages that hit this error will need a partner connector created to authenticate their source as an approved sender.

Public Preview and Release Roadmap

This feature is being released as a Public Preview for admins to test and provide feedback. Some customers may not have the confidence to enable it due to a lack of tracking of Direct Send senders to their organization. Feedback including feature requests and bug reports may be sent to the follow address: directsend-feedback[AT]microsoft.com. Note: Feedback submitted here will not receive a reply. If you need to engage us with questions or issues regarding the feature, please comment below or go through the regular support channels.

You can also use the Exchange Online Feedback Portal to submit feature requests that other customers can then vote on. This avenue provides us with an extra layer of information to help make decisions on features.

We are working on creating a report for Direct Send traffic that admins can use to get an overview of what traffic will be impacted. This will make it easier for admins to identify and act on any legitimate traffic and enable the feature with confidence. We will provide updates here for that work. There is no fixed date for General Availability (GA) of this feature as it will depend on the feedback received. A separate communication will be sent out to announce GA.

We also plan to enable this feature in the future for new tenants by default. This is part of our effort to make your organizations more secure by default. Note that the plan includes new tenants being unable to disable this feature as we move to deter use of unauthenticated Direct Send traffic.

Known Issues

There is a forwarding scenario that could be affected by this feature. It is possible that someone in your organization sends a message to a 3^rd party and they in turn forward it to another mailbox in your organization. If the 3^rd party’s email provider does not support Sender Rewriting Scheme (SRS), the message will return with the original sender’s address. Prior to this feature being enabled, those messages will already be punished by SPF failing but could still end up in inboxes. Enabling the Reject Direct Send feature without a partner mail flow connector being set up will lead to these messages being rejected outright.
If you are using the Azure Communication Services (ACS) to send emails to your tenant, and if those emails are sent using a “MAIL FROM” address that is one of your Microsoft 365 accepted domains, enabling RejectDirectSend would block those emails sent to your Microsoft 365 tenant. A solution for ACS traffic to be compatible with the setting is being worked on. In case the domains used to send emails from ACS are not one of the Microsoft 365 accepted domains or sub-domains, enabling RejectDirectSend should not have an impact on ACS traffic. If ACS email traffic is using an Exchange Online domain where the MX is pointed to a 3rd party service, please refer to the FAQ’s below, which provide instructions on mail connectors required to enable traffic in Exchange Online.

Conclusion

We invite Exchange admins to try out the feature and provide feedback that we can use to validate it and proceed to offering this feature for General Availability.

FAQs

Must all customers enable the -RejectDirectSend parameter to consider themselves protected?
No. This parameter joins many layers of protection in Microsoft 365. It gives customers the strict ability to outright reject incoming Direct Send traffic they have not approved. 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. It is still true that without this layer your tenant is adequately protected against messages spoofing your own domains. Even with this setting enabled, those existing protection mechanisms are relied on to protect your mailboxes from other 3^rd party domain spoofing that is not considered Direct Send.

Customers who have pointed their MXes elsewhere should have already followed the advice here: Mail flow best practices when using a third-party cloud service with Exchange Online. All customers should be following the recommendations in Anti-spoofing protection for cloud mailboxes to protect them from spoofing.

Does the RejectDirectSend setting work even when the MX is pointed to a 3^rd party service?
Yes, it works when the MX is pointed to a 3^rd party service or when it is directly pointed to Exchange Online; there is no dependency on MX location. However, the recommended configuration when your MX points elsewhere is to have a connector is set up to receive the traffic from that service and exclude other traffic. With the recommended tenant configuration of a connector only allowing the 3^rd party service traffic, there is no possibility of unauthenticated Direct Send traffic reaching you and the Reject setting will never be utilized.

The MX record of our domain is pointing to a 3rd party service, and someone is directly sending email to our tenant bypassing the MX. Will -RejectDirectSend setting help us lock down our Exchange Online tenant to only accept mail from your third-party service?
No, -RejectDirectSend will only reject emails where the P1 sending domain (envelope sender), is an accepted domain in the tenant unless these are attributed to a configured Inbound connector.

If you do not want anyone to bypass your MX which is pointed to a 3^rd party service, you can achieved this by creating an Inbound connector as recommended on step 4 in the support article mail flow best practices when using a third-party cloud service with Exchange Online using either TlsSenderCertificateName (preferred) or SenderIpAddresses parameters (you need to mention the Certificate presented by the 3rd party or the IP Address of the 3rd party), then set the corresponding RestrictDomainsToCertificate or RestrictDomainsToIPAddresses parameters to $True. With this configured, only mail that passes through the inbound connector is allowed into your tenant, otherwise it will be rejected. To know more, please refer to Direct Send vs sending directly to an Exchange Online tenant.

We enabled -RejectDirectSend and created inbound connector for our partner that needs to send from our accepted domain. How can we confirm if the email from the partner is really attributing to that connector?
To see if the email from the partner is attributed to the connector, you can send a test email from the partner and run the following command (give it some time after sending the email so that the data is populated)

Get-MessageTracev2 -MessageId "your message ID here" | Get-MessageTraceDetailv2 | fl

In the output, you should be able to see the connector name similar to the following:

You can also see the connector name under email entity page (it will show the GUID of the connector).

We enabled RejectDirectSend, but the 3^rd party vendor that needs to send from our accepted domain doesn't have static IP ranges or a dedicated certificate that we can associate with a connector. How can we block the Direct Send but also allow this 3^rd party vendor to send email to our users using our accepted domain?
If the 3^rd party vendor doesn’t have IP ranges or a dedicated certificate, or you need more customization, you might consider using a Transport rule to quarantine or redirect Direct Send instead of blocking at the org config using RejectDirectSend setting. With a Transport rule, you could add exceptions specific to the 3rd party vendors. For example, if the 3^rd party vendors stamp a unique X-header you could use that. Here is an example of similar transport rule:

If the message is received from ‘Outside the Organization’ and the sender domain is ‘contoso.com’ deliver to hosted quarantine
Except if the message headers (add header and value).

(You can add any other action instead of quarantine)

What permission is required to set the RejectDirectSend parameter under organization config (Set-OrganizationConfig -RejectDirectSend $true/$false)
Editing the setting requires an administrator with the role "Organization Configuration" assigned.

How does RejectDirectSend affect P1 sending domain addresses that are a subdomain of an accepted domain?
-RejectDirectSend will impact email from P1 address that is a subdomain of an Accepted Domain, if that Accepted Domain has "Accept mail for all subdomains" enabled (MatchSubDomains=TRUE).

Changes to this post:

8/29/2025: Added a subdomain of accepted domain FAQ
8/12/2025: Added another known issue and FAQ to the post
8/4/2025: added a reference to What is Direct Send and how to secure it
7/30/2025: made a few clarifications in the text based on frequently asked questions in comments.

Microsoft 365 Messaging Team

Updated Aug 29, 2025

Version 12.0

Platinum Contributor

Joined April 19, 2019

View Profile

Exchange Team Blog

You Had Me at EHLO.

119 Comments

Maverick11
Copper Contributor
Aug 24, 2025
Hello Community, we currently have an inbound connector for Mimecast in Exchange Online. It is configured to verify IP addresses using Mimecast IPs but does not restrict domains to IP addresses. We also set up a transport rule to monitor traffic for potential direct send vulnerabilities. During monitoring, we noticed some emails bypass our connector. This includes calendar and Teams meeting invites, which appear to come from IPv6 addresses that seem to belong to Microsoft services. Is this expected behavior? We want to properly secure our inbound connector and would appreciate advice on the best approach. Should we create a new inbound connector that restricts domains to IP addresses and includes Mimecast IPs instead of enabling reject direct send? Would it be better to run both connectors for a period before disabling the old one? Could these changes affect calendar invites, Teams invites, or other legitimate Microsoft service emails or any other emails? Any recommendations or best practices for securing the inbound connector without impacting legitimate traffic would be greatly appreciated. Thank you.
- Carolyn_Liu
  Microsoft
  Aug 28, 2025
  1. Does "we currently have an inbound connector for Mimecast in Exchange Online" mean a Partner Inbound connector? If so, unless you check the Reject email messages if they aren't sent from within this IP address range checkbox in your Partner connector (step 9 in Set up a connector to apply security restrictions to mail sent from your partner organization to Microsoft 365 or Office 365 | Microsoft Learn), the connector was really enforcing the inbound emails to your organization. 2. Is your domain's MX pointing to Mimecast? If so I would discourage you to use IP addresses unless you have dedicated IP addresses from Mimecast, otherwise you have to monitor all Mimecast IP addresses, if they add a new one, your partner connector enforcement will end up rejecting emails from those new IPs. You probably should consider using mimecast certificate domain instead.
  - Maverick11
    Copper Contributor
    Aug 28, 2025
    Yes, we do have the dedicated IPs from Mimecast for our region. Also, can you please confirm on Calendar and meeting invites? Plus do you recommend enabling reject direct send as well or will that cause issues with Microsoft notifications and out of office replies?

fabulat0re

Copper Contributor

Aug 22, 2025

What happens to all the e-mail notifications from different M365 services (Teams, Voicemails, Planner Activities, Document Comments, ...)? Microsoft is pushing these mails into the Exchange Online tenant and ignoring the MX records, which are pointing to somewhere else (mailboxes are also on-prem).
From my point of view, these e-mails are delivered via Direct Send to the tenant. And yes, many of these e-mails they are sent from an Accepted Domain of the tenant!

Arindam_Thokder

Microsoft

Aug 22, 2025

Emails which are directly pushed to Mailbox does not go through Transport, so they won't get blocked. Also, most of the notifications are sent using Microsoft.com address and also Auth-as will be Internal (reaction notification for example), these won't be impacted either. If you have an example where notification email is sent using your accepted domain and auth-as is anonymous. Please share with us and we can work with the particular notification team to fix the issue.

Sebastian_Rottmann

Brass Contributor

Sep 01, 2025

PIM emails from entra aren't send. Maybe there is more but it's quiet hard to name something missing.

before your change those PIM related emails where send. they are sent to m365adminaccount_at_ourcompany.onmicrosoft.com and then forwarded to our user accounts onpremuseraccount_at_ourcompany.com (we don't allow admins to have to direct email accounts for security reasons).

further example when everything worked:

From: Microsoft Security <MSSecurity-noreply_at_microsoft.com>
Subject: PIM: You now have the Contributor role
Resent-From: <m365adminaccount_at_ourcompany.microsoft.com>
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 2a01:111:f403:c206::3) smtp.rcpttodomain=ourcompany.onmicrosoft.com
 smtp.mailfrom=microsoft.com; dmarc=pass (p=reject sp=reject pct=100)
 action=none header.from=microsoft.com; dkim=none (message not signed);
 arc=pass (0 oda=0 ltdi=1)
Received: from AS9PR06CA0324.eurprd06.prod.outlook.com
 (2603:10a6:20b:45b::13) by FR6P281MB4444.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:134::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8989.16; Fri, 1 Aug
 2025 07:31:58 +0000
Received: from AM2PEPF0001C70C.eurprd05.prod.outlook.com
 (2603:10a6:20b:45b:cafe::f3) by AS9PR06CA0324.outlook.office365.com
 (2603:10a6:20b:45b::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8989.14 via Frontend Transport;
 Fri, 1 Aug 2025 07:31:57 +0000
Authentication-Results: spf=pass (sender IP is 2a01:111:f403:c206::3)
 smtp.mailfrom=microsoft.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none
 header.from=microsoft.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com
 designates 2a01:111:f403:c206::3 as permitted sender)
 receiver=protection.outlook.com; client-ip=2a01:111:f403:c206::3;
 helo=CWXP265CU009.outbound.protection.outlook.com; pr=C
Received: from CWXP265CU009.outbound.protection.outlook.com
 (2a01:111:f403:c206::3) by AM2PEPF0001C70C.mail.protection.outlook.com
 (2603:10a6:20f:fff4:0:12:0:8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9009.8 via Frontend Transport; Fri,
 1 Aug 2025 07:31:57 +0000

dOLOb
Copper Contributor
Aug 19, 2025
Hi, I'm seeking some clarification on a sentence in the first FAQ "Must all customers enable the -RejectDirectSend parameter to consider themselves protected?"
It currently is written as, "With a properly configured tenant and domain, spoofed emails will fall of existing authentication checks that are in place to deflect suspicious messages away from inboxes to junk folders or quarantine depending on settings."
Should "fall of" be "fail"?
Thanks in advance.
- SeanMSFT
  Microsoft
  Aug 21, 2025
  That should be "fall foul of" the existing checks. Thanks, I'll get it corrected.
myaeger
Copper Contributor
Aug 13, 2025
I appreciate the latest article Direct Send vs sending directly to an Exchange Online tenant | Microsoft Community Hub. However, regarding the Transport Rule methodology for blocking mail sent directly to an Exchange Online tenant, there are still some gaps that using the "'X-MS-Exchange-Organization-AuthAs' header contains ''Internal''' header exception does not seem to cover. One is email coming from "noreply-at-yammer-dot-com" does not have that in the headers. Nor and more importantly, do some calendar related emails. While you can use the Type="Calendaring" for some of them, I've found that it's also necessary to use the 'X-MS-Exchange-MeetingForward-Message header contains "Forward"' header as well, and unfortunately you can not look for multiple headers in a single transport rule.

I also wonder how these internal Microsoft email use cases are handled if you did indeed "limit traffic to the specified connector by including the “RestrictDomainsToCertificate” or “RestrictDomainsToIPAddresses”" on the connectors. Would this not then reject these internal MS mail messages and calendar events within the tenant (like forwarding a calendar invite, or responding to a calendar invite)?
- Secret_Work_Persona
  Copper Contributor
  Aug 21, 2025
  To evaluate two headers, for one you can use 'contains' as you mentioned and for the other you can use 'matches these text patterns'. Pattern matching uses regular expressions, so to test if X-MS-Exchange-MeetingForward-Message exists with any value you would use 'X-MS-Exchange-MeetingForward-Message' header matches the following patterns: '\w*'. The regular expression \w* means any word character a-z, A-Z, 0-9, and underscore. To match a specific value you'll need to craft that into a Regular Expression.
Caprock
Copper Contributor
Aug 11, 2025
I would like to submit this as sort of a peer review. This article is not meant to be applied to companies utilizing 3rd party AntiSpam, i.e. Barracuda/Mimecast/Proofpoint although it does discuss them. For them we have been locking down their connectors when applicable.

I have been utilizing a method similar to the method described in the “How can we see all emails sent directly to our tenant (i.e. not through a connector)?” portion of What is Direct Send and how to secure it. We start by running a message trace summary report, inbound, for the past 90 days. One report for each domain in the tenant with the recipient being *@domain.com. Combine the .csvs, and filter the sender for any domains in the tenant. These are emails which are being sent from currently unauthenticated sources. Emails sent via internal/"your org" connectors do not appear to show on these reports and would be unaffected by disabling direct send according to this article, whereas external/"partner org" connectors do show on this report. Once we have verified and authenticated legitimate sources, we should be able to block direct send. This is a leg up on the Mail Flow Rule I have seen described as it will allow for 90 days, up to 100 thousand emails per domain, worth of historical data to be analyzed instead of just the emails we have received since the rule was implemented. It is also better than the inbound connector report for clients without a 3rd party AntiSpam described in What is Direct Send and how to secure it as it gives more insightful reporting, such as originating IP address and Subject, which can be used to determine if the sender is a system that needs to be authenticated with a connector.

Let me know if you see any holes in this theory.
JeremyTBradshaw
Iron Contributor
Aug 08, 2025
Even though the link still works, you should update the link text in the bottom section "Changes to this post:", since you renamed the title of that post from what it was on Aug 4 "What is Direct Send and how to secure it" to "Direct Send vs sending directly to an Exchange Online tenant". People might go searching around needlessly to find the right post.
- Nino_Bilic
  Microsoft
  Aug 08, 2025
  Thanks, done.
PoorMens_Bravo
Brass Contributor
Aug 06, 2025
What was the problem that 'Direct Send' as a feature addressed to?
- Arindam_Thokder
  Microsoft
  Aug 06, 2025
  Direct Send is not a feature, this is how any SMTP mail server works. The "RejectDirectSend" parameter is the new feature and with this new Organization parameter, administrators can allow/reject email which is coming with a "MAIL FROM" address (P1 sender) same as accepted domain of the tenant but not attributed to any inbound connector of the tenant.
  - ryaron
    Copper Contributor
    Aug 07, 2025
    Q: if we disable directsend and still want to allow all ms alerts/notifications, can we do that by a rule? If so pls share exact rule details, if we have to create inbound partner connector pls share exact ip addresses of ms that needs to be allowed on the connector, and of course the ms report is essential the sooner the better
zPGMc
Copper Contributor
Aug 05, 2025
We just enabled this setting to disable direct send (🙃) and we are now having issues with emails generated via Azure Communication Services being blocked. There is a Reddit thread on this same topic, so it appears we are not alone on this issue. Can anyone here advise or provide insight on this? Does ACS use Direct Send? Is there a way to allow ACS to function but still disable Direct Send?
- Andy David
  MVP
  Aug 06, 2025
  If these messages are spoofing your accepted domain in the MAIL FROM, then you could be seeing this. there is no such thing as "using Direct Send".
  
  There are some options you can leverage rather then disabling the direct send option. ( such as using a mail flow rule) However, if you want to receive these messages again, consider re-enabling direct send and then watch this KB when its updated again: https://techcommunity.microsoft.com/blog/exchange/what-is-direct-send-and-how-to-secure-it/4439865
  - zPGMc
    Copper Contributor
    Aug 06, 2025
    Andy David Whatever the correct way is of referring to Direct Send email routing is semantics. ACS obviously relies on Direct Send being enabled. We had to re-enable Direct Send to get those messages flowing again. Yes, these are spoofed messages using Direct Send from our own domain. We fall into the category of companies that utilize a 3rd party for email routing and email monitoring and Direct Send is a hole that exists that bypasses SPF, DKIM, etc.. since it does not flow through our default email gateway as defined in our MX records. I have been closely watching all of the back and forth on this. We wish to disable Direct Send entirely, but since we also need messages sent via ACS to be delivered, we do not have that option at this time. It's disappointing that Microsoft apparently knew this was an issue based on a reply on another comment thread but did not inform their customers about this limitation.
Soupy
Copper Contributor
Aug 04, 2025
Do we know when the Direct Send traffic report will be ready? We need that information to properly evaluate the potential impact before proceeding.
MadCoder332
Copper Contributor
Aug 04, 2025
there an estimated date on when the Direct Send traffic report will be available? It is very important to assess the real impact of this before implementing it.