The Silent Spoofing Threat
You've spent years hardening your domain's email authentication policies. SPF, DKIM, DMARC—they're all dialed in, set to strict enforcement, and monitored constantly. Yet, an attacker with a one-line PowerShell script can still send an email that appears to come from your CEO. Complete with their actual Outlook profile picture, the message lands directly in your employees' inboxes. The message bypasses every single security check you have set up without triggering a warning banner. It sounds like a sophisticated cryptographic exploit. It isn't. It's the reality of a widespread configuration gap in Microsoft Exchange environments, now known as Ghost-Sender.
First disclosed by Swiss cybersecurity firm InfoGuard in June 2026, Ghost-Sender exposes a systemic weakness in how Microsoft Exchange Online and hybrid deployments handle incoming mail when routed through third-party security gateways. This isn't a theoretical exercise. Support communications from Microsoft indicate that this vulnerability is being actively abused in the wild. If your organization routes its external inbound mail through an external secure email gateway (SEG) rather than going directly to Exchange Online entrypoints, you are likely vulnerable.
For security teams, the threat is frustrating. We rely on SPF, DKIM, and DMARC as our foundational perimeter trust checks. We assume that if a message claims to come from an internal domain but originates from an external IP, DMARC will block it. Ghost-Sender breaks that assumption completely. Because Microsoft Exchange defaults to accepting any direct inbound mail, attackers can side-channel your external gateway, connect directly to your Microsoft 365 tenant, and drop messages directly into user mailboxes. To Microsoft, this is an architectural limitation. To security practitioners who have to deal with the fallout of business email compromise, it is a glaring vulnerability that needs immediate mitigation.
Behind the Ghost-Sender Vulnerability
To understand how Ghost-Sender works, you have to look at the mechanics of mail routing. In a standard enterprise environment, the organization's MX records point to a third-party hygiene filter like Proofpoint, Mimecast, or Barracuda. These filters scan inbound mail for malware, spam, and phishing attempts before forwarding the clean messages to Exchange Online. This setup creates a funnel. You assume that your Exchange tenant only receives mail from the IP addresses of your third-party filter.
But Exchange Online is designed to be highly accessible. By default, Microsoft 365 tenants maintain a public-facing endpoint that can receive direct SMTP connections. Under normal circumstances, external senders find your mail servers via DNS MX queries and route mail through your SEG. But an attacker doesn't have to follow DNS. They can resolve the underlying tenant's direct endpoint (typically something like yourdomain-com.mail.protection.outlook.com) and send mail directly to it.
When this direct connection occurs, Exchange Online accepts the email. If the email claims to come from an internal sender, Exchange does not automatically apply the SPF check to fail the mismatch to the attacker's IP. Why? Because the tenant's configuration signals that it expects clean, forwarded mail from an external system. If the internal routing connectors aren't explicitly locked down, Exchange assumes the email has already been validated or is part of a trusted internal direct delegation.
The payload delivery is simple. An attacker needs only a single PowerShell command using standard SMTP send functions to construct and transmit the message. They connect directly to the Exchange Online endpoint, specify the sender as [email protected], the recipient as [email protected], and transmit the headers. Because the message enters the tenant directly, the email authentication stack gets confused. The DMARC check is bypassed because Exchange processes the mail as if it bypassed the external boundary, and the recipient sees a perfect replica of an internal message.
Organizations Exposed by External MX Records
The vulnerability doesn't affect every single Exchange customer, but it does target a very common architecture. If your MX records point directly to Microsoft 365, you are generally protected because Microsoft's boundary protection handles the incoming SPF/DMARC checks. However, if you route traffic through an external MX record—whether due to compliance requirements, deep content archiving, or legacy security preferences—you are exposed.
Hybrid Exchange deployments are particularly vulnerable. In these environments, mail often paths from the cloud to on-premises servers and back, using complex routing rules. If a security team fails to explicitly lock down the inbound connectors to only accept traffic from the specific IP ranges of their secure email gateway, the Exchange tenant remains open to the public internet.
According to InfoGuard's data, the scope of this exposure is massive. Less than half of the organizations running Exchange Online with an external MX record have actually implemented the necessary IP restriction or connector policies to block this type of direct ingress. Many administrators assume that pointing their MX record to an external gateway is sufficient to redirect all traffic. They forget that the tenant's direct endpoint remains active and reachable. It's the security equivalent of installing a state-of-the-art security gate on your driveway but leaving the side fence completely down. Attackers don't bother walking through the front gate; they walk straight through the open yard.
The Real-World Phishing Risks
The impact of this configuration gap is severe because it destroys the visual cues users rely on to spot phishing. Most organizations use transport rules to inject warning banners when an email originates from outside the company. These "EXTERNAL" tags serve as a constant reminder to treat links and attachments with caution. With Ghost-Sender, because Exchange Online accepts the mail and treats it as internal, those external warning banners never trigger.
Even worse, Outlook resolves the sender's profile picture for internal users. When an employee receives an email claiming to be from the CEO, and they see the CEO’s face, they have no reason to suspect foul play. They act on the instruction. This makes the vulnerability an ideal vector for wire transfer fraud, credential extraction, and payroll redirection—a challenge similar to how modern phishing campaigns leverage trust-based credentials, as discussed in our analysis of how attackers bypass MFA.
Consider an attacker impersonating Microsoft's own billing or system administration accounts. They can send a notification stating that the organization's Azure tenant is about to be suspended due to an outstanding invoice, directing the IT administrator to a phishing site. If the administrator checks the headers later, they might notice the bypass, but by then, the developer credentials or billing details are gone. The level of trust that users place in internal mail communications is high, and this exploit manipulates that trust.
Microsoft's Controversial Design Choice
The response from Microsoft highlights a recurring friction point between cloud vendors and enterprise security teams. When InfoGuard reported Ghost-Sender to the Microsoft Security Response Center (MSRC) in April 2026, the case was promptly closed. Microsoft's stance was that this is not a product vulnerability but an architectural limitation. They argue that because customers chose to route their MX records to a third party, it is the customers' responsibility to secure their own inbound connectors.
In May 2026, Microsoft general support suggested changing the MX records back to M365 or inserting custom headers in forwarded emails. As InfoGuard pointed out, adding headers doesn't stop attackers from connecting directly to the tenant and fabricating those headers themselves.
This stance on configuration responsibilities differs from their direct security updates for product-level defects, such as when Microsoft patched an Exchange Server zero-day in June 2026 to address active exploitation of Outlook Web Access.
Security industry analysis has been critical of this hands-off approach. While SMTP authentication issues are a recurring headache in enterprise environments, as detailed in our analysis of previous Exchange spoofing incidents, Ghost-Sender introduces a far more insidious twist. Microsoft actually deployed a mitigation in their environment, observed the fallout, and subsequently rolled it back. The rollback indicates that enforcing strict RFC compliance or blocking direct-to-tenant email by default causes massive business disruption for customers who rely on complex, non-standard mail routing. Consequently, the burden of protection has been shifted entirely onto the customer's security team.
Step-by-Step Mitigation Methods
You cannot rely on Microsoft's Standard or Strict preset security policies to protect your tenant from Ghost-Sender. Even the "Enhanced Filtering for Connectors" will not block this if it isn't specifically configured. You must actively modify your Exchange Online connector settings.
There are two primary methods to close this ingress hole. The first, and most robust, is to configure a Partner Organization Connector. Go to the Exchange Admin Center, navigate to Mail Flow, and select Connectors. Create an inbound connector from "Partner Organization" to "Office 365." In the configuration settings, restrict the connector to only accept email sent from the specific IP addresses of your third-party secure email gateway. Any email hitting your tenant that does not come from these dedicated IP blocks should be blocked. If you choose this route, verify that you have covered all your gateway provider's egress IP ranges, or you will experience dropped emails.
The second method involves a fail-safe Mail Flow Rule. If your routing is too complex for IP-locked connectors, you can create a transport rule that identifies spoofed internal mail. Build a rule that matches all incoming messages where the X-MS-Exchange-Organization-AuthAs header is not set to Internal and where the sender's domain matches your own internal domains. You must pair this with an IP whitelist exception containing your gateway's ranges. Set the action to redirect the matching emails to quarantine.
Additionally, you should disable Direct Send capabilities in your Exchange tenant. Direct Send allows devices and applications (like copiers or legacy LOB apps) to send mail to internal users directly through the default tenant MX endpoint. Disabling this shuts down the primary pathway Ghost-Sender exploits for internal-to-internal spoofing.
Detecting Attack Attempts After Patching
Closing the configuration hole is only half the battle. You also need to know if you've already been targeted. Unfortunately, identifying historical compromise is difficult. Because of the vast array of licensing tiers and the varying compliance logging levels across tenants, there's no single event ID in Unified Audit Logs that cleanly screams "Ghost-Sender exploit."
Your best option is to look at your mail headers. Specifically, analyze the received headers of message traffic that did not flow through your gateway. A legitimate message from your gateway will show a hop chain starting from the external sender, hitting the gateway's IP, and then forwarding to Microsoft's IPs. A Ghost-Sender exploit will bypass the gateway completely, with the first hop in the header showing the attacker's public IP connecting directly to your Outlook endpoints.
If you run security analytics, you can query your message tracing logs. Look for emails that claim to come from external domains (or internal ones) but show an ingress IP that does not belong to your gateway provider. Be aware that attackers may attempt to spoof the gateway's header syntax. To do this successfully, they need to know your internal IP addresses or the specific hostnames of your boundary appliances. If you find discrepancies in the hop times, or mismatched hostnames in the Received: block, treat those messages as highly suspicious.
Securing Exchange Against Ghost-Sender
InfoGuard has released a testing tool that allows security administrators to verify if their domains are vulnerable. The tool attempts a direct SMTP send to an authorized email address within the host domain, bypassing the configured MX records. Running this tool should be part of your next vulnerability management cycle. If the test mail arrives in your inbox with the spoofed address, your current configurations are insufficient.
Ultimately, Ghost-Sender exposes the danger of default-open cloud architectures. Security architects must stop viewing cloud environments as secure by default and start treating them like any other exposed network space. If you do not explicitly drop traffic at the boundary, you must assume that someone is going to exploit the opening. Lock down your inbound connectors, monitor your header logs, and don't wait for a vendor patch that is never coming.