What happened

The campaigns Microsoft describes are not sophisticated at the email layer. Attackers send from external IPs while setting the sender to an address at the victim organization, so the message looks like it came from a colleague or from an internal system. Where the target tenant receives mail directly and has SPF, DKIM and DMARC configured, the result is unambiguous: SPF fails because the sending IP is not authorized, there is no valid DKIM signature, and a DMARC policy of quarantine or reject takes effect.

The gap is in organizations whose MX records do not point at Microsoft 365 directly. Mail arrives via a third-party security gateway, an archiving service or a hybrid on-premises relay, and the connector that hands it to Exchange Online was not configured so that authentication results are evaluated correctly. In those tenants, Microsoft's composite authentication shows reasons like 905 (complex routing) or 451 rather than a fail, and the spoofed mail is delivered. The attackers did not need to defeat DMARC. They needed victims whose routing had quietly turned it off.

Once a message lands, the link goes to a Tycoon2FA page: an adversary-in-the-middle proxy that relays the real Microsoft login, captures the session cookie and defeats most multi-factor authentication in the process. Microsoft's indicators cover activity from June through December 2025 across many industries; the campaigns were opportunistic rather than targeted.

Why it matters if you run public infrastructure

Email authentication is a set of DNS records and a set of behaviors, and the records only matter if the behaviors honor them. Most organizations verify the records once, at setup, and then change the behaviors: add a gateway, move archiving, onboard a marketing platform, set up a hybrid relay. Each change can leave the published policy looking perfect while enforcement silently degrades. Microsoft's report is a large-scale demonstration of attackers finding those organizations at volume.

The recommendations Microsoft gives are the standard ones, and they are standard because the failures are common: SPF should end in a hard fail (-all), not the soft fail that most setup guides default to; DMARC should be at p=reject, not p=none; DKIM must actually sign outbound mail; and third-party connectors must be configured so authentication is calculated on the original sending IP, not the gateway's.

What to check this week

  1. Read your own SPF, DKIM and DMARC records as they are published today, not as documented. Look for ~all, for p=none, for SPF includes that reference vendors you no longer use, and for DMARC reports going to an address nobody reads.
  2. Trace the path of inbound mail. If MX does not point at your mailbox provider, confirm the intermediate hop is configured (in Microsoft's case, Enhanced Filtering for Connectors) so the original sender IP is evaluated.
  3. Send yourself a spoof. From an external system, send a message with a From address at your own domain and see what happens. If it arrives, your policy is decorative.
  4. Watch the records for change. A DMARC policy relaxed "temporarily" during a vendor migration and never restored is the most common way an enforcing domain becomes a spoofable one. So is an SPF include added by a departing employee's tool.
  5. Cover the domains you do not send from. Parked and campaign domains need v=spf1 -all and p=reject too; attackers do not check whether you use a domain before spoofing it.

How Attack Surface Scan covers this

Attack Surface Scan checks SPF, DKIM selectors, DMARC, MTA-STS, TLS-RPT and CAA for every verified domain, and re-checks on schedule. It flags weak configurations (soft-fail SPF, DMARC at none or with no reporting address, SPF records over the lookup limit, includes that point at domains that no longer resolve) and, more importantly, it alerts when a record changes: a policy downgraded from reject to none, a new include appearing, an MX moving. It cannot see inside your mail connectors, which is where Microsoft's specific gap lives, so the spoof test in the list above is still worth doing by hand. What it removes is the drift you never noticed in the public records themselves.

Sources