Ghost-Sender
Exchange Online spoofing tester.
Exchange Online tenants routing mail through third-party filters may allow incoming spoofing from any sender - bypassing SPF, DKIM, and DMARC entirely. Paste a list of your domains to check which are affected.
01 — Vulnerability
When an organisation uses Exchange Online (or on-premises exchange in hybrid mode) with a third-party mail server or spam filter as its MX record, it is possible to send mail from any sender to that organisation when no further hardening was performed. Outlook delivers it to the recipient's inbox without any warning.
This is independent of the configured SPF, DKIM, or DMARC policies of the spoofed sender. External and internal email addresses can be impersonated; for internal senders the recipient's mail client even resolves the profile and picture. As such there is no way for a victim to discern if the mail came from their CEO or was spoofed by an attacker.
From: [email protected] delivered straight into the inbox of a vulnerable tenant - no warnings and no SPF/DKIM/DMARC failure indicators shown.For the full details, disclosure timeline, and Microsoft's response, read the technical write-up on InfoGuard Labs.
02 — impact
Spoofing succeeds against any organisation with a vulnerable configuration, regardless of the spoofed sender's published SPF, DKIM, or DMARC policies.
Fake invoices
Send fraudulent bills that appear to come from trusted vendors, e.g. [email protected], straight into the inbox of vulnerable organisations.
CEO fraud & internal phishing
Impersonate executives or other internal users on the same domain. Recipients see the real internal profile picture next to the spoofed sender.
External-sender phishing
Conduct phishing campaigns from arbitrary external senders. SPF / DKIM / DMARC failures are not surfaced to the recipient.
03 — Ghost-Sender Testing Tool
Exchange Online exposes a direct SMTP endpoint for every tenant on the public internet: <dashed-domain>.mail.protection.outlook.com. When a third-party mail filter is used as the MX record, this endpoint by default accepts mails from any sender without performing any validation.
The tester validates the used MX records, identifies the exchange online endpoint, and connects to this endpoint to issues a RCPT TO command. If the server accepts it, this is an indicator that any sender can deliver mail to that tenant with an arbitrary From: address - SPF, DKIM, and DMARC are not validated.
# 1. MX records check# 2. probe → tenant ingress:C: EHLO evil.tldS: 250 example-com.mail.protection.outlook.com HelloC: MAIL FROM:<[email protected]>S: 250 2.1.0 Sender OKC: RCPT TO:<[email protected]>S: 550 5.7.51 TenantInboundAttribution; … Mitigated
04 — classification
For each input domain the tool resolves MX, derives candidate tenant ingress hostnames, and issues an SMTP probe (EHLO / MAIL FROM / RCPT TO).
Mail is hosted directly on Microsoft 365, or the tenant ingress host rejected the probe. Note that while Ghost-Sender does not apply, internal spoofing by tester may still function if DMARC is misconfigured `p=none` and Direct Send is enabled.
A tenant ingress host accepted the RCPT. An unauthenticated sender can likely spoof this domain if Exchange Online is used for mail. To confirm the vulnerability, the test tool can be used to send a test mail against the mail-infrastructure.
The tenant exists but responded with 5.7.51 + TenantInboundAttribution: inbound attribution is enforced.
Inconclusive: domain uses Google Workspace, MX points to a non-standard protection.outlook.com host, tenant replied 4.4.4 (no Exchange subscription), or no Outlook tenant could be identified.
MX lookup failed (NXDOMAIN, no MX record, or a DNS resolver error).
05 — mitigation
Full details as well as configuration steps can be found in the write-up or the linked Microsoft blog.
Partner connector with strict authentication (Preferred)
Set up a 'Partner Organisation' connector that applies to all incoming emails and rejects emails based on either IP or certificate based validation. It should be ensured that the configuration does not reject emails forwarded by the on-premises mail server.
Transport rule blocking unauthenticated relay (Alternative)
Create a mail flow rule that quarantines all emails without the
X-MS-Exchange-Organization-AuthAsheader set toInternaland where the IP address does not belongs to one expected to send emails to Exchange Online (such as the mail server the MX record points to).
550 5.7.51 TenantInboundAttribution; Rejecting. Recipient has a partner connector with RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set. Connector ID: ec9dab91-c912-43ea-…
When the tester surfaces this response, the tenant is mitigated: an upstream partner connector with IP/certificate restrictions is enforcing inbound attribution.
06 — Testing
A tenant is possibly vulnerable when all three of the following conditions hold:
MX does not point at *.mail.protection.outlook.com
Mail for the domain is handled by some third-party gateway (filter, appliance, and on-prem server) before reaching Exchange Online.
No partner connector with IP/certificate restrictions
Fingerprintable by opening an SMTP session against the tenant ingress and inspecting the response to RCPT TO. The tester does this automatically.
The environment uses Exchange Online or on-premises exchange in hybrid mode
Loosely fingerprintable through the presence of mail.protection.outlook.com DNS entries and the SMTP RCPT TO response.
Authorized use only
This tool is for authorized testing only. The probe is a standard SMTP conversation that stops at RCPT TO and does not deliver a message. The separate Scan + Send mode does deliver a message to a target address you specify. Confirm you have written authorization for every domain before scanning or sending.
Ready to scan?
Paste a list of domains and get a per-domain verdict.