Ghost-Sender exposes Exchange Online mail flow trust gaps

At a glance

What this is: Ghost-Sender is a mail-flow misconfiguration issue that can let spoofed messages reach Exchange Online inboxes even when authentication fails.

Why it matters: It matters because IAM, PAM, and identity security teams must treat email delivery paths as part of trust enforcement, not just rely on SPF, DKIM, and DMARC results.

👉 Read Abnormal AI's analysis of Ghost-Sender and Exchange Online spoofing

Context

Ghost-Sender is a delivery-path problem, not a credential-compromise problem. It describes a situation where Exchange Online may accept inbound mail outside the intended inspection route, so authentication failures do not necessarily prevent inbox delivery. For identity teams, that makes email flow enforcement part of the trust boundary, alongside SPF, DKIM, DMARC, and gateway policy.

The practical issue is that many organisations assume their MX-listed secure email gateway is the point where legitimacy is decided. Ghost-Sender shows that assumption can break when direct-to-tenant mail reaches Exchange Online first. That means recipients may see spoofed internal or external senders as if they were legitimate, even though the message failed authentication.

Key questions

Q: How should security teams stop spoofed mail that bypasses the MX gateway path?

A: They should validate whether the tenant can accept mail directly, then enforce rejection or quarantine with connectors and transport rules that match approved routes. SPF, DKIM, and DMARC are necessary, but they are not enough if delivery happens before enforcement. The control objective is to make failed authentication lead to the correct disposition before the message reaches the inbox.

Q: Why do SPF, DKIM, and DMARC sometimes fail to protect Exchange Online tenants?

A: They fail when the environment treats authentication as a signal rather than a blocking condition. If Exchange Online accepts mail directly or bypasses the intended gateway path, a message can fail authentication and still be delivered. That is why mail-flow enforcement and route validation matter as much as authentication policy.

Q: What breaks when a secure email gateway is only part of the trust model?

A: The inspection model breaks because the gateway sees only the mail that is routed through it. If an attacker sends mail directly to the tenant, the intended inspection path is bypassed and user-facing trust can be created without the gateway ever evaluating the message. That makes path validation a governance control, not just a network detail.

Q: Who is accountable when spoofed mail reaches the inbox despite failed authentication?

A: Accountability sits with the teams that own mail routing, tenant configuration, and identity security together. If routing allows direct delivery and policy does not force rejection or quarantine, the failure is operational and governance-related, not just a user awareness issue. Organisations should map this to email security ownership, change control, and audit evidence.

Technical breakdown

Direct-to-tenant delivery bypasses the MX inspection path

Ghost-Sender works when inbound mail is sent directly to the Exchange Online ingress endpoint rather than the MX record that normally points to a secure email gateway or third-party filter. In that model, the gateway never sees the message, so its inspection logic, policy checks, and quarantine decisions are bypassed entirely. Exchange Online then becomes the enforcement point, and if the tenant accepts the message, the spoofed email can proceed despite failing upstream authentication checks. The weakness is architectural: the trust decision is split between routing and validation, and those layers are not always aligned.

Practical implication: validate whether direct-to-tenant SMTP delivery is possible in your tenant, not just whether the gateway is configured correctly.

SPF, DKIM, and DMARC can fail without stopping delivery

SPF, DKIM, and DMARC are authentication signals, not delivery guarantees. Ghost-Sender exposes environments where those checks fail but the message still reaches the mailbox, which creates a dangerous gap between authentication outcome and enforcement outcome. In the tested behavior, failed authentication did not automatically translate into rejection or quarantine, so the tenant allowed the email to survive long enough for the user to receive it. That matters because security teams often treat authentication policy as a final gate when it may only be an advisory signal unless tenant settings enforce it.

Practical implication: test the actual disposition of failed-authentication mail and confirm whether it is rejected, quarantined, or delivered.

Header analysis is the most reliable way to detect mail-flow drift

When spoofed messages bypass standard routing, the most useful detection signal is often header inconsistency. Header analysis can reveal whether a message arrived through the expected gateway, whether the internal authentication markers align with the declared path, and whether the tenant accepted mail through an unintended route. The article notes that low-noise indicators are not guaranteed across all configurations, which makes header-level validation more dependable than trying to rely on a single authentication verdict. This is a mail-flow integrity problem as much as an email spoofing problem.

Practical implication: build detection around header and path validation, not authentication headers alone.

Threat narrative

Attacker objective: The attacker wants to place a convincing spoofed message directly in front of the recipient and use trust in the sender identity to drive phishing, fraud, or internal impersonation.

1. Entry occurs when an attacker sends spoofed mail directly to the Exchange Online ingress endpoint instead of through the MX-listed secure email gateway.
2. Escalation happens when the tenant accepts the unauthenticated message even though SPF, DKIM, and DMARC fail, allowing delivery to proceed.
3. Impact follows when the spoofed sender lands in the inbox and can impersonate a trusted vendor, executive, or internal team without any account compromise.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mail-flow enforcement is the control, not SPF, DKIM, or DMARC alone. Those protocols tell you whether a sender is authenticated, but they do not guarantee that unauthenticated mail will be stopped before delivery. Ghost-Sender shows that security teams can be correct on authentication and still be wrong on enforcement. The implication is that identity security for email must include the acceptance path, not just the authentication result.

Direct-to-tenant delivery exposes an identity trust boundary that many programmes do not model. Organisations often assume the MX-listed gateway is the only path into the mailbox environment, but Exchange Online may accept mail outside that route. That assumption breaks the moment the tenant itself becomes the effective entry point. Practitioners need to treat mail routing as part of access governance, because the user experience of trust can be decoupled from the technical state of authentication.

Header discrepancies are a named concept worth operationalising: mail-flow integrity drift. This is the gap between the path an email was supposed to take and the path it actually took. It matters because spoofing can succeed without account theft when the environment accepts mail that failed policy checks. Security teams should use that concept to separate delivery-path failures from sender-authentication failures in their incident and control models.

Exchange Online misconfiguration is an identity governance problem because it changes who can speak with authority. The article shows that internal-looking messages can appear legitimate even when no account is compromised, which means identity assurance is being projected by mail flow rather than earned by authentication. That breaks the assumption that legitimacy is decided at the point of sender verification. Practitioners should treat inbox acceptance as a trust decision with governance consequences.

Traditional email controls fail when trust is enforced after the user has already seen the message. The real failure mode here is not weak SPF or absent DKIM, but delayed enforcement. Once a message reaches Outlook and displays a familiar sender profile, the burden shifts to the user, which is too late for reliable security. The practitioner takeaway is to validate enforcement before delivery, not after user exposure.

From our research:

• In one reported example, authentication headers showed SPF failure, DKIM not signed, and DMARC failure, yet the message still reached the inbox, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• For a broader identity governance lens, see Ultimate Guide to NHIs , What are Non-Human Identities for the credential and trust models that underpin non-human access.

What this signals

Mail-flow integrity drift: teams should treat direct-to-tenant delivery as an identity governance signal, not just a messaging anomaly. If the intended inspection path and the actual delivery path can diverge, then trust decisions are happening in the wrong place and email authentication controls become advisory instead of enforceable.

The governance implication is that Exchange Online configuration now sits alongside SPF, DKIM, and DMARC as part of the trust boundary. Organisations that only monitor sender authentication will miss cases where mail is technically unauthenticated yet still operationally delivered to users.

With 57% of organisations lacking a complete inventory of their machine identities, per The Critical Gaps in Machine Identity Management report, the broader lesson is clear: identity programmes often lose control when they cannot fully account for where trust is created, routed, and enforced.

For practitioners

• Validate direct-to-tenant mail acceptance Confirm whether your Exchange Online tenant accepts inbound mail outside the MX-listed inspection path and record whether spoofed messages are rejected, quarantined, or delivered.
• Harden partner and transport rules Use Partner Organization connectors and transport rules to reject or quarantine mail that does not arrive from approved sender IP ranges or expected internal auth markers.
• Review Direct Send exposure Disable Direct Send where possible and verify that unauthenticated mail to the Exchange Online ingress endpoint receives a non-delivery response instead of inbox delivery.
• Operationalise header-based detection Create detection workflows that compare message headers, gateway path indicators, and expected routing so mail-flow discrepancies can be identified consistently.

Key takeaways

• Ghost-Sender is a trust-enforcement problem, not just an authentication problem, because failed SPF, DKIM, and DMARC do not always stop delivery.
• The evidence shows inbox delivery can still occur even when the spoofed domain has proper authentication policies and the message bypasses the intended gateway path.
• The control that matters most is validating and enforcing actual mail flow, including direct-to-tenant acceptance, quarantine logic, and header-based route verification.

Key terms

• Mail-flow integrity drift: The mismatch between the route an email should take and the route it actually takes. In practice, this means a message can bypass the intended gateway or inspection layer and still reach the mailbox if tenant acceptance is too permissive.
• 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.
• Authentication failure enforcement: The control decision that turns SPF, DKIM, or DMARC failure into rejection, quarantine, or another blocking outcome. Without enforcement, authentication results may be visible in headers but still fail to protect the recipient from inbox delivery.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: Ghost-Sender bypasses SEGs by sending mail directly to Exchange Online. Read the original.