In early June 2026, Swiss cybersecurity firm InfoGuard Labs disclosed a vulnerability they named Ghost-Sender: a misconfiguration in Microsoft Exchange Online that allows an attacker to deliver email impersonating any sender – internal or external – directly to a target organization’s inbox while bypassing SPF, DKIM, and DMARC authentication entirely.
Microsoft was notified on April 21, 2026. By May 29, 2026, the company’s Security Response Center had classified the issue as a known architectural limitation rather than a product vulnerability. No platform-level fix has been issued. The responsibility for remediation sits entirely with Exchange Online administrators.
This is not a theoretical flaw waiting to be exploited. Microsoft support confirmed to the researchers that a related issue is being actively abused in the wild. Preliminary analysis suggests that over 20 percent of Exchange Online environments with external MX records have no mitigation applied.
How Ghost-Sender Works
The vulnerability requires a specific but common configuration: an organization using Exchange Online, or on-premises Exchange in hybrid mode, where the organization’s MX record points to a third-party email gateway rather than directly to Microsoft’s servers. This setup is extremely common among organizations that use commercial spam filtering solutions from vendors like Proofpoint, Mimecast, Barracuda, or similar services.
In a correctly functioning deployment, inbound email arrives at the third-party gateway first. The gateway applies spam filtering, policy enforcement, and security scanning, then passes clean email to Exchange Online via a configured relay path. The expectation is that Exchange Online only receives email that has already passed through the external filter.
The problem is that Exchange Online’s *.mail.protection.outlook.com endpoint is publicly accessible and accepts direct SMTP connections. An attacker who identifies this endpoint can bypass the third-party gateway completely, sending email directly to Exchange Online while impersonating any sender address. Because the email arrives through what Exchange treats as a trusted internal pathway, the standard anti-spam and anti-phishing policies – including the “Honor DMARC” setting – do not apply. The spoofed message is delivered to the inbox.
From the recipient’s perspective, the email appears to come from a legitimate sender. The From address can say anything: a colleague, an executive, a trusted vendor, a bank. The actual sending infrastructure is invisible unless the recipient inspects the raw message headers.
Why Authentication Cannot Help in This Scenario
SPF, DKIM, and DMARC are designed to verify that a message claiming to come from a given domain was actually sent by authorized infrastructure for that domain. They work as receiving-server-side checks: the recipient’s mail server queries the sender’s DNS records and verifies signatures on the message.
Ghost-Sender does not attempt to forge DMARC-passing credentials. It does something different: it exploits the fact that Exchange Online’s inbound processing treats direct connections to its endpoint differently from messages relayed through the external gateway. When an email arrives directly at *.mail.protection.outlook.com in this configuration, Exchange Online applies a different policy context – one in which the Honor DMARC check is not triggered.
This means that even if the spoofed domain has a p=reject DMARC policy, the message is still delivered. The sender’s DMARC record says “reject unauthenticated email claiming to be from this domain,” but Exchange Online is not asking the question in the first place.
It is worth being precise about what this means. Ghost-Sender does not break DMARC as a protocol. It bypasses the condition under which Exchange Online consults DMARC policy for inbound mail in hybrid deployments. The protocol itself functions correctly. The gap is in how Exchange Online decides when to apply it.
The Scale of Exposure
InfoGuard’s research indicates that this is not an edge-case misconfiguration. Any organization that uses Exchange Online alongside an external MX record – for spam filtering, archiving, compliance scanning, or email gateway purposes – is potentially vulnerable if specific mitigations have not been applied. Preliminary analysis of publicly scanned environments suggests that fewer than half of organizations in this configuration have deployed a mitigation.
The category of affected organizations is significant. Third-party email gateways are standard infrastructure in financial services, healthcare, legal, and enterprise environments – precisely the categories of organizations most frequently impersonated in business email compromise and spear phishing campaigns. An attacker who can deliver email that appears to come from an internal finance department address, or from a trusted external law firm, in an environment where recipients have no reason to suspect spoofing, has bypassed a substantial portion of the organization’s email security investment.
What Microsoft Said
InfoGuard contacted Microsoft on April 21, 2026. Microsoft’s Security Response Center closed the initial report as a non-vulnerability. Subsequent engagement resulted in Microsoft acknowledging the issue as a known architectural limitation on May 29, 2026, with no commitment to a platform-level fix.
This response places Ghost-Sender in the same category as several other Exchange Online architectural behaviors that have been raised as security concerns over the years: Microsoft’s position is that correct configuration of the product avoids the vulnerability, and that the responsibility for correct configuration belongs to the customer.
Whether or not that position is reasonable, the practical consequence is that every Exchange Online environment running an external MX record needs to be checked and, if necessary, remediated by its administrator. There is no patch coming.
The Two Mitigations
InfoGuard identified two configurations that block Ghost-Sender:
The first is deploying a Partner Organization inbound connector with a wildcard domain match and IP-based or certificate-based sender restriction. This connector tells Exchange Online to accept inbound email only from specified IP ranges or certificates, rejecting direct connections from unapproved sources before mail processing begins.
The second is creating a priority-0 mail flow rule – the highest available priority – that quarantines all inbound mail not originating from approved IP ranges or not carrying the X-MS-Exchange-Organization-AuthAs: Internal header. This rule intercepts messages that arrive through the direct path and isolates them before they reach recipient inboxes.
Both mitigations require administrative access to Exchange Online and careful configuration to avoid disrupting legitimate mail flow. Implementing them without testing can cause legitimate mail delivery failures, so the recommended approach is to first set the mail flow rule to prepend a warning header rather than quarantine, verify that all legitimate message sources are correctly identified, and then harden to quarantine.
What This Means for Your DMARC Strategy
Ghost-Sender does not change the value of DMARC enforcement. If your domain has a p=reject policy, it is still correctly preventing your brand from being used in phishing campaigns that go through standard delivery paths. The vast majority of email infrastructure on the internet applies DMARC checks as expected.
What Ghost-Sender demonstrates is a narrower problem: specific Exchange Online configurations create a condition where DMARC is not consulted for inbound mail, regardless of the sender domain’s policy. Organizations running Exchange Online with an external MX record need to verify that they have applied mitigations, independent of their own DMARC deployment status.
DMARC aggregate reporting can help here in an indirect way. If your domain is at p=reject and your aggregate reports show unusual sending sources – sources you do not recognize and did not authorize – it may indicate that your domain is being used in Ghost-Sender-style attacks targeting other organizations with similar configurations. The reporting gives you visibility into how your domain is being used across the internet, even when the attack path bypasses DMARC evaluation on the receiving end.
The structural lesson from Ghost-Sender is the same one that has emerged from every major email spoofing disclosure: authentication gaps exist at every layer of the email infrastructure stack, and any single one of them can render the others ineffective in specific scenarios. The organizations best protected are those that combine correct DMARC enforcement on their own domains with active monitoring of what is being delivered to their users – not just what is being sent on their behalf.
Excello Mail provides DMARC aggregate report analysis, sending source discovery, and guided enforcement for every domain you manage. Sign up for free to Excello Mail and get complete visibility into who is sending email as your brand – and what is reaching your users’ inboxes.