TL;DR: Ghost-Sender shows that some Exchange Online tenants can still deliver spoofed mail directly to the inbox even when SPF, DKIM, and DMARC fail, bypassing MX-listed inspection paths and weakening SEG-based defenses, according to Abnormal AI. Email authentication only protects users when mail flow enforcement matches the intended route.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Abnormal AI's blog post: Ghost-Sender is a mail-flow misconfiguration issue that can let unauthenticated spoofed email reach Exchange Online inboxes despite failing SPF, DKIM, and DMARC.
Why it matters: IAM and security teams need to verify the actual delivery path, because email authentication is not enough if tenant enforcement still allows spoofed messages through.
Context
Ghost-Sender is a mail flow and trust-enforcement problem, not an account-compromise story. The key issue is that Exchange Online can accept mail directly at the tenant ingress endpoint even when the message failed SPF, DKIM, and DMARC, which means the expected inspection path does not always control delivery.
For security teams running Exchange Online behind a secure email gateway or other external filter, this is an identity governance problem because the environment may treat unauthenticated sender traffic as deliverable mail. That breaks the assumption that authentication failure and inbox delivery cannot coexist.
The practical risk is impersonation of external vendors, executives, colleagues, and internal departments without stealing an account first. In other words, the control gap sits between mail authentication and the tenant’s enforcement behaviour, not in the attacker’s credential access.
Key questions
Q: What breaks when Exchange Online accepts mail outside the approved inspection path?
A: The control assumption breaks first: teams expect the MX-listed gateway or filtering layer to enforce inbound checks, but direct-to-tenant delivery can bypass that path. When that happens, failed SPF, DKIM, and DMARC do not necessarily stop delivery, so mailbox trust no longer matches mail-flow policy.
Q: Why do spoofed emails still succeed when authentication controls exist?
A: Spoofed email still works when organisations treat authentication as a checkbox rather than an enforcement mechanism. Attackers also exploit compromised accounts, lookalike domains and weak user verification habits. Controls reduce risk, but only if they are enforced, monitored and paired with identity-aware process checks for approvals and account recovery.
Q: What are the signs that mail flow enforcement is misconfigured?
A: Look for messages that arrive with failed SPF, unsigned DKIM, or DMARC failure but still appear in user inboxes. Also watch for routing evidence that the message did not come through the expected gateway or connector path, because that mismatch is the key indicator of enforcement drift.
Q: Should security teams disable Direct Send or rely on gateway filtering?
A: 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.
Technical breakdown
How direct-to-tenant mail bypasses the MX-listed inspection path
In the Ghost-Sender pattern, the sender does not deliver to the MX-listed secure email gateway first. Instead, the message connects directly to the Exchange Online ingress endpoint, typically the tenant’s mail.protection.outlook.com address, and bypasses the organization’s intended filtering route. This is not an authentication failure in the classic sense. SPF, DKIM, and DMARC can still fail, but the critical issue is that the mail flow path itself is not enforced tightly enough to stop delivery before the message reaches the mailbox.
Practical implication: Validate whether your tenant will accept direct inbound mail outside the approved mail path.
Why SPF, DKIM, and DMARC can fail without preventing delivery
Authentication protocols answer whether the sender is legitimate, but they do not by themselves guarantee a block at delivery time. Ghost-Sender shows that an environment can record failed authentication and still route the message into the inbox if tenant configuration allows it. That creates a split between authentication evidence and enforcement outcome. The recipient may never see a warning, which means mail security cannot rely on header verdicts alone when the receiving system accepts the message anyway.
Practical implication: Treat failed authentication as insufficient unless the tenant explicitly quarantines or rejects the message.
Why Outlook can make spoofed mail look internally legitimate
When the spoofed sender appears to be internal, Outlook may resolve the sender profile and photo, which adds social credibility to the message. The attacker does not need account takeover for this effect, only a delivery path that accepts the spoofed message. This matters because visual trust cues amplify the success of impersonation, especially for invoice fraud, executive impersonation, and other workflow-based lures. The control failure is not just delivery, but the user-facing presentation of a message that should never have arrived unchallenged.
Practical implication: Review whether mailbox presentation and routing checks create a false internal-trust signal.
Threat narrative
Attacker objective: Deliver spoofed email that looks legitimate enough to drive phishing, invoice fraud, or internal impersonation without compromising an account.
- Entry occurs when the attacker sends mail directly to the Exchange Online tenant ingress endpoint instead of the MX-listed filtering path.
- Credential access is not required because the technique relies on unauthenticated sender delivery rather than account compromise.
- Escalation occurs when the tenant accepts a spoofed message despite failed SPF, DKIM, and DMARC, allowing delivery into the inbox.
- Impact is successful impersonation of external or internal identities, with the message appearing more trustworthy to the recipient.
Breaches seen in the wild
- MongoBleed breach: MongoBleed exposed secrets across 87K MongoDB servers.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Mail authentication is only a control verdict, not a delivery guarantee: Ghost-Sender exposes the gap between message authentication and mail-flow enforcement. SPF, DKIM, and DMARC can all fail while the tenant still accepts the message, which means the security decision is being made too late in the path. The implication is that email security governance must validate route enforcement, not just authentication results.
Direct-to-tenant acceptance is a mail-flow trust gap, not a user error problem: The weak point is the assumption that all inbound mail enters through the approved inspection layer. When Exchange Online accepts mail outside that path, the environment creates an alternate trust channel that security teams did not intend. Practitioners should treat this as a governance failure in delivery architecture, not a tuning issue in a single control.
Header evidence becomes more important when delivery behaviour and policy disagree: The article’s emphasis on header analysis reflects a broader reality that users cannot reliably see mail-flow discrepancies. If consistent low-noise signals are absent, defenders need to inspect routing artifacts to prove whether a message followed the expected path. The practitioner lesson is to measure enforced mail flow, not assume it from policy documentation.
Exchange Online mail-flow trust gaps create identity risk across human and non-human workflows: The same spoofed delivery weakness can be used against people, vendors, and automated approval chains that trust inbox-originated requests. That widens the blast radius beyond phishing into workflow abuse, because inbox legitimacy often becomes a downstream authorisation signal. Teams should treat mail delivery integrity as an identity input, not just a messaging concern.
Ghost-Sender exposes a named concept: mail-flow enforcement drift: The problem is that sender authentication, routing design, and tenant enforcement have drifted apart. The authentication layer says one thing, but the delivery layer may do another. That divergence is now a practical control boundary that identity and messaging teams must govern together.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: NHI Authentication Guide
What this signals
Mail-flow enforcement drift: Exchange Online tenants can drift into a state where authentication policy, connector design, and actual delivery behaviour no longer agree. That is a governance problem because security teams may believe failed SPF, DKIM, and DMARC already stop delivery when the tenant still allows the message through.
For programmes that rely on secure email gateways, the practical next step is to prove the mailbox path rather than assume it. Header inspection, connector review, and quarantine behaviour all need validation together, because the inbox is often the last trust boundary users actually experience.
For practitioners
- Validate direct inbound acceptance Test whether Exchange Online accepts mail directly from the internet when the message does not traverse the approved MX-listed gateway path. Document whether the tenant rejects, quarantines, or delivers those messages before relying on any gateway or authentication policy.
- Enforce quarantine for off-path mail Use mail flow rules to identify messages that did not arrive from approved sender IP ranges or that lack the expected internal routing header, then quarantine them before they reach the inbox.
- Harden connector and certificate checks Review partner organization connector settings so that mail from approved domains is validated against the expected source IP or certificate and cannot quietly bypass the intended inspection route.
- Inspect header discrepancies routinely Build detection around header and routing inconsistencies, because the article shows that inbox delivery can coexist with failed authentication and low-noise indicators are not guaranteed across configurations.
- Disable Direct Send where feasible Remove unauthenticated direct-to-tenant delivery where business use allows it, so spoofed internal mail receives a non-delivery response instead of reaching users through the tenant ingress endpoint.
Key takeaways
- Ghost-Sender shows that mail authentication is not enough when tenant routing can still deliver spoofed messages directly to the inbox.
- The core failure is the gap between expected mail flow and actual Exchange Online enforcement, not account compromise.
- Teams need to validate the delivery path, quarantine off-path mail, and remove unauthenticated direct-send routes where possible.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Spoofed mail reaches inboxes despite failed SPF, DKIM, and DMARC authentication checks. |
| NHI-10 — Human Use of NHI | Spoofed internal mail abuses human trust in identity presentation and inbox legitimacy. | |
| Recommendation — Verify that authentication failures lead to rejection or quarantine before delivery. Reduce reliance on sender appearance and validate high-risk requests out of band. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Mail-flow enforcement functions as an authorisation boundary for message delivery. |
| Recommendation — Align delivery permissions with approved sender paths and block off-path acceptance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on failed email authentication that still allowed inbox delivery. |
| Recommendation — Apply authenticator management to ensure failed validation cannot still result in trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity spoofing impacts who users believe is communicating, even without account compromise. |
| Recommendation — Revoke or quarantine mail identities that bypass approved routing and sender controls. | ||
Key terms
- Mail-Flow Enforcement: Mail-flow enforcement is the control that decides whether a message is rejected, quarantined, or delivered after it reaches the receiving tenant. In Exchange Online contexts, it is distinct from SPF, DKIM, and DMARC because those checks only describe authenticity, while enforcement determines the actual outcome.
- Direct-to-tenant delivery: 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.
- Mail-flow trust boundary: The operational point where an organisation decides whether an inbound email is allowed to become user-visible. For modern cloud mail systems, this boundary must include routing, connector policy, header inspection, and tenant acceptance behaviour.
- Mailbox Impersonation: Mailbox impersonation is a permission model that lets an authorized account act as or access another mailbox for administrative or investigative purposes. In incident response, it can help responders inspect content and remove threats more efficiently. Because it is powerful, it requires strong governance, logging, and narrow assignment.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org