On April 14, 2026, a phishing campaign began reaching inboxes at healthcare systems, banks, law firms, and technology companies across 26 countries. By April 16, it was over. In those 48 hours, Microsoft’s threat intelligence team had logged more than 35,000 targeted users at more than 13,000 organizations. Ninety-two percent were in the United States.
Microsoft published its analysis on May 4, 2026. The campaign used adversary-in-the-middle (AiTM) infrastructure to harvest session tokens in real time, which means it bypassed multi-factor authentication entirely. But before any token was stolen, the attack had to get into an inbox. That first step, delivery, is where email authentication either holds the line or fails.
What the Campaign Actually Did
The phishing messages used what Microsoft’s researchers called “polished, enterprise-style HTML templates with structured layouts and preemptive authenticity statements.” The lure was a code-of-conduct acknowledgment request, the kind of message employees are conditioned to respond to without much scrutiny. Healthcare and life sciences organizations received 19% of the campaign volume. Financial services received 18%. Professional services and technology companies split the remainder.
The delivery mechanism exploited a pattern Microsoft had warned about four months earlier, in January 2026: complex email routing configurations where MX records do not point directly to Microsoft 365, combined with third-party connectors that carry implicit trust. In these environments, an attacker who routes through a trusted relay can inject messages that appear to originate from inside the organization, bypassing the DMARC and SPF checks that would have flagged or rejected the same message sent directly.
Once the message reached the inbox, clicking the link led to a sign-in page served by AiTM infrastructure. The AiTM proxy stood between the victim and the real Microsoft sign-in, captured credentials and the resulting session token in real time, and relayed a successful sign-in to the victim to avoid raising suspicion. With a valid session token in hand, the attacker had authenticated access to the account regardless of what MFA method was enrolled.
The Routing Misconfiguration Problem
Microsoft’s January 2026 security advisory described the attack surface precisely. Organizations that route inbound mail through a third-party security gateway before it reaches Microsoft 365 often configure an inbound connector that grants that gateway elevated trust. If that connector is misconfigured, specifically if it allows messages claiming to come from internal accepted domains without verifying SPF alignment or DKIM signature, then an attacker who can reach that connector can send email that Microsoft 365 treats as internally sourced.
The technical conditions that create this exposure are common:
- MX records point to a third-party filtering service, not directly to Exchange Online
- The inbound connector for that service is scoped to accept any message the service forwards, rather than validating authentication on each message
- DMARC policy on the organization’s own domain is
p=none, which means receiving systems are told to monitor but never block unauthenticated mail
Each condition is individually unremarkable. Organizations use third-party mail gateways for legitimate reasons. Inbound connectors require trust grants by design. p=none is the starting point for DMARC deployment. Together, they create a path from outside the organization to an inbox that reads as internal.
The mitigation Microsoft recommended in January was direct: set DMARC to p=reject with SPF configured to hard fail (-all), and audit every third-party connector to verify that it validates SPF and DKIM rather than inheriting blanket trust. Organizations whose MX records point directly to Exchange Online are not exposed to this specific attack vector. Those with third-party routing in the path are, if their authentication configuration is permissive.
Why MFA Did Not Save These Users
The AiTM technique targets the session token that is issued after successful authentication, including after the MFA challenge is completed. The victim signs in, passes the second factor, and receives a session cookie. The AiTM proxy captures that cookie before the browser stores it. The attacker presents the same cookie to the service and receives full authenticated access.
This is not a vulnerability in MFA implementations. It is a technique that operates above the authentication layer, at the session layer. It works against TOTP codes, SMS one-time passwords, push approvals, and most hardware token implementations. Phishing-resistant MFA methods tied to the origin URL, such as FIDO2 passkeys and certificate-based authentication, block AiTM because the authenticator refuses to operate on a domain it does not recognize. But phishing-resistant MFA is not the norm across the 13,000 organizations that were targeted in April.
The practical implication is that MFA reduces but does not eliminate the risk from credential phishing. DMARC at enforcement level, combined with accurate SPF, reduces the delivery risk that makes the credential phishing attempt possible in the first place. Neither control alone is sufficient. Both are necessary components of a layered defense.
The First Gate
Email authentication at p=reject is the first gate in the phishing kill chain. It does not stop every phishing campaign, but it eliminates one large and important category: messages that claim to come from your domain or a domain you control and are not actually authenticated from your infrastructure.
If the organizations targeted in the April campaign had enforced p=reject on their own domains and audited their connector configuration to ensure SPF alignment was verified at the inbound connector level, the attack path that relied on appearing to originate internally would have been blocked before delivery. The phishing email that looks like an internal HR communication is far less credible when it has to arrive from a domain the attacker actually controls, rather than spoofing the organization’s own identity.
This is the enforcement gap that the 2026 DMARC adoption reports document. Of the roughly 937,000 domains with DMARC records, fewer than half have moved to quarantine or reject. The majority are at p=none, which generates reports and does nothing to block delivery. For organizations routing mail through third-party gateways with permissive connectors, p=none offers no protection whatsoever against the attack pattern Microsoft documented.
The Configuration Audit You Should Run Now
The combination of the January 2026 routing warning and the May 2026 AiTM campaign disclosure defines a specific checklist for any organization using Microsoft 365 with third-party mail routing:
DMARC policy level. Verify that your organizational domain has a DMARC record at p=quarantine or p=reject. If your record is at p=none, schedule the enforcement migration and treat it as a security remediation, not a compliance checkbox.
SPF hard fail. Review your SPF record and confirm it ends in -all, not ~all. A softfail (~all) tells receiving servers that unauthenticated mail might still be legitimate. A hard fail (-all) tells them to reject it. The ~all setting exists for the monitoring phase of DMARC deployment. Once enforcement is in place, it should be replaced.
Inbound connector validation. If you use a third-party gateway, review the connector configuration in Exchange Admin Center. Confirm that the connector validates SPF and DKIM on inbound messages rather than implicitly trusting everything the gateway forwards. Microsoft’s documentation covers this under “Enhanced Filtering for Connectors.”
Subdomain policy. Your apex domain’s DMARC policy does not automatically apply to subdomains unless you include sp=reject in your record. The RFC 9989 update introduced the np= tag for non-existent subdomains specifically. If attackers can send from mail.yourdomain.com or hr.yourdomain.com without hitting an enforcement policy, those subdomains are attack surface.
Aggregate report monitoring. Running at p=reject without reviewing aggregate reports means you will not know when a new legitimate sending source appears and fails authentication. DMARC enforcement without ongoing report analysis is maintenance without monitoring.
The Takeaway
The April 2026 campaign targeted 13,000+ organizations in two days using techniques that have been documented for years. The routing misconfiguration vulnerability that contributed to its reach was publicly disclosed by Microsoft in January 2026 with concrete remediation steps. The gap between disclosure and remediation is where attackers operate.
Email authentication at enforcement level is not a sophisticated technical achievement. It is a configuration state. The challenge is not knowing what to configure; the challenge is completing the process across every sending source, every connector, and every subdomain, and then maintaining that configuration as infrastructure changes. That operational continuity is what separates organizations that are protected from those that are documented but exposed.
Closing the routing gap and enforcing DMARC p=reject across a complex sending environment is exactly the kind of ongoing operational work that Excello Mail manages for you. Aggregate report analysis, source discovery, connector guidance, and enforcement monitoring in one platform. Sign up free at excello.email →