Email spoofing defenses often focus on whether a message passes authentication. Ghost-Sender shifts the question to what happens next: whether failed authentication is actually enforced before the message is delivered.

Ghost-Sender is a configuration issue that can enable unauthenticated email spoofing against certain Microsoft Exchange Online tenants. In affected environments, a spoofed email can fail SPF, DKIM, and DMARC, originate from an unauthenticated sender, and still reach the inbox.

Public research demonstrated that fraudulent messages could be delivered even when the spoofed domain had properly configured email authentication policies. The issue is the disconnect between authentication results and delivery behavior: the failure is visible in the mail flow, but the environment may still allow the message to reach the user.

At a high level, Ghost-Sender exploits certain Exchange Online environments that route inbound mail through secure email gateways (SEGs) or other third-party filtering services.

This exposure arises when an organization uses Exchange Online—or on-premises Exchange in hybrid mode—and routes mail through a third-party mail server, gateway, or filtering service as the domain’s MX record. In a typical setup, that external service receives inbound mail first, applies filtering, and then forwards allowed messages to Microsoft 365.

Ghost-Sender bypasses that designated mail flow. Instead of sending mail to the MX-listed gateway, the sender connects directly to the tenant’s Exchange Online ingress endpoint, typically in the format of the organization’s dashed domain followed by mail.protection.outlook[.]com. If that endpoint accepts unauthenticated mail directly, an attacker can send messages to the tenant outside the organization’s intended inspection path.

Ghost-Sender gives attackers an avenue to impersonation without first taking over an account or stealing credentials. It relies on direct SMTP delivery to the tenant and an environment that does not reject or quarantine unauthenticated sender traffic before it reaches the user.

Researchers found that, in misconfigured setups, Exchange Online accepted mail sent directly to the tenant and delivered it to the inbox, even when authentication failed. One example showed that a message claiming to originate from noreply@microsoft[.]com was delivered despite failed authentication. And this is not a matter of users seeing a clear warning and choosing to ignore it. In the documented behavior, these messages can reach the inbox without authentication failure indicators being surfaced to the recipient.

The result is simple in execution but significant in impact: an attacker may be able to send email from arbitrary senders to recipients within the target tenant. That can include external senders—such as a well-known software provider or recognized vendor—and internal senders, such as executives, colleagues, and internal departments. For internal spoofed senders, Outlook may resolve the sender’s profile and picture, making the message appear even more legitimate to the recipient.

This technical weakness allows attackers to send messages that inherit the credibility associated with legitimate identities. A fraudulent invoice can appear to originate from a known vendor. An external phishing lure can look as though it was sent by a trusted third party. An internal impersonation attempt can appear to come from someone within the organization, potentially even resolving the individual’s actual profile photo in Outlook.

This is what makes Ghost-Sender especially dangerous. Familiar messages are often subject to less scrutiny, particularly when they appear to come from established vendors, trusted partners, executives, or internal teams. By creating the semblance of legitimate communication, Ghost-Sender enables impersonation without requiring the attacker to compromise the individual or organization being spoofed.

Ghost-Sender is less about one security control breaking down and more about a flawed assumption. The organization assumes inbound mail will enter through the MX-listed inspection path, but Exchange Online may still accept mail sent directly to the tenant. Authentication may still record failure, but the message may still be delivered to the user’s inbox.

That creates a blind spot for SEGs and filtering services, which are designed to inspect messages that pass through them. When a message is sent directly to Exchange Online rather than through the external MX-listed filtering layer, the intended inspection path has been bypassed.

The issue also complicates reliance on SPF, DKIM, and DMARC as the final arbiters of legitimacy. In one reported example, authentication headers showed SPF failure, DKIM not signed, and DMARC failure, yet the message still reached the inbox.

In the documented Ghost-Sender testing, some Microsoft security controls did not block delivery in the tested configuration. A standard “Your organization’s email server” connector with certificate- or IP-based authentication did not reject the spoofed emails during testing. Enhanced Filtering for Connectors did not prevent delivery. Standard and Strict preset security policies also failed to prevent arbitrary impersonation in the tested configuration.

The defensive risk is the gap between what security teams expect the mail flow to enforce and what the tenant may actually accept. Without directly validating that behavior, teams may assume the environment is protected when spoofed messages can still reach users.

For teams using Exchange Online with an external MX record, reducing exposure starts with validating actual tenant behavior—not just reviewing intended mail flow. From there, the priority is to harden the paths Exchange Online will accept, quarantine messages that bypass approved routes, and account for the limits of traditional detection.

Determine Whether Exchange Online Accepts Mail Outside the Intended Route

Confirm whether the Exchange Online tenant can accept inbound mail directly from the internet outside the intended third-party filtering path. Any validation should be performed only with proper authorization and should verify whether spoofed messages are rejected, quarantined, or delivered.

Configure a Partner Organization Connector

A Partner Organization connector can help mitigate risk when configured to apply to mail from any domain and reject messages based on IP or certificate validation. The connector must be set up correctly, including the wildcard entry used to identify the partner; otherwise, the email send may still work.

Quarantine Direct-to-Tenant Mail

A transport rule, or mail flow rule, can quarantine inbound messages when they do not come from approved sender IP ranges and do not include the X-MS-Exchange-Organization-AuthAs: Internal header. In this approach, Exchange Online may still accept the message at the SMTP layer, but it’s intercepted afterward and placed into hosted quarantine rather than delivered to the user’s inbox.

Disable Direct Send Where Possible

Disabling Direct Send can reduce Ghost-Sender risk, but it does not remove the tenant’s Exchange Online ingress endpoint. Instead, it forces authentication for mail sent directly to that endpoint. Unauthenticated messages will receive a non-delivery response, which helps prevent spoofing of internal senders. However, because the endpoint remains active and can still accept authenticated messages, disabling Direct Send does not fully eliminate external sender impersonation risk.

Analyze Headers for Mail Flow Discrepancies

Defenders should also account for detection complexity. Consistent, low-noise traditional indicators are not guaranteed across all tenants, licenses, and configurations. In the public Ghost-Sender research, header analysis for discrepancies in the mail gateway flow is presented as the most practical detection clue. Accurately forging those routing details would require internal information such as appliance IP addresses and hostnames along the organization’s mail path.

Ghost-Sender is more than just another spoofing technique. It is a reminder that email security depends on the interaction between authentication, mail routing, tenant configuration, and user trust.

SPF, DKIM, and DMARC remain essential controls, but Ghost-Sender shows that authentication results only matter when they are enforced at the right point in the mail flow. When tenant settings or routing decisions allow failed authentication to coexist with inbox delivery, attackers may impersonate arbitrary senders and place messages directly in front of users.

That makes email authentication necessary, but not sufficient. Security teams need to validate how messages actually reach the inbox, confirm that failed authentication leads to the expected outcome, and evaluate high-risk requests in context. This means understanding whether the sender-recipient relationship makes sense, whether the message content aligns with expected workflows, and whether the message’s technical route matches the organization’s designated mail flow.

Ghost-Sender highlights a broader problem in email security: attackers do not need to defeat every control when they can exploit the assumptions those controls depend on. Security teams need defenses that can recognize when the appearance of trust no longer reflects legitimate communication.

For additional insight into the threat landscape, visit our threat intelligence data and research hub, Abnormal Intelligence.