Why the Ghost‑Sender Attack on Microsoft Exchange Is Being Widely Exploited

Vulnerability Overview

InfoGuard Labs discovered a configuration flaw in Microsoft Exchange Online called Ghost‑Sender. When an organization routes inbound mail through a third‑party gateway via its MX record, Exchange Online still accepts mail sent directly to its public SMTP endpoint <tenant>.mail.protection.outlook.com, bypassing SPF/DKIM/DMARC checks.

Mail Flow Comparison

Normal flow with third‑party gateway

Attacker → MX record → Third‑party gateway (filter) → Exchange Online → User mailbox

SPF/DKIM/DMARC validation occurs at the gateway.

Ghost‑Sender flow

Attacker → Direct delivery to Exchange Online public endpoint → User mailbox

The endpoint is publicly reachable and accepts mail without authentication.

Attack Evidence

In a test on a tenant the following Authentication‑Results header was observed:

Authentication-Results: spf=fail (sender IP redacted) smtp.mailfrom=microsoft.com; dkim=none (message not signed) header.d=none; dmarc=fail action=oreject header.from=microsoft.com; compauth=none reason=451
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate redacted as permitted sender)

Despite SPF failure, missing DKIM signature, and DMARC rejection, the message was delivered to the inbox.

Impact Scope

More than 50 % of organizations that combine an external MX gateway with Exchange Online have no mitigation configuration.

Approximately 20 % of bug‑bounty target domains are immune.

About 25 % of tenants with a Partner Organization connector remain vulnerable.

Even tenants with Microsoft “Standard Protection” or “Strict Protection” presets are exploitable.

Why Traditional Email Security Fails

SPF

Exchange Online does not perform SPF verification on mail delivered directly to the public endpoint, so the SPF check is bypassed.

DKIM

DKIM validation is also skipped for direct deliveries, allowing unsigned messages.

DMARC

DMARC enforcement is ineffective because the DMARC check is not executed on the bypassed path.

Microsoft’s Position

Microsoft Security Response Center classified the issue as “Not a Vulnerability” and treated it as a regular support case. The suggested mitigation is to point the MX record directly to Microsoft 365 or to add additional headers on forwarded mail.

Red‑Team Exploitation

Prerequisites:

Target domain that uses an external MX gateway with Exchange Online.

The tenant’s SMTP endpoint, discoverable via DNS (e.g., <domain>.mail.protection.outlook.com).

An SMTP client; a single PowerShell command is sufficient.

Example PowerShell command:

Send-MailMessage -SmtpServer <target>.mail.protection.outlook.com `
    -To [email protected] `
    -From [email protected] `
    -Subject "Urgent: Invoice Payment Required" `
    -BodyAsHTML "<h1>Payment Required</h1>..." `
    -Credential (Get-Credential)

Typical high‑value scenarios include phishing, business‑email compromise, supply‑chain attacks, and credential harvesting.

Mitigation Measures

Option 1 – Partner Organization connector (recommended)

Create a “Partner Organization” connector in the Exchange Admin Center.

Set the domain pattern to a wildcard ( *) to match all sender domains.

Restrict the connector to specific IP addresses or certificates, rejecting unauthenticated direct deliveries.

Verify that legitimate internal mail flow is not disrupted.

When correctly configured Exchange Online returns:

5.7.51 TenantInboundAttribution; Rejecting.

Option 2 – Transport rule (mail flow rule)

Create a high‑priority (priority 0) rule that isolates any message where the X‑MS‑Exchange‑Organization‑AuthAs header does not contain “Internal” and the sending IP is not authorized.

Action: route the message to a quarantine mailbox and stop further rule processing.

Note: the rule cannot be automatically detected by the ghost‑sender.com testing tool; manual verification is required.

Additional recommendation: disable the “Direct Send” feature to prevent internal‑sender spoofing via that path.

Detection Tool

InfoGuard Labs provides an online tester at https://ghost-sender.com/. Workflow:

Enter a list of domains (one per line).

The tool resolves MX records, identifies the Exchange Online endpoint, and performs an SMTP probe.

If the server accepts the RCPT TO command, the domain is flagged as vulnerable.

Administrators can also use the test‑mail feature to verify mitigation rules.

Detection Challenges

Ghost‑Sender leaves no clear network‑level indicators of compromise. Logs in Exchange Admin Center and Defender for Office 365 do not consistently reveal the source of spoofed messages. The only reliable detection method is to compare inbound mail headers against the expected MX‑gateway path; any deviation suggests a direct delivery.

Conclusion

The design of Exchange Online exposes a publicly accessible SMTP endpoint that accepts mail without authentication, creating a “back door” when an organization relies on an external inbound gateway. Over half of surveyed tenants lack any barrier, and attackers have demonstrated active exploitation. Defenders should assess exposure with the Ghost‑Sender tester and deploy either the Partner Organization connector or the transport‑rule mitigation, while considering pointing MX records directly to Exchange Online Protection.