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 this 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 fundamentally accepts SMTP connections from the internet. The MX record tells legitimate senders the desired delivery route. It is neither a firewall rule nor an access list, and it does not prevent anyone from directly addressing 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 reachable from the internet. - The administrator has not restricted Exchange Online so that only the upstream gateway may deliver mail there.
- 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 defect here?
The media framing does little to put it in context either. Heise headlines that Exchange Online lets spoofed emails “pass through without complaint”, even though only certain insufficiently hardened third-party and hybrid configurations are affected. Crow in the Cloud puts it much more accurately: it is not a security hole in the strict sense, but a design and configuration issue.
“An MTA is doing MTA-Things”
Every Exchange Online tenant has a public SMTP endpoint. This endpoint is not a secret, nor is it intended to be one. 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 identifying 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 as spammers have attempted to reach less well-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.
That is exactly what Microsoft documents: with an external MX, an inbound connector of type Partner should be created that, for SenderDomains *, accepts only the certificate or source IP addresses of the upstream service. 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 but which still land in the mailbox. That looks spectacular, but it is not a cryptographic “bypass” of these mechanisms. The emails are specifically not passing successfully. They return fail. What matters is which local action the receiving system derives from that result.
SPF checks whether a system is allowed to send for the envelope sender. DKIM verifies a signature. DMARC combines these results with the visible sender domain and publishes a desired treatment. Even the current DMARC standard, RFC 9989, explicitly states that the recipient may honor this desired treatment but is not required to do so. DMARC is an important signal, but not a network access control.
With an upstream gateway, Exchange Online initially sees the IP address of that gateway 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 particularly obvious when an administrator weakens or completely bypasses EOP checks using an SCL bypass because the upstream product is supposed to filter anyway, while simultaneously leaving direct internet delivery open. In that case, they have not had a protection mechanism “bypassed”; they have deliberately provided no effective protection for one of two entrances.
Microsoft can certainly be criticized when 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. All of these are 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 refers, at Microsoft, to anonymous messages whose envelope sender (
5321.MailFrom) uses an Accepted Domain of the tenant. - Direct delivery to Exchange Online generally refers to 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 if Direct Send is not needed. It prevents internal domain spoofing through this route. However, it does not close the entire side entrance to arbitrary external senders. Microsoft describes the exact scope in the cmdlet documentation for RejectDirectSend. Anyone who wants to prevent “Ghost Sender” completely still needs access restrictions via a partner connector or an appropriate mail flow rule.
Does Microsoft really have to do everything for the administrator?
No. Anyone adding an additional mail filter to a production transport chain assumes responsibility for that transport chain.
The vendor cannot reliably guess whether scanners, multifunction devices, SaaS services, hybrid servers, partner relays, or other legitimate systems still need to send directly to Exchange Online in addition to the external MX. An automatic “the MX points elsewhere, so block everything else” would interrupt desired mail flows in numerous real-world environments. That is why the administrator must explicitly define the desired trust boundary.
Nevertheless, Microsoft should make it easier for those responsible. A good Configuration Analyzer should detect an external MX without a restrictive partner connector and issue a clear warning. The setup dialog could explain that a connector of type “Your organization” identifies matching connections, but does not automatically reject non-matching connections. 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 mail flow completely. Which systems are actually allowed to deliver to Exchange Online? This also includes hybrid, application, and emergency routes.
- 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 routes.
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 is preferable to an IP allowlist. Changes should first be made in a controlled test, because a faulty 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 expected. An alternative transport rule may initially 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 has left open.
The irony is that InfoGuard itself describes the issue in its own post 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 as a result. No: Exchange Online initially behaves like an MTA here. It becomes insecure through the incompletely configured trust boundary.
Does Microsoft really have to do everything for the administrator? No. But apparently, administrators need to be reminded time and again 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.
Anyone who would like their mail flow reviewed or properly secured can schedule a no-obligation consultation:
Comments
Comments are loaded from GitHub / Giscus.