Direct Send – What It Is, and What It Isn’t

There are a number of posts online panicking about “Direct Send” and how its the worst thing ever. These appear to have started following Microsoft’s publication of an article on how to turn it off – but lots of the articles get the basic principles wrong and therefore provide poor and inaccurate advice.

The blog post is written in mind for me to send to my clients who have asked me about it, but is designed to clear up some misconceptions that have turned up – for example, check out the Microsoft documentation on disabling Direct Send and read some of the comments – it’s the wild west of poor configuration and Microsoft blaming going on!

How SMTP Servers “Work”

Any email tranport server (the SMTP protocol) will listen on TCP port 25 and accept emails sent to it and further deliver them. It has been like this since 1975, and this leads to an inherent problem about what to do if the email is fake (spoof) or rubbish (spam) or malicious (phish or malware). So email servers are either protected with a Secure Email Gateway (SEG) such as Mimecast or ProofPoint or have the protections built in.

If your server is on-premises, and therefore likely to be Exchange Server, as it has very weak protections built-in, you would have a SEG in front of the server and use your firewall to allow only the SEG to submit email to the on-premises server. The SEG should be configured to block spoof, phish, malware etc. If you have had this arrangement for a number of years, have you revisited the configuration recently to make sure the SEG is still blocking all the things it needs to block?

But in the cloud it is different. Your firewall cannot sit between your SEG and Exchange Online. One can always connect to the publicly known Exchange Online endpoints. Therefore, it is all about configuration. And with M365 mailboxes (Exchange Online) you have two options:

1. Send all external email directly to Exchange Online Protection – MX to EOP – and configure EOP properly.
2. Send all email to your Secure Email Gateway – MX to 3rd party SEG – and configure EOP to reject anything that does not come via the SEG.

Any other configuration is not a good idea.

Note that Exchange Online Protection is in the cloud – it does not provide dedicated IPs or resources to you or your mailboxes, everything is shared. From the perspective of Exchange Online Protection (EOP), there are a number of dedicated environments running EOP that are geographically isolated – for example a US instance and an EU instance (and others). If your tenant is US based then it will share EOP services with every other (non-gov) US tenant. If your MX record is mydomain-com.mail.protection.outlook.com then this resolves to EOP US IP addresses and therefore I can use another MX record to another tenant in your region or the related IP addresses directly and send emails to you – your MX record is not a security boundary.

Therefore, if you do not want mail to be delivered directly to Exchange Online Protection but instead only to your SEG then it is all about good configuration to block this perceived backdoor.

What Is Direct Send

So now onto Direct Send. This is used typically by scanners and printers and other devices on your network to send from your domain to your domain. In circumstances where you do not need this, you can now turn this off (for this see Microsoft recent article). Direct Send also only considered “non-authenticated” email. In this context, email is authenticated if the sender can be tied to a connector. So Direct Send is email arriving at EOP where there is no connector in place for the sending source IPs (or sending source certificate).

Direct Send is NOT any from address to your domain. It is exclusively from your domains to your domains. This picture shows what I mean – and in this example “domain.com” is one of my tenant domains:

Whereas the below is NOT Direct Send – this is just a standard email send from someone external to an internal mailbox:

How To Control Direct Send

If your configuration option above is #1 – MX to EOP then there are a few things to configure correctly for the applications etc to send directly to Exchange Online Protection. First is that all the sending IP addresses should be listed on the SPF record. This SPF record ideally should be a hard fail record (-all at the end) and your DMARC record should reject all email that fails SPF (or DKIM, but Direct Send users are probably not using DKIM). Therefore, your DMARC record should contain “p=reject”.

Of course to be “reject” all your other senders need to be in the SPF record as well, or using DKIM. DMARC verification services can help you get this correct.

With both of these configurations in place, Direct Send from your allowed senders will work, but Direct Send utilised by a malicious actor will fail because their sending IP is not allowed via your SPF record. EOP will see it failing SPF and therefore DMARC and treat the email based on the Honor DMARC setting anti-phish policy or the TABL rules mentioned below. If you have no DMARC record (or p=none) then you have no way to tell Exchange Online (any tenant) what to do with messages spoofed from your domains.

Of course, if you don’t have a need for Direct Send then disable it, but if you do need Direct Send and you disable it, it will not matter if your SPF and DMARC is correct because you have disabled it!

Of course, a badly configured EOP set up will also cause problems – for example being worried about spoof emails but having no protections against impersonation is not a good place to be. It is of no use blaming Microsoft for a poor anti-spoof configuration if you don’t actually configure it properly. Therefore, anti-spoofing configuration is required inside EOP. This is either the anti-phishing settings belonging to Microsoft Defender for Office (MDO) Plan 1 licence or a Tenant Allow/Block List (TABL) rule blocking spoof for * if you do not have MDO.

You can see recent spoof attempts against your tenant from the Spoof Intelligence Insight at https://security.microsoft.com/spoofintelligence. With the TABL rules being configured at https://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem

So, to summarise, if you have MX pointing to EOP and no SEG in use then turn off Direct Send if you do not use it, but if you do have external or internal services sending directly to your MX endpoint FROM and TO your internal domains add these senders to your SPF record and work to get DMARC to reject status. Add inbound partner connectors for the source if possible as well.

If your above configuration is #2, email should route to your mailboxes via a SEG (and then via EOP) you have a number of options. Note that any email that reaches EOP that is FROM and TO your domains, even if it routed via the SEG is considered Direct Send unless you have a partner connector for your SEG in place.

The perceived issue that people have with EOP is that it is a poor spam detector. This was historically true – but not so much anymore. Mostly its problems in detection now are caused by out of date configuration or configuration that IT/Security will not put in place because it impacts users (i.e. sending stuff to the quarantine and notifying users they have mail in the quarantine, whitelisting domains etc), which means EOP does not work effectively.

For organizations with an SEG, EOP should be configured with an Inbound Partner Connector restricted to the IP addresses that the SEG users to send to your tenant. This is an Exchange Online PowerShell only configuration (it is not all available in the admin portal) and is documented in Step 4 of Microsoft long existing documentation on how to configure Exchange Online if you use a SEG. With this configuration in place any external email from any domain, including your own domains, will be rejected if arriving at Exchange Online without first having gone through your 3rd party SEG. And as its rejected, you don’t need to disable Direct Send (unless your SEG allows the spoofed email in, but that is not the issue we are discussing here).

Lots of the conversation online about Direct Send has been with misconfigured partner connectors (not restricting mail-flow to only these connectors), misunderstanding Direct Send (thinking it is any from address and so therefore SMTP relay in general) or disabling and not configuring lots of EOPs protections and then wondering why emails that bypass the SEG are not blocked.

If you are one of my clients with a SEG I always build as follows:

1. MX to SEG
2. EOP + MDO properly configured
3. Partner connector from SEG, but not restricted to only from the SEG because EOP will protect for directly delivered content
4. On-premises Exchange routes to EOP for hybrid environments, and therefore EOP protections are also in place for internal and on-prem/cloud mail flows as well (as the SEG only protects for external email). You need this as not all internal email is “good”. A compromised account sending malicious email to other internal mailboxes is not going via your SEG.

The above sometimes hits issues with email being “protected” twice – something makes it through the SEG and then EOP block it and I’m asked why, and how to stop EOP protecting it and having the users need to look in multiple quarantines! My suggestion, which often does not get anywhere, is that the quarantine in use should be the one closest to the user. So Defence in Depth, SEG + EOP both properly configured (or EOP properly configured on its own, as this has many layers of defense) and quarantine phish and high confidence phish in EOP along with high confidence spam and maybe spam to Junk Email folder (or quarantine).

This configuration also makes it easy to remove your SEG as well, which is a project I have run for many of my clients over the past years as they see the effectiveness of the SEG getting worse.

Photo by Liza Summer: https://www.pexels.com/photo/crop-unrecognizable-woman-sealing-carton-parcel-with-tape-6348095/