They should do both where the environment allows it, but for different reasons. Gateway filtering helps inspect mail at the perimeter, while disabling Direct Send reduces unauthenticated direct delivery to Exchange Online. The right choice depends on whether the tenant can still accept mail outside the approved route.
Why the two controls solve different problems
Gateway filtering and direct send are not interchangeable controls. Gateway filtering inspects mail as it enters or leaves through the approved perimeter, which is useful for policy enforcement, malware screening, and routing control. Disabling Direct Send closes a separate path, unauthenticated mail submission directly into Exchange Online, so you remove a bypass rather than only inspecting traffic after it arrives.
The practical question is whether your mail architecture still needs that bypass at all. If business processes, printers, scanners, or applications can be moved to authenticated or relay-based delivery, disabling Direct Send usually gives the cleaner security posture because it reduces the number of places where mail can enter without normal sender verification.
That said, gateway filtering still has value even when Direct Send is disabled. A tenant can accept mail only through the approved route and still need content inspection, spoofing checks, routing policy, and quarantine handling at the perimeter. The strongest posture is usually layered: reduce unauthenticated paths first, then inspect the traffic that remains.
When disabling Direct Send is the better default
Direct Send becomes a liability when it is being used as a convenience path rather than a deliberate mail flow design. If the tenant does not have a legitimate need to accept unauthenticated direct delivery from internal devices or applications, disabling it removes an easy abuse path that attackers can use for low-friction message injection.
For many environments, the right sequence is to identify every sender that depends on Direct Send, decide whether it can authenticate, and migrate it to a controlled relay or application submission method. If you can complete that migration without breaking business functions, the control is usually worth the operational effort because it shrinks the attack surface and simplifies mail governance.
Gateway filtering alone does not fully solve this problem if Direct Send remains enabled. A perimeter filter can inspect mail that passes through it, but it does not eliminate alternate delivery paths that never touch the same inspection point. In that sense, relying only on filtering can leave a hidden exception route in place.
How to decide based on the tenant’s mail flow design
The decision turns on whether the environment can still accept mail outside the approved route. If the answer is yes, because legacy systems or embedded devices still rely on direct submission, then keep that route only as a temporary exception and compensate with strict monitoring and a migration plan. If the answer is no, disable Direct Send and treat gateway filtering as the inspection layer, not the primary containment control.
A useful rule is to treat gateway filtering as a content and policy control, and Direct Send as a transport-authority control. One decides what the mail looks like when it is inspected, the other decides whether the mail should have been allowed to arrive that way in the first place. Strong security programs tend to control both the path and the payload.
For teams operating Microsoft 365, this often becomes an architecture decision rather than a pure security toggle. The cleaner the approved submission model, the easier it is to reason about trust boundaries, sender provenance, and incident response when suspicious mail appears.
Risk and Threat Considerations
Leaving Direct Send enabled can create an unauthenticated message path that bypasses some of the assumptions your perimeter controls rely on. That increases the chance of mail injection, abuse of weakly governed device or application flows, and confusion during investigations when messages arrive outside the normal submission route.
Failure mechanism: An attacker or abused system can send mail directly to the service without using the approved authenticated route, which can weaken sender trust decisions and reduce the value of perimeter-only inspection.
Impact: Security teams may miss or misclassify unwanted messages, and administrators may retain an unnecessary bypass that complicates containment, monitoring, and root-cause analysis.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service, Workstation, and Device Connections) | Direct Send is a service submission path that benefits from authenticated control. |
| AC-4 — Information Flow Enforcement | Gateway filtering enforces mail flow policy at the approved perimeter. | |
| Recommendation — Require authenticated mail submission paths and restrict unauthenticated direct delivery routes. Enforce allowed mail paths at the gateway and block unauthorized direct routing. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about constraining which mail paths are allowed. |
| A.8.20 — Network security | Gateway filtering is a boundary control that inspects and controls mail traffic. | |
| Recommendation — Define and enforce the approved mail submission route and remove unnecessary bypasses. Inspect mail at the boundary and apply controls to the permitted path. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Disabling Direct Send reduces an unnecessary access path into Exchange Online. |
| Recommendation — Remove direct submission paths that are not required for business operations. | ||
Practitioner Guidance
What to prioritise: First inventory every legitimate system that depends on Direct Send, then classify which ones can move to authenticated submission, relay, or another controlled mail path. The control decision should follow the dependency review, not precede it.
What to verify: Confirm that disabling Direct Send will not break printers, scanners, line-of-business applications, or relay-dependent workflows. If a dependency exists, document why it exists, who owns it, and when it will be retired or remediated.
Common mistake: Treating gateway filtering as a substitute for reducing unauthenticated delivery paths. Filtering is strongest when it sits on top of a constrained mail architecture, not when it has to compensate for every possible bypass.
Practitioner takeaway: If you can eliminate unauthenticated direct mail submission without harming business operations, do so, then keep gateway filtering as the inspection and enforcement layer rather than the only line of defense.