Ghost Sender in Exchange Online: An MX Record Is Not a Firewall
Direct delivery to Exchange Online bypasses an upstream gateway if the tenant does not explicitly block it. The risk is real; the cause is an incomplete mail flow configuration.
The attack vector described by InfoGuard Labs as “Ghost Sender” is real: an attacker can bypass an upstream email gateway and deliver directly to Exchange Online. However, this requires the tenant to continue accepting that direct route. This is not a universal vulnerability in Exchange Online, but an insufficiently secured mail flow topology.
A Mail Transfer Agent that serves mailboxes for a domain generally accepts SMTP connections from the internet. The MX record tells legitimate senders the intended delivery route. It is neither a firewall rule nor an access list, and it does not prevent anyone from directly contacting a known Exchange Online endpoint.
What “Ghost Sender” actually shows
The scenario described by InfoGuard Labs looks like this:
- An organization hosts its mailboxes in Exchange Online.
- The public MX record points to an upstream Secure Email Gateway.
- The Exchange Online endpoint at
*.mail.protection.outlook.comremains directly accessible from the internet. - The administrator has not restricted Exchange Online so that only the upstream gateway may deliver to it.
- An attacker ignores the MX record and submits their message directly to Exchange Online.
The intended route is therefore:
Internet -> Drittanbieter-Filter -> Exchange Online -> PostfachHowever, this route remains open:
Angreifer -> Exchange Online -> PostfachThis is a serious misconfiguration. The upstream filter can be bypassed through this route; spoofed senders, phishing, and CEO fraud are made considerably easier as a result. InfoGuard deserves credit for making the problem visible, investigating its prevalence, and publishing an easy-to-use test.
But where exactly is the product flaw here?
The media framing does little to help put this into perspective. Heise headlines that Exchange Online lets spoofed emails “pass without objection”, even though only certain insufficiently hardened third-party and hybrid configurations are affected. Crow in the Cloud puts it much more accurately: not a security hole in the narrow sense, but a design and configuration problem.
“An MTA is doing MTA things”
Every Exchange Online tenant has a public SMTP endpoint. This endpoint is not a secret, nor should it be. Microsoft itself explains that Exchange Online accepts messages addressed directly to mailboxes hosted there by default: that is simply how email works.
SMTP itself also describes the MX record as a mechanism for determining the regular destination system. This does not create an obligation for the destination server to reject connections through every other reachable host. An attacker does not have to follow the signposted route. If another MTA is reachable, knows the recipient domain, and accepts the message, it will be tried—much like spammers have attempted to contact poorly protected backup MX systems for decades.
Anyone placing a third-party filter upstream changes the default topology. “Exchange Online is my internet mail gateway” becomes “only my third-party gateway may hand off internet mail to Exchange Online.” This new Trust-Border is not created by a DNS entry. It must be explicitly enforced on the receiving system.
This is precisely what Microsoft documents: with an external MX, an inbound connector of type Partner should be created that accepts only the certificate or source IP addresses of the upstream service for SenderDomains *. Messages delivered directly past the gateway are then rejected. This is stated verbatim in Microsoft’s guide “Manage mail flow using a third-party cloud service with Exchange Online”.
Frank Carius also describes this “side entrance” in detail in the MSXFAQ.
SPF, DKIM, and DMARC are not bouncers
InfoGuard shows messages for which SPF, DKIM, and DMARC fail yet which still reach the mailbox. That looks spectacular, but it is not a cryptographic “bypass” of those mechanisms. The emails do not pass successfully at all. They deliver fail. What matters is which local action the receiving system derives from that result.
SPF checks whether a system is authorized to send for the envelope sender. DKIM checks a signature. DMARC ties these results to the visible sender domain and publishes a requested handling policy. Even the current DMARC standard, RFC 9989, explicitly states that the recipient may consider this requested handling but is not required to do so. DMARC is an important signal, but not a network access control.
With an upstream gateway, Exchange Online also initially sees the gateway’s IP address rather than that of the original sender. This is what Enhanced Filtering for Connectors is for: it reconstructs the original source and improves SPF, DKIM, DMARC, anti-spoofing, and anti-phishing evaluations. However, Enhanced Filtering is not a lock either. It does not replace the restrictive partner connector.
The misconfiguration becomes especially obvious when an administrator weakens or entirely bypasses EOP checking with an SCL bypass because the upstream product is supposed to filter already, while simultaneously leaving direct internet delivery open. In that case, they have not had one protection mechanism “bypassed”; they have deliberately provided no effective protection for one of two entry points.
Microsoft can certainly be criticized if a message with a clearly visible authentication failure lands in the inbox without a warning. The semantics of connector types, the documentation, and missing warnings in the Configuration Analyzer can be criticized. These are all legitimate points. However, the existence of a publicly reachable SMTP endpoint is not a security vulnerability.
“Direct Send” is not the same as “direct delivery”
The discussion conflates two things:
- Direct Send is Microsoft’s term for anonymous messages whose envelope sender (
5321.MailFrom) uses an accepted domain belonging to the tenant. - Direct delivery to Exchange Online generally means an SMTP message that ignores the published third-party MX and is submitted directly to the Exchange endpoint. The sender may also use any external domain.
Direct Send has its own switch:
Set-OrganizationConfig -RejectDirectSend $trueThe switch is useful when Direct Send is not needed. It prevents internal domain spoofing through this path. However, it does not close the entire side entrance for arbitrary external senders. Microsoft describes the exact scope in the cmdlet documentation for RejectDirectSend. Anyone wishing to prevent “Ghost Sender” completely still needs access restrictions through a partner connector or an appropriate mail flow rule.
Does Microsoft really have to do everything for the administrator?
No. Anyone adding an extra mail filter to a production transport chain assumes responsibility for that transport chain.
The provider cannot reliably guess whether scanners, multifunction devices, SaaS services, hybrid servers, partner relays, or other legitimate systems besides the external MX still need to send directly to Exchange Online. An automatic “the MX points somewhere else, so block everything else” would disrupt desired mail flows in many real-world environments. That is why the administrator must explicitly define the intended trust boundary.
Still, Microsoft should make it easier for those responsible. A good Configuration Analyzer should detect an external MX without a restrictive partner connector and provide a clear warning. The setup dialog could explain that a connector of type “Your organization” identifies matching connections but does not automatically reject nonmatching ones. Secure-by-default switches and better operational reports would also be welcome.
That would be sensible product hardening. But it does not change the technical assessment: an insecure special topology remains an insecure configuration and does not become a zero-day merely because it is widespread.
How to close the side entrance
For environments with an upstream filter, at least these items belong on the checklist:
- Document the mail flow completely. Which systems may actually deliver to Exchange Online? This also includes hybrid, application, and emergency paths.
- Set up a restrictive partner connector. Use
SenderDomains *and restrict delivery to a certificate (preferred) or maintained source IP ranges. A connector of typeOnPremisesor “Your organization” does not enforce this default-deny effect (see, for example: Mail routing between Apache James and Exchange Online). - Configure Enhanced Filtering correctly. If EOP is still expected to filter, the original IP and sender information must be reconstructed properly. Blanket SCL-
-1bypasses should be reviewed critically. - Disable Direct Send if unused. First use Message Trace or the available reports to check whether scanners or applications depend on it.
- Do not switch blindly. Test and then monitor gateway IP ranges, certificate changes, hybrid mail flow, and
onmicrosoft.com-, Teams-, and other special paths.
A simplified example of the IP-based variant is:
New-InboundConnector `
-Name "Only from upstream mail gateway" `
-ConnectorType Partner `
-SenderDomains * `
-RestrictDomainsToIPAddresses $true `
-SenderIpAddresses <IP-Bereiche-des-Gateways> `
-RequireTls $trueWhere possible, certificate binding should be preferred over an IP allowlist. Changes should first be made in a controlled test, because an incorrect allowlist can quickly turn the open side entrance into a complete mail outage.
The simple self-test
The test shown by InfoGuard (and MSXFAQ) is useful:
Send-MailMessage `
-SmtpServer <tenantname>.mail.protection.outlook.com `
-To admin@<tenantdomain> `
-From noreply@example.com `
-Subject "EXO Nebeneingang" `
-Body "Testmail direkt zum Tenant"With a correctly restricted partner connector, an SMTP rejection such as 5.7.51 TenantInboundAttribution; Rejecting is to be expected. An alternative transport rule may first accept the message and then move it to quarantine; therefore, in addition to the SMTP response, Message Trace, quarantine, and the mailbox must also be checked. Send-MailMessage (deprecated) is used here only as an easy-to-understand illustration. Any controlled SMTP testing tool serves the same purpose.
A useful test with a misleading label
“Ghost Sender” is not a new SMTP exploit. It is a catchy name for an open side entrance whose protection Microsoft has documented for a long time and which the administrator left open.
The irony is that InfoGuard itself describes the issue in its own article as a “widespread and systematic misconfiguration” and concludes with the sentence “Ghost-Sender is a misconfiguration.” Microsoft’s Security Response Center also initially did not classify the report as a security vulnerability. The facts are therefore present in the article: unfortunately, only the title, test email, and “Vulnerability” branding suggest a more dramatic interpretation.
The useful part of the publication is the wake-up call: many companies apparently have not properly locked down their mail flow. The problematic part is the claim that Exchange Online has a universal security vulnerability because of this. No: Exchange Online initially behaves like an MTA here. It becomes insecure through an incompletely configured trust boundary.
Does Microsoft really have to do everything for the administrator? No. But apparently, it is necessary to keep reminding people that DNS routing does not replace access control.
Is your mail flow secure?
Not sure whether your Exchange Online tenant also has an open side entrance? adeptio reviews your complete mail flow: from MX records, connectors, and third-party gateways to EOP, SPF, DKIM, DMARC, and Direct Send. Practical, independent, and with specific recommendations.
If you would like to have your mail flow reviewed or properly secured, feel free to schedule a no-obligation consultation:
Comments
Comments are loaded from GitHub / Giscus.