SMTP delivery sent straight to the Exchange Online ingress endpoint instead of the organisation’s MX-listed gateway. This can undermine security inspection because the tenant may receive the message before third-party filtering has a chance to evaluate it.
Expanded Definition
Direct-to-tenant delivery describes SMTP traffic that reaches Microsoft 365 or Exchange Online by connecting straight to the tenant ingress path, rather than passing through the organisation’s MX-listed gateway. In NHI and email security operations, the term matters because the delivery path determines which controls see the message first, including anti-malware inspection, URL rewriting, sandboxing, and policy enforcement.
Definitions vary across vendors because some products describe the same condition as bypass delivery, direct send, or tenant ingress bypass. The operational distinction is not the message format, but the route: if the tenant accepts the mail before a third-party gateway evaluates it, inspection is effectively moved downstream. That can create blind spots for impersonation, payload delivery, and compromised service account abuse. The concept also intersects with mail authentication and trust decisions, which are covered in the NIST Cybersecurity Framework 2.0 as part of protective control design.
The most common misapplication is assuming that all inbound mail is uniformly filtered when the tenant’s accepted path allows some messages to arrive before the gateway policies have a chance to evaluate them.
Examples and Use Cases
Implementing inbound mail controls rigorously often introduces routing complexity, requiring organisations to weigh stronger inspection coverage against dependency on correct MX and connector configuration.
- An organisation migrates to Microsoft 365 but leaves legacy MX records, allowing some mail to arrive directly at the tenant while the security gateway still inspects the intended path.
- A partner integration uses a direct tenant connector for transactional mail, but the connector is broader than intended and accepts messages that should have been screened by the perimeter gateway.
- A phishing campaign targets a cloud tenant with spoofed sender data and reaches mailboxes before third-party filtering can fully apply, illustrating the delivery-path risk described in the Ultimate Guide to NHIs.
- A security team validates whether inbound authentication, transport rules, and tenant restrictions are consistent with the baseline controls recommended by the NIST Cybersecurity Framework 2.0.
- During incident response, analysts confirm whether a malicious message entered through the MX gateway or directly to tenant ingress, which changes containment scope and log sources.
Why It Matters in NHI Security
Direct-to-tenant delivery becomes an NHI concern when mail flow is used to reach service inboxes, workflow automations, approval chains, or human operators who administer secrets and privileged access. If a message bypasses the inspection layer, an attacker can deliver credential theft lures, malicious attachments, or policy-triggering content that influences NHI-related actions before defensive controls intervene.
This is especially relevant because NHIs already represent a disproportionate attack surface. NHI Mgmt Group reports that NHIs outnumber human identities by 25x to 50x in modern enterprises, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs. That makes mail delivery path integrity part of broader identity defence, not just email hygiene.
Teams should also treat this term as a governance indicator. If direct delivery is present unintentionally, it can invalidate assumptions about where inspection, logging, and enforcement occur, which undermines incident triage and control testing. Organisations typically encounter the operational impact only after a phishing event, missed alert, or mailbox compromise, at which point direct-to-tenant delivery becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Mail delivery path affects how protective data security controls are enforced. |
| NIST CSF 2.0 | DE.CM | Direct-to-tenant routing changes where email events are monitored and logged. |
| OWASP Non-Human Identity Top 10 | NHI-08 | Bypassed inspection can expose service accounts and automations to phishing and abuse. |
Confirm inbound mail is inspected before tenant acceptance and verify control points with test messages.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
