Why Internal Domain Spoofing Still Happens After Disabling Microsoft 365 Direct Send

The question

You disabled Microsoft 365 direct send to stop internal domain spoofing. A week later, someone reports a spoofed email from your own domain sitting in an inbox. What went wrong?

Direct send is a Microsoft Exchange transport rule. It controls how mail moves between internal mailboxes in your tenant. It has nothing to do with whether an external sender can claim your domain in the From header. Those are two completely separate problems, and disabling one does not fix the other.

This article explains what direct send actually does, what it misses, and how to catch internal spoofing using DMARC aggregate reports.

What direct send actually controls

In Microsoft 365 and Exchange Online, direct send is a connector or transport rule that lets mail flow directly between internal users without going through the cloud's outbound filtering. It is designed for scenarios where you want internal mail to bypass certain processing steps.

What direct send does:

• Routes mail between mailboxes in the same tenant
• Bypasses outbound spam filtering for internal-to-internal mail
• Keeps internal mail internal

What direct send does not do:

• Validate the From header on incoming mail from external sources
• Check SPF, DKIM, or DMARC alignment on any mail
• Stop an external attacker from sending mail that claims to be from your domain

Direct send is a transport mechanism. It says "this mail should go here" but it never asks "is this sender actually allowed to use this From address?"

What DMARC p=reject actually controls

DMARC works on the gap between two different sender identities in an email:

• **RFC5321.MailFrom** - the bounce address, used for SPF validation
• **RFC5322.From** - the From header address shown to recipients

When you set DMARC p=reject, receiving mail servers check whether the domain in the From header aligns with the domain that passed SPF or DKIM. If they do not align, the message is rejected.

p=reject does not check:

• Whether your internal users are sending authenticated mail
• Whether your internal network has been compromised
• Whether a forwarded message looks like internal spoofing

p=reject only validates messages coming from external sources against your published policy. It operates at the boundary of your domain's published DNS records, not inside your tenant.

Three scenarios where internal spoofing persists after disabling direct send

Scenario 1: Forwarded mail showing the original sender as your domain

When a message from an external sender is forwarded by a user inside your organization, the forwarded copy arrives with the original From address intact. To the receiving mail server, this looks like someone at your domain sent the message. If the forwarding server does not add its own DKIM signature or SPF alignment, the forwarded message may fail DMARC.

This is not spoofing in the malicious sense. It is a forwarding artifact. But it can trigger DMARC failures in your aggregate reports and look like internal spoofing to an untrained reviewer.

Scenario 2: Cross-tenant relay or shared SMTP infrastructure

Organizations using shared SMTP relays, multi-tenant Exchange deployments, or cross-tenant mail flow may have mail that appears to come from your domain but originates from infrastructure that does not align with your DMARC policy. If a partner or vendor relay sends on behalf of your domain without proper DKIM signing, those messages fail DMARC.

Disabling direct send does not affect mail that originates from a different tenant or relay and then passes through yours.

Scenario 3: Compromised internal account sending authenticated mail

If an internal account is compromised and an attacker uses valid credentials to send mail through Microsoft 365's outbound servers, the message passes SPF and DKIM because it originated from authenticated infrastructure. Your DMARC p=reject policy at the boundary will never see this traffic, because the mail never leaves your tenant. The attacker is already inside the system that vouches for the sending identity.

This is the scenario direct send cannot address at all, and it is exactly the kind of anomaly that DMARC aggregate report monitoring is designed to surface.

How to detect internal spoofing in your DMARC reports

DMARC aggregate reports (RUA) arrive daily from participating mail receivers. They contain a summary of all messages that attempted to deliver mail on behalf of your domain, regardless of whether they passed or failed authentication.

DMARCFlow processes these reports and flags anomalies that manual review misses. Specifically for internal spoofing scenarios, it surfaces:

• Source IPs sending mail for your domain that are not in your known infrastructure list
• Sudden changes in authentication pass/fail ratios that may indicate a compromised account or new forwarding rule
• Forwarding patterns detected through DKIM failure spikes with simultaneous SPF passes

Without this monitoring in place, you are relying on users to report spoofed emails they receive. By the time a user reports it, the spoofing campaign may have been running for days.

Look for these signals in your DMARC reports manually if you do not have automated monitoring:

IP addresses you do not recognize

Your aggregate reports show source IP addresses that sent mail claiming your domain. If you see IPs that are not your Microsoft 365 endpoints and not your known relay infrastructure, those are worth investigating immediately.

High volume of SPF-aligned failures with DKIM failures

A spike in messages that fail DKIM but pass SPF often indicates forwarding. The forwarding service uses its own SPF record but cannot DKIM-sign for your domain. This is usually benign but worth knowing.

Authenticated internal senders showing unexpected failure rates

If you run internal mail servers or applications that send authenticated mail, monitor their DKIM and SPF alignment. Unexpected DMARC failures from internal sources can indicate configuration drift.

What to do right now

1. Pull your latest DMARC aggregate report and look at the source IPs in the failure data. Check whether each one matches your known infrastructure.
2. If you see forwarding patterns (DKIM failures with SPF passes), identify which mail streams are being forwarded and whether they need DKIM signing.
3. If you have not set up RUA reports yet, do that first. You cannot catch what you cannot see.
4. Consider moving to p=reject once you have reviewed your report data and resolved any legitimate mail streams that currently fail.

FAQ

Does disabling direct send help with anything?

Yes. It stops mail from being routed directly between internal users without going through your normal mail hygiene pipeline. In some configurations, this can help with certain internal scanning workflows. But it does not address external spoofing or internal account compromise.

Can p=reject stop internal spoofing?

p=reject stops external sources from sending mail that pretends to be from your domain. It does not stop a compromised internal account from sending authenticated mail. For internal account compromise, you need log monitoring, anomaly detection, and user education.

Why am I seeing DMARC failures for my own domain from Microsoft 365 endpoints?

This usually happens when Microsoft 365 apps or services send mail on behalf of your domain without proper DKIM signing. Check your Microsoft 365 DKIM configuration, particularly for subdomains used by Teams, SharePoint, or other integrated services.

What is the difference between direct send and a receive connector?

Direct send in Microsoft 365 is a transport rule configuration. Receive connectors in on-premises Exchange control which external servers can relay mail through your Exchange server. Both are relay mechanisms, not authentication mechanisms. Neither validates the From header.

Bottom line

Direct send and DMARC p=reject solve different problems. Direct send controls internal mail routing. DMARC p=reject validates that external mail claiming your domain has the right authentication. Disabling one does not affect the other.

If you want visibility into what is actually happening with your domain's mail, start receiving DMARC aggregate reports and review them regularly. That is the only way to know whether your domain is being spoofed, forwarded, or otherwise misused, regardless of what transport rules you have configured.