Why Microsoft 365 Shows an Internal Sender Address from an External IP

The Scenario That Confuses Everyone

An M365 administrator runs a message trace and sees something that looks wrong: the sender field shows someone at your own domain - hr@yourcompany.com - but the source IP is something like 203.0.113.42, which is clearly external and has no business sending mail as your internal user.

The first instinct is to call it spoofing. Sometimes it is. But not always, and the distinction matters.

What you are seeing is a collision between two separate systems inside Microsoft 365: the application layer (which decides what to display in the sender field) and the MTA layer (which handles authentication and routing). They do not always agree on what counts as "internal" and "external," and that gap is by design.

Why M365 Shows Internal Sender Addresses from External IPs

The Envelope Sender vs. the From Address

Email has two different sender identities that travel alongside each message, and they are often confused.

The envelope sender (also called MAIL FROM or return-path) is what MTAs use to deliver the message and what SPF authenticates. It is invisible to normal email readers.

The From header is what you see in your email client. It is what M365 displays in message trace. It can say anything - there is no built-in verification on the From header itself, which is why DMARC exists.

When you look at message trace and see an internal sender address, you are seeing the From header, not the envelope sender.

How Mail Flows Through Microsoft 365

When an external email arrives at M365, the receiving server (the edge transport server) sees the connecting IP, evaluates SPF against it, checks DKIM, and evaluates DMARC. The result of this chain is what appears in the authentication results field.

The From header is read from the message content itself, which was set by the sending MTA - not by M365. M365 passes the From header through unchanged unless a transport rule modifies it.

So the external IP sends a message where the From header says hr@yourcompany.com. M365 receives it, checks whether 203.0.113.42 is authorized to send for yourcompany.com (SPF), and then displays the message with its original From header.

The Source IP That Message Trace Actually Shows

When you look at a message trace, the source IP field shows the IP of the server that connected to M365's edge. This is the MTA-to-MTA delivery IP. It has no direct relationship to the From header field.

This is why a third-party email gateway, a SaaS application, or a cross-tenant relay can send mail that appears to come from an internal address - the From header was set by the original sender, but the delivery was done by the relay's infrastructure.

What SPF, DKIM, and DMARC Actually Check

SPF: The Envelope-From, Not the From Header

SPF validates the envelope sender (MAIL FROM domain) against the connecting IP. If the connecting IP is not listed in the SPF record for the envelope sender domain, SPF fails.

SPF does not look at the From header. An email with From: hr@yourcompany.com can have an envelope sender of noreply@salesforce.com, and SPF will validate against salesforce.com, not yourcompany.com.

This means an internal-looking From header with an external source IP can pass SPF if the external IP is legitimately authorized to send for whatever envelope sender domain was used.

DKIM: The Signed Domain, Not the Display Name

DKIM attaches a cryptographic signature to the message, tied to the signing domain (the d= domain in the DKIM-Signature header). The From header domain does not have to match the DKIM signing domain.

A third-party marketing platform can send mail on behalf of your domain, sign it with their own domain's DKIM key, and the message will pass DKIM even though the From header says yourdomain.com.

DMARC: Aligned Identifier, Not the Sender Field

DMARC requires at least one of SPF or DKIM to pass and to have an aligned identifier. Alignment means the domain used for SPF (envelope MAIL FROM) or DKIM (d= domain) matches the From header domain, or a parent domain if pct/sp tags are in play.

A message with From: hr@yourcompany.com and an external source IP passes DMARC if either:

• SPF passes with aligned envelope domain, or
• DKIM passes with aligned signing domain

The From header content is not validated by DMARC. This is why DMARC alone does not prevent the display-name spoofing scenario where an attacker puts your CEO's name in the From header but sends from an external domain.

When an Internal Sender from an External IP Is Legitimate

Third-Party Email Gateways and SEG Relays

If your organization uses a third-party SEG (secure email gateway) like Proofpoint, Mimecast, or Abnormal Security, inbound mail is received by the SEG first. The SEG then relays it to M365. From M365's perspective, the connecting IP is the SEG's, not the original sender's. If the SEG preserves the original From header during relay, M365 message trace will show your internal domain in the sender field while displaying the SEG's IP as the source.

This is normal and expected. The question is whether the SEG is performing authentication checks on the original message before relaying.

Cross-Tenant Forwarding

When someone at a partner company forwards an email from their M365 tenant to someone at yours, the flow goes: partner M365 → your M365. The source IP at your M365 edge is Microsoft's, not the partner's. If the original From header used your domain (say, because the partner's admin set a custom From address), message trace will show yourdomain.com as the sender with a Microsoft IP as the source.

Journaling Systems

M365 journaling rules can create apparent internal senders from external IPs when the journaling system processes and re-injects messages. The envelope structure changes while the message content - including the From header - is preserved.

When It Is a Spoofing Problem DMARC Should Have Caught

The more serious case: an attacker actually sends mail from an external IP, uses your domain in the From header, and somehow evades DMARC enforcement. This can happen when:

• The attacker sends from a domain that has a weak or misconfigured SPF record and uses your domain as the MAIL FROM (envelope sender) - SPF passes because their server IP is authorized for their own domain, not yours. DMARC fails because the envelope domain does not match the From domain.
• A compromised internal account sends from an external IP (for example, via a cloud mail app the user installed) with the From header showing their internal address. SPF passes if the envelope domain is your domain and the IP is in your SPF record; DMARC alignment depends on what the attacker used for the envelope.
• A misconfigured third-party relay strips authentication results but preserves the From header.

The critical diagnostic question is not whether the From header looks internal - it is whether the authentication results in the message headers show SPF, DKIM, and DMARC as pass or fail.

How to Investigate Using M365 Tools

Using Message Trace to Find the Real Source

In the M365 admin center, go to Mail Flow → Message Trace. Search by sender address or domain. For each message, open the detail view and check:

• Source IP - the IP that connected to M365's edge transport
• Authentication-Results - the SPF, DKIM, and DMARC result strings
• Direction - Inbound means it came from outside your tenant

If you see an internal-looking sender with a source IP that is not your known sending infrastructure, that is worth investigating.

Checking Authentication Results in the Headers

In the message detail view, expand the message headers. Look for:

Authentication-Results: spf=fail (sender SPF is not pass) ...
Authentication-Results: dkim=fail (body hash did not verify) ...
Authentication-Results: dmarc=fail (pct=100) ...

Or passing results:

Authentication-Results: spf=pass ... dkim=pass ... dmarc=pass

The authentication results tell you whether M365's edge actually validated the message. A From header that looks internal is meaningless if authentication passed or failed independently.

What to Do If SPF or DKIM Failed

If authentication results show SPF or DKIM failures for a message that appears to come from an internal sender, the message may have been sent from an unauthorized source. Check whether the source IP belongs to a legitimate third-party service you authorized. If not, the message may be spoofing your domain despite the From header appearing internal.

If DMARC failed and the source IP is unknown, quarantine or reject the message. If DMARC passed but you still suspect spoofing, the attacker may have passed alignment - which points to a gap in your authorized sending infrastructure.

How DMARCFlow Helps You Catch This Faster

DMARCFlow's aggregate reports surface the source IP for every DMARC evaluation result across all your monitored domains. Rather than checking message trace one email at a time, you can see which external IPs are sending as your domain, how often, and whether they are passing or failing DMARC alignment.

When a third-party SEG or SaaS tool starts sending from a new IP range, DMARCFlow flags it before it becomes a deliverability problem. When an attacker sends from an unauthorized IP, the DMARC failure shows up in the report with the source IP visible, even if the From header looked indistinguishable from a legitimate internal message.

If you receive DMARC reports but find them difficult to read or act on, DMARCFlow parses them into actionable summaries. The summary shows source IPs, pass/fail rates, and domain-level alignment failures - the exact data you need to distinguish a misconfigured relay from an active spoofing campaign.

FAQ

Does DMARC fail if the sender address looks internal but the IP is external?

Not automatically. DMARC evaluates the envelope sender and the aligned DKIM domain, not the From header display name. If either SPF or DKIM passes with aligned domain identifiers, DMARC passes - regardless of what the From header shows.

Can SPF pass for an email with an internal sender address from an external IP?

Yes. If the envelope sender domain matches the source IP's authorized SPF record, SPF passes. For example, if a third-party platform sends with its own envelope domain and has its own IP in its SPF record, SPF passes - even if the From header displays your domain.

How do I block external IPs from sending as my internal users?

The short answer is that you cannot do this with authentication alone. DMARC checks alignment, not the From header content. A domain-based DMARC policy with p=reject helps, but the real constraint is ensuring your SPF record only includes IPs you control and that third-party senders use their own envelope domains or have proper DKIM signing.

What does it mean if message trace shows internal sender with external IP and authentication passed?

In most cases, this means a legitimate third-party relay or SEG processed the message and re-delivered it to M365. Check whether the source IP belongs to a service you authorized. If it does not, treat it as an unauthorized relay and investigate.

Why do M365 mail flow reports sometimes show a different sender name than the actual envelope sender?

M365 prioritizes the From header for display in mail flow reports because that is what users see in their email clients. The envelope sender is only visible in message headers or message trace detail. They are independent fields, which is why they can differ.