Microsoft 365 phishing from your own domain: complex routing explained

On 6 January 2026, Microsoft Threat Intelligence described phishing that appeared to come from an organisation’s own domain. The vector was not a new Microsoft 365 flaw or a Direct Send vulnerability. It occurred in complex mail-routing environments where MX did not point directly to Exchange Online and spoof protection or third-party connectors were too permissive.

Microsoft had seen increased use since May 2025. Lures covered voicemail, shared documents, HR and password expiry; many led to Tycoon2FA adversary-in-the-middle phishing. Microsoft explicitly said the described vector did not affect tenants whose MX records pointed directly to Office 365 and benefited from native spoof detections.

Why a DMARC failure might not be enough

In a normal path, an outside server sending as the company domain causes SPF failure, no aligned DKIM and DMARC failure, after which p=reject or p=quarantine enforces a decision. When mail crosses an on-premises gateway, external filter or archive, Exchange Online must distinguish the trusted relay from the original internet source.

An over-broad connector can classify a message as internal despite anonymous authentication. Microsoft highlighted a useful combination: InternalOrgSender=True, incoming directionality, AuthAs=Anonymous, plus SPF/DMARC failures without effective enforcement. It is a valuable detection signal, although correlation is required and it is not proof of malice by itself.

Auditing the path without disrupting mail

Draw the real inbound and outbound routes. Compare MX records with connectors, transport rules and every gateway’s public addresses. After removing obsolete senders, use SPF hard fail, enable DKIM and move DMARC toward p=reject based on aggregate reports rather than leaving p=none indefinitely.

Each connector should trust a specific certificate or narrow IP range, not an entire partner network or a header claim. Send controlled samples from an unauthorised source and verify rejection rather than mere spam placement. Our SPF, DKIM and DMARC guide provides the foundation.

Detection and human resilience

Alert on the combination of same-domain sender and recipient, incoming direction, anonymous authentication and DMARC fail/none. Inspect the first untrusted hop, newly created transport rules and spikes in QR-code messages or external redirectors.

An “internal” appearance must not remove verification. Payment, bank-detail or password-reset requests need an independent channel. Use phishing-resistant MFA because SMS codes and push approval remain exposed to AiTM flows. Our Microsoft 365 security guide covers the surrounding controls.

The core lesson is that SPF, DKIM and DMARC are not three DNS records to add once. They form a system dependent on the full route. BreachRoad can audit that configuration and safely simulate spoofing.

Regression tests for every routing change

Any gateway or connector modification should trigger a test suite. Mail signed by an authorised system must pass and retain authentication results. A message using the company domain from an unauthorised IP must be rejected. Legitimate mailing-list forwarding should work without disabling protection across the domain.

Test failover too. A backup MX or temporary relay can remain the weakest route for years. Include printers, invoicing platforms and marketing automation in inventory because they often create pressure for broad SPF exceptions.

Reading headers without guessing

Start with the lowest untrusted Received line, then examine Authentication-Results at the trusted gateway. The user-visible From differs from the envelope sender used by SPF. DKIM validates the signing d= domain, while DMARC requires aligned SPF or DKIM with the visible domain.

If a filter rewrites messages or adds ARC, define which ARC sealers are trusted. ARC does not “fix” an unauthorised sender; it carries a prior authentication result through an intermediary.

FAQ

Can p=reject break legitimate mail? Yes, if senders were not inventoried. That is why migration starts with aggregate reports and a controlled enforcement percentage.

Is an External banner enough? No. It helps users, but the documented path could classify mail as internal. Enforcement must operate on authentication and routing.

---

Primary sources: Microsoft Threat Intelligence — complex routing and domain spoofing, Microsoft Learn — enhanced filtering for connectors.