Microsoft's Tycoon2FA Findings: How a Routing Misconfiguration Let Attackers Spoof Real Domains
On January 6, 2026, Microsoft's security team published findings on a phishing technique that doesn't rely on a new exploit or a leaked credential — it relies on something far more common: a mail-routing setting most admins configured once, years ago, and never revisited. The result is email that fails SPF and DKIM outright, and still lands in the inbox looking like it came from inside the building.
What Microsoft found
The campaigns Microsoft tracked use Tycoon2FA, an adversary-in-the-middle (AiTM) phishing-as-a-service kit that proxies a real login page in real time to capture both credentials and the post-MFA session token — the same class of attack that makes standard push/OTP-based MFA far weaker than it used to be against a well-resourced phishing kit. Microsoft Defender for Office 365 alone blocked more than 13 million malicious emails linked to Tycoon2FA in October 2025, "including many attacks spoofing organizations' domains."
The domain-spoofing part is the interesting piece. It doesn't come from a DNS takeover or a stolen signing key — it comes from a specific, extremely common setup: an organization whose MX record doesn't point directly at Microsoft 365, because mail is routed through an on-premises Exchange environment or a third-party service first. Microsoft's own detection actually flags this at the message level, with a reason code most admins have never had to think about:
reason=905, which indicates that the tenant has set up complex routing where the mail exchanger record (MX record) points to either an on-premises Exchange environment or a third-party service.
In that routing shape, a message can carry authentication results that look like a clean rejection — and still get delivered as if it were internal mail. Microsoft's writeup shows the actual header evidence from one of these messages:
spf=fail (sender IP is 51.89.59.188) smtp.mailfrom=contoso.com;
dkim=none (message not signed) header.d=none;
dmarc=fail action=quarantineSPF failed. DKIM was absent entirely. DMARC evaluated to a fail with an action=quarantine instruction attached — every signal a receiving system needs to stop the message is right there in the header. What breaks it is the routing complexity itself: because mail transits an on-prem or third-party hop before reaching Microsoft 365, that intermediate hop can carry its own authentication context forward in a way that lets the message get tagged as coming from inside the tenant. Microsoft's report also calls out the internal-mail marker directly — a spoofed message showing up with X-MS-Exchange-Organization-AuthAs: Anonymous, the header that's supposed to be the tell that a message actually came from outside, despite everything else about it looking internal.
Microsoft describes the campaigns as opportunistic rather than targeted — sent broadly "to a wide variety of organizations across several industries and verticals" — with at least one observed campaign using this exact vector to run financial scams, the classic business-email-compromise playbook: a spoofed internal-looking message asking someone in finance to move money or change a payment detail.
Why "we have DMARC" wasn't enough here
None of this required an organization to have no DMARC record at all. It required one set up permissively enough — or a mail-routing topology complex enough — that a technically-failing message still had a path to the inbox. That's the recurring theme across almost every DMARC-adjacent incident: the record exists, the monitoring exists, but the policy doing the actual blocking was never tightened past a safe-sounding default.
Microsoft's own remediation guidance is specific about exactly which defaults to fix:
- Move from a monitor-only or quarantine DMARC policy to strict
p=reject, notp=noneand notp=quarantineas a permanent resting state. - Move SPF from a soft fail (
~all) to a hard fail (-all) — a soft fail is, by design, a suggestion a receiving server can ignore. - Properly configure mail-flow connectors for any third-party or on-prem hop in front of Microsoft 365, instead of leaving the routing "complex" in the way reason=905 flags.
- Layer in Safe Links URL scanning and Zero-hour auto purge (ZAP) as a second line of defense for whatever gets through.
- Move toward phishing-resistant authentication — FIDO2 security keys or passkeys — since AiTM kits like Tycoon2FA exist specifically to defeat standard push/OTP MFA, not to guess passwords.
The part that's easy to miss
Every one of those fixes is something a security team can only confidently make with visibility into what would break first. Jumping straight to p=reject and SPF -all without knowing which of your own legitimate senders — a marketing platform, a helpdesk tool, that one third-party service routing mail through an on-prem hop — would also start failing is exactly how "we tightened DMARC" becomes "we broke our own outbound mail." That's the actual gap DMARC aggregate (RUA) reporting exists to close: it shows you every sending source claiming your domain, whether it's passing or failing, and whether your current policy is strict enough to matter — before you flip the switch, not after.
If you're running ESPM, this is precisely what the per-domain grade and alignment breakdown on your Dashboard are built to surface: whether your DMARC policy has actually reached p=reject, whether SPF is on a hard or soft fail, and which sending sources in your aggregate reports would be affected by tightening either one — so the move to strict enforcement is a planned change, not a guess.