Microsoft Warns Misconfigured Email Routing Can Enable Internal Domain Phishing

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
910
4,295
2,168
Germany
Threat actors engaging in phishing attacks are exploiting routing scenarios and misconfigured spoof protections to impersonate organizations' domains and distribute emails that appear as if they have been sent internally.

"Threat actors have leveraged this vector to deliver a wide variety of phishing messages related to various phishing-as-a-service (PhaaS) platforms such as Tycoon 2FA," the Microsoft Threat Intelligence team said in a Tuesday report. "These include messages with lures themed around voicemails, shared documents, communications from human resources (HR) departments, password resets or expirations, and others, leading to credential phishing."
Full Story:
 
Full Story:
This is a useful Microsoft warning because it highlights a “looks internal” phishing scenario that can bypass user skepticism (the email appears to come from your own domain), but it’s mainly enabled by mail-flow/routing design plus weak or permissive anti-spoof enforcement rather than a brand-new “email hack.”

What’s actually being abused (in practical terms)
  • Organizations with complex mail routing (for example: MX not pointing directly to Microsoft 365, mail passing through on‑prem Exchange or a third-party gateway/archiver first) can end up with a gap where spoof checks aren’t strictly enforced.
  • Attackers then send messages that appear to originate from inside the tenant’s domain (sometimes even with the same address in both the “From” and “To” fields), making the phish look like an internal message.
  • Microsoft ties much of the activity to phishing-as-a-service kits like Tycoon2FA, including AiTM-style credential theft intended to bypass MFA by stealing session tokens.
Microsoft also explicitly notes this has been seeing increased use since May 2025 and that it is not a “Direct Send vulnerability” as some public reporting has implied. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))

Who is and isn’t likely impacted
  • More likely impacted: tenants where MX does NOT point to Office 365 and where spoof protections/DMARC/SPF enforcement is permissive or inconsistently applied across hops (third-party connectors/gateways, on‑prem relays, etc.). ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))
  • Less likely impacted (for this specific vector): tenants with MX pointing directly to Office 365, where Microsoft says native spoofing detections protect customers from this routing-based tactic. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))

Key defensive actions (admin-focused)
  • Enforce DMARC (ideally p=reject once validated) and move SPF to a hard fail posture where feasible (e.g., -all, not ~all), plus ensure DKIM is enabled for your sending domains. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))
  • Review all third-party connectors and mail-flow paths (secure email gateways, journaling/archiving, ticketing systems, scanners/MFPs, marketing platforms) to ensure they are explicitly authorized and not creating an “unvalidated” relay path. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))
  • Harden anti-phishing/anti-spoof policy behavior (quarantine/reject on DMARC fail rather than “none/monitor”), and confirm you’re not allowing internal-domain spoofing due to an overly permissive policy or exception list.
  • Detection/triage hint (SOC/helpdesk): messages can “look internal” while still being externally originated; Microsoft notes header combinations that can reveal this (for example, internal-org-sender indicators combined with incoming directionality / anonymous auth). ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))

User-focused safety notes
  • Treat “internal” emails that pressure urgency (password reset, invoice/payment, HR changes, shared document, voicemail) with the same skepticism as external mail—especially if it contains a QR code, a shortened/redirect link, or asks you to “re-authenticate.”
  • If your org uses Microsoft 365/Defender, report suspicious messages using the built-in reporting mechanism so detections can improve and the security team can trace the actual source path.

Bottom line
This is best viewed as a configuration/routing hardening issue: if your environment has complex mail flow, make sure spoof protections are strictly enforced end-to-end (DMARC/SPF/DKIM + connector hygiene), because “looks internal” phishing is significantly more convincing and can accelerate credential theft and BEC-style fraud. ([microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/?utm_source=openai))

Sources
 
3rd, 4th, 5th, 6th, and so on parties are the best points of attack.

Even the most secure localhost will not save any of us.

"How did I lose my life savings? I had AV installed on all my computers and mobile devices!"

bunty-buntu.gif
 
Recommendation / Remediation

To neutralize this vector, you must force Exchange Online to look past your gateway's IP address to validate the true sender.

Enable "Enhanced Filtering for Connectors" (Critical)

This feature (formerly known as "Skip Listing") instructs M365 to ignore the IP address of your trusted gateway when calculating SPF/DMARC and instead evaluate the IP immediately preceding it.

Action
Navigate to Microsoft 365 Defender > Email & collaboration > Policies & rules > Threat policies > Enhanced filtering.

Config
Select your inbound connector (for your gateway) and enable skip listing for the gateway's IP range.

Enforce Strict DMARC Policies

Ensure your organization's DMARC record is set to p=reject or p=quarantine.

Note
Without Enhanced Filtering (step 1), enforcing DMARC on a complex route can cause false positives for legitimate mail. Enable Enhanced Filtering first.

Review Connector Security

Verify
that your Inbound Connectors are strictly scoped. They should only accept mail from the specific IP ranges of your third-party gateway or on-prem servers, often using certificate validation (TlsSenderCertificateName).

Disable "Direct Send" (If Unused)

If your tenant does not require applications to send mail directly using the "Direct Send" method, disable it to prevent attackers from potentially using your infrastructure to spoof outbound mail.

References

Threat Actor

Tycoon 2FA PhaaS Kit

Attack Vector
Complex Routing / Internal Domain Phishing

Source
Microsoft Threat Intelligence