Blog · Dmarc
Why Microsoft 365 Shows an Internal Sender When the Source IP Is External
If you pull a message trace in Microsoft 365 and see a sender flagged as internal while the Source IP field points to an address outside your network, this is not a bug and it is not necessarily a breach. The answer is how Microsoft 365 defines "internal" - and it is not what most admins expect.
The short version: "internal" means the sender is in the same Microsoft 365 tenant as the recipient. It does not mean the message originated from an IP address inside your network. The Source IP shows the last hop before Exchange Online accepted the delivery. For any mail that passes through a relay, SMTP gateway, or third-party filtering service, that last hop is not your internal server - it is theirs.
What "Internal Sender" Actually Means in Microsoft 365
Exchange Online applies the internal/external label based on tenant membership, not network topology. If the recipient's email address is in your tenant, and the message arrived through Exchange Online's infrastructure, Exchange Online marks it internal before it evaluates any authentication results.
This internal flag controls how Exchange Online applies its built-in spam and malware policies. Internal mail bypasses external spam filtering rules that would normally apply to mail from outside your tenant. This is intentional - it prevents legitimate intra-tenant mail from being flagged as suspicious simply because it came through a gateway.
The authentication results in a message trace - SPF, DKIM, DMARC, CompAuth - are evaluated separately. "Internal" tells you the tenant relationship. The individual auth results tell you whether the sending infrastructure is authorized for the From: domain.
Concrete example: A marketing platform sends email on behalf of your domain through your approved SMTP gateway. The gateway terminates the incoming connection, inspects the message, and re-submits it to Exchange Online from its own IP range. Because the recipient is in your tenant, Exchange Online marks the message internal - even though the Source IP is the gateway's external address, not your network.
Why the Source IP Can Still Be External
The Source IP in a message trace is the IP of the last server that connected to Exchange Online to deliver the message. This is almost never the original sender's mail server once any relay, gateway, or archiving service is in the path.
Common scenarios that produce "internal sender, external IP":
Third-party email gateways (Mimecast, Proofpoint, Cisco IronPort)
These services terminate the incoming SMTP connection, inspect the message, and re-submit it to Exchange Online from their own IP range. The original sender's IP disappears; the Source IP becomes the gateway's.
Microsoft 365 Connectors with smart hosting
If you route outbound mail through a third-party gateway using Exchange Online connectors, return mail arrives from the gateway's IP rather than your tenant's registered send infrastructure.
Hybrid Exchange deployments
Mail between on-premises Exchange servers and Exchange Online travels over connector pairs. The public IPs of your on-premises edge servers appear as Source IPs in traces - even when the message originated inside your organization.
Cross-tenant federation (Teams, calendar sharing)
When an external organization shares calendar availability or sends Teams interop mail, Exchange Online routes it through its own infrastructure. The Source IP is a Microsoft datacenter or cross-tenant relay - not either organization's direct network.
In every case, the message is legitimately internal (same tenant on both ends) but the Source IP reflects a relay in the delivery chain, not the originating network.
How Authentication Results Display in Message Trace
When you see an internal sender with an external Source IP, the authentication results typically follow a consistent pattern:
| Check | Result | What it means |
|---|---|---|
| SPF | Fail | The submitting IP is not in the From: domain's SPF record |
| DKIM | Fail | The message was re-signed or modified by a relay that does not hold your DKIM private key |
| DMARC | Fail | The RFC5321 From: domain does not align with the authenticated sending domain |
The key distinction: CompAuth runs against Microsoft's tenant identity system. SPF, DKIM, and DMARC run against your public DNS records. These are two separate systems. CompAuth pass does not mean SPF pass, and SPF fail does not override CompAuth pass for intra-tenant delivery.
The signal that matters: CompAuth: Fail on an internal message is worth investigating. This should not happen for legitimate intra-tenant mail. It means the tenant authentication check itself failed - indicating a misconfigured connector, a compromised OAuth application, or an unauthorized relay.
When This Is a Security Concern
Most of the time, this is expected behavior. The concern is when it masks something you should know about.
Normal (not a security risk):
- Approved third-party relays submitting mail on behalf of your domain
- Calendar sharing and Teams interop with external organizations
- Hybrid mail flow between on-premises Exchange and Exchange Online
What should trigger investigation:
- Unexpected mailbox rules that auto-forward to external addresses (check in Purview audit log)
- OAuth applications with broad send permissions on your tenant (check in Exchange Online app permissions)
- Messages with CompAuth: Fail AND internal: yes - this combination should not occur in normal operations
- Source IP resolving to an unapproved relay with no corresponding connector configured
How to identify the Source IP: Run a reverse DNS lookup on the IP shown in the trace. If it resolves to a known and approved service (your SMTP gateway vendor, your archiving provider), the explanation is benign. If it resolves to something you do not recognize, audit your tenant's inbound connector configuration.
How to Investigate Using Purview and Message Trace
Step 1: Pull the full message trace
In the Exchange admin center, go to Mail flow > Message trace. Filter by the recipient address and date range. Note the authentication results, Source IP, and internal/external flag.
Step 2: Identify the Source IP
``
nslookup
Cross-reference the result against your approved relay vendors. If the IP belongs to Mimecast, Proofpoint, or your registered SMTP gateway, it is almost certainly a known relay.
Step 3: Audit mailbox rules
In the Exchange admin center, check for unexpected inbox rules on affected accounts. In the Purview compliance portal, search the audit log for "New-InboxRule" or "Set-InboxRule" events in the relevant time window.
Step 4: Review connector configuration
Check Exchange Online > Mail flow > Connectors. Look for unexpected smart host entries or modified inbound connector settings. Unauthorized connectors are a common vector for unauthorized intra-tenant relay.
Step 5: Watch for the real signal in your DMARC reports
The actionable pattern is not "internal sender with external IP" - that is expected. The pattern to alert on is unexpected authentication failures from sources inside your own tenant. DMARC aggregate reports show which IPs are failing authentication for your domain, including internal ones. An unknown internal IP failing DKIM or DMARC when you have no approved relay at that address is worth investigating.
DMARCFlow aggregates these reports across all your domains and flags anomalies - so you do not have to parse XML to notice when an unexpected source starts generating auth failures from inside your tenant.
FAQ
Does this mean my domain is being spoofed inside my own tenant?
No. "Internal" means the sender and recipient share the same tenant. SPF, DKIM, and DMARC failures on internal messages are normal when a third-party relay is in the delivery chain. CompAuth pass means Microsoft validated the sender as a legitimate tenant entity - not that the From: domain's DNS records authorized the sending IP.
Why does CompAuth pass even when SPF and DKIM fail?
CompAuth validates against Microsoft's tenant identity system, not your public DNS. A third-party relay can fail SPF and DKIM against your domain while passing CompAuth because Microsoft authenticated the relay as an authorized connector for your tenant. These are separate authentication systems running in sequence.
How can I tell if this is a legitimate third-party sender versus a threat?
Check the Source IP's reverse DNS. If it matches a known relay service configured in your Exchange Online connectors, it is expected. If you do not recognize the IP and there is no corresponding connector, treat it as suspicious and audit your tenant's send permissions and application grants.
Can I prevent external-originated mail from appearing as internal?
Not entirely. You can reduce unexpected appearances by removing unapproved smart hosts from connectors, enforcing TLS on all inbound connectors, and reviewing OAuth application permissions regularly. But as long as you use any approved relay or hybrid connector, some external Source IPs will appear for internal messages.
Bottom Line
Microsoft 365 shows an internal sender when the message is addressed to a recipient in your tenant - regardless of where the message physically entered Exchange Online's infrastructure. The Source IP reflects the last hop in the delivery chain, which for most enterprise topologies is a relay, gateway, or cross-tenant federation service, not your internal network.
This is expected behavior. The metric worth monitoring is unexpected authentication failures from sources inside your own tenant - which surfaces in your DMARC aggregate reports as a DMARC policy failure from an IP you do not recognize. DMARCFlow's aggregate report monitoring gives you a structured view of exactly which IPs are failing authentication for your domain, including internal ones, so you can investigate without manually parsing XML.