The Ghost-Sender Exchange Online Flaw: What to Check Beyond DMARC

Ghost-Sender is a newly documented flaw in how Microsoft Exchange Online accepts incoming mail. It lets an attacker deliver a fake email that looks like it comes from a coworker or a trusted brand, even though the message fails every authentication check that is supposed to catch forged mail. Security researchers at InfoGuard published the technique on June 9, 2026, and Microsoft has classified it as a known architectural limitation rather than a bug it plans to patch.

The flaw affects organizations that route incoming mail through a third-party spam filter before it reaches Microsoft 365. This setup is common, especially among companies whose IT is managed by an agency or a service provider. DMARC enforcement is the usual defense against spoofing, and it does not stop this attack, because the spoofed mail enters through a path where the DMARC verdict is never acted on. The sections below explain how the technique works, why authentication alone cannot stop it, and which Microsoft 365 settings close the gap.

What's in This Guide

• What Is the Ghost-Sender Flaw?
• How Attackers Bypass Exchange Online's Filtering
• Why Don't SPF, DKIM, and DMARC Catch This?
• Microsoft's Response: A "Known Architectural Limitation"
• Are You Exposed? How to Check Your Exchange Online Setup
• What To Do Now: Practical Mitigations
• The Practical Takeaway

What Is the Ghost-Sender Flaw?

Ghost-Sender is a technique for delivering spoofed email into Microsoft 365 inboxes. The message claims to come from a trusted colleague or a well-known brand. The authentication checks recognize the claim as false, and Exchange Online delivers the message anyway.

Researchers at InfoGuard disclosed the technique publicly on June 9, 2026. In their testing, a message claiming to come from noreply@microsoft.com reached the inbox with a failing result on every check: SPF failed, DKIM was missing, and DMARC failed. Results like these normally mean the message is rejected or lands in the spam folder. This one was delivered.

The technique needs no stolen passwords and no changes to the target's DNS. It abuses how Exchange Online routes incoming mail, so it works even against a domain whose SPF, DKIM, and DMARC records are all configured correctly.

How Attackers Bypass Exchange Online's Filtering

Many organizations do not point their domain's mail records straight at Microsoft. They put a third-party security gateway in front: a spam and malware filter from a vendor such as Proofpoint, Mimecast, or Barracuda. Their MX record (the DNS entry that tells the world where to deliver mail) points at that filter, not at Microsoft. Mail is supposed to flow in one direction: internet to filter, filter to Microsoft, Microsoft to the inbox.

The problem is that Microsoft's own delivery address stays reachable the entire time. Every Microsoft 365 organization (a "tenant" in Microsoft's terminology) has a direct delivery address in the form yourdomain.mail.protection.outlook.com, and it accepts mail from anyone on the internet. An attacker who sends to this address reaches Exchange Online directly and skips the external filter completely. The filter never sees the message, so none of its anti-spoofing or anti-phishing rules run.

Because the message arrives through Microsoft's own infrastructure, Exchange Online treats it with more trust than a message arriving from the open internet. This misplaced trust is the core of the flaw.

Why Don't SPF, DKIM, and DMARC Catch This?

SPF, DKIM, and DMARC are checks a receiving mail server runs to decide whether a message really comes from the domain in its From address. They are the core defense against domain spoofing, and they stop the large majority of it.

Ghost-Sender does not defeat these checks. It sidesteps the point in delivery where their result is acted on. The spoofed message does fail all three, exactly as InfoGuard's test showed. But the mail has already been accepted at Microsoft's direct delivery address, and Exchange Online does not apply the same DMARC enforcement to mail it treats as internal. The authentication verdict is "fail," and the message is delivered regardless.

None of this means DMARC is optional. DMARC is still the control that stops everyday spoofing: the forged supplier invoices, the fake executive wire requests, and the lookalike-domain phishing that never reaches your Exchange endpoint. Ghost-Sender is a narrow architectural exception, and it changes nothing about why you need DMARC underneath it.

Messages spoofed in this way land on infrastructure where clean authentication is already hard to maintain. In DMARCeye's Q1 2026 industry report, mail attributed to Microsoft's infrastructure showed 90.0% compliance, with SPF failing on 26.6% of messages and DKIM on 19.6%. A meaningful share of legitimate Microsoft-originated mail already does not authenticate cleanly. As the Q1 report notes, low compliance on a major provider is almost always a configuration problem on the sender side, not a flaw in the platform itself. The usual causes are customers who have not added the right DKIM keys to their DNS, or whose sending has outgrown their SPF record.

The point is not that Microsoft's mail is weak. It is that Microsoft 365 mail flow is complicated to configure correctly, and Ghost-Sender exploits one specific gap in how inbound routing is wired.

You can download the full report here:

Microsoft's Response: A "Known Architectural Limitation"

InfoGuard reported the issue to Microsoft on April 21, 2026. Microsoft deployed an internal mitigation the following day, then rolled it back on April 27. On May 29, 2026, Microsoft classified Ghost-Sender as a known architectural limitation rather than a product vulnerability, and as of that date there was no platform-level fix.

In practice, this means the responsibility to close the gap sits with each organization, not with a patch that arrives automatically. Microsoft is tightening related defaults, and new tenants now have Direct Send (the feature the attack relies on) rejected by default after a change Microsoft began rolling out in early 2026. Existing tenants keep their current configuration until an administrator changes it.

If you run Microsoft 365 with an external filter, you cannot wait for a fix to arrive. You have to check and adjust the configuration yourself.

Are You Exposed? How to Check Your Exchange Online Setup

You are potentially exposed if two things are true: your organization uses Microsoft 365 (or Exchange in hybrid mode), and your domain's MX record points to a third-party filter instead of directly to Microsoft. This covers a large share of managed tenants, because placing a dedicated security gateway in front of Microsoft is a common design.

InfoGuard's scanning found that over 20% of the Exchange Online domains it tested through bug-bounty programs appeared vulnerable, and that fewer than half of the environments using an external MX record had any mitigation in place.

To check a tenant, work through three questions:

• Where does the MX record point? If it points somewhere other than *.mail.protection.outlook.com, mail is routed through a third party and the direct Microsoft endpoint is still exposed.
• Is the inbound connector restricted? In the Exchange admin center, review your inbound connectors. A connector that restricts senders by IP range or TLS certificate is the control that closes the gap. If no such restriction exists, the tenant is likely open.
• Is Direct Send enabled? Direct Send lets mail reach mailboxes without authenticating. If it is on and no transport rule compensates, spoofed mail can get through.

What To Do Now: Practical Mitigations

Two configurations reliably block Ghost-Sender, and Microsoft's own Direct Send control adds a third layer.

1. Restrict the inbound connector. Create or adjust a Partner Organization inbound connector so it applies to mail from any domain and only accepts messages that pass IP-range or TLS-certificate validation. This tells Exchange Online to trust inbound mail from your filter's addresses, not from anyone who happens to find the direct delivery address.
2. Quarantine untrusted internal-looking mail. Add a top-priority (priority 0) mail flow rule that quarantines any inbound message that does not carry the X-MS-Exchange-Organization-AuthAs: Internal header from an approved source, or that does not come from your approved IP ranges. In plain terms, this catches mail that claims to be internal but did not arrive through a trusted path.
3. Turn off Direct Send. Direct Send is the Microsoft 365 feature that lets devices and apps send mail through the tenant without authenticating. Disabling it (the RejectDirectSend setting) removes the specific path Ghost-Sender abuses. Confirm your legitimate printers, scanners, and line-of-business apps use an authenticated connector first.

This is not a DMARC problem but a Microsoft 365 configuration problem with a Microsoft 365 solution. What DMARC monitoring adds is visibility. When a spoofed message fails SPF, DKIM, and DMARC, Microsoft still records that failure and includes it in your DMARC aggregate reports. A tool that reads those reports for you shows spoofed, authentication-failing mail being sent as your domain from sources you do not recognize. This is exactly the signal that a technique like Ghost-Sender is being used against you. DMARCeye's free plan covers one domain and turns that raw report data into a plain-language view of who is sending as you and what is failing.

If you want to see what your domain publishes right now, start with its current DMARC record:

The Practical Takeaway

Email security works in layers, and no single layer covers everything. DMARC is the essential core: it authenticates the domain in your From address and stops the broad category of spoofing that makes up most email fraud. This flaw does not weaken it. What the flaw exposes is a different layer: the trust Microsoft 365 places in its own internal mail flow. DMARC was never designed to govern this layer, and only your Microsoft 365 configuration can secure it.

For agencies and IT providers, the message to a client is both parts at once: keep your DMARC enforcement in place because it stops the majority of spoofing, and close the Exchange Online gap because DMARC cannot reach it.

This two-part answer is the work we think matters most. DMARCeye exists to give people clear visibility into who is sending as their domain, and to explain spoofing, the real risk it carries, and the fixes that work, including the ones like this that sit beyond DMARC itself.