On June 25, 2026, Microsoft’s threat intelligence team published details of a phishing campaign that has been running against hotels across Europe and Asia since April. The lure is ordinary: a ZIP file named photo-<numbers>.zip, supposedly a guest complaint about a bedbug infestation or a stay review, sent to reception and front-desk inboxes. What makes the campaign worth every DMARC-protected domain’s attention is not the lure. It is the delivery mechanism, which Microsoft calls “authentication laundering.”
Every message in this campaign passed SPF, DKIM, and DMARC. Not because the attacker forged anything, but because the attacker never needed to.
The Chain: Calendly to Google to Cloudflare to Your Front Desk
The emails did not originate from a spoofed domain or a lookalike. They came from a genuinely compromised Calendly account, sent through Calendly’s own SendGrid-backed notification infrastructure under the subdomain em1618.calendly.com. Because Calendly is the actual authorized sender for its own notification domain, SPF passed. Because Calendly signs its outbound mail with DKIM, that passed too. Because the From-domain alignment matched Calendly’s own DMARC policy, DMARC passed cleanly.
The message displayed as “Booking Manager (via Calendly)” – a name chosen specifically because hospitality staff are trained to expect scheduling notifications from exactly that kind of sender. The link inside routed through share.google, Google’s own URL-sharing redirect, before landing on a Cloudflare-fronted phishing domain. Each hop in that chain is, on its own, a legitimate, trusted piece of internet infrastructure.
Clicking through downloaded a ZIP containing a file named to look like a photo – IMG-<random>.png.lnk in the first wave, PHOTO-<random>.png.lnk in a second wave that began in late May. Opening it triggered a PowerShell script using a seven-phase BigInt-based decoder to retrieve a next-stage payload. The second wave added a step where the malware compiled a small .NET DLL locally using csc.exe, before ultimately downloading a full, legitimate copy of the Node.js runtime from nodejs.org and using it to execute a JavaScript implant Microsoft tracks as TonRAT. Persistence was set through both HKCU\Run and HKCU\RunOnce registry keys, so removing one path left the other intact. The implant then beaconed to command-and-control infrastructure over non-standard ports, ran headless browser automation, and queried IP geolocation services to profile the compromised machine.
Why “Authentication Laundering” Is the Right Name for This
DMARC, SPF, and DKIM answer one question: did this message come from infrastructure the domain owner has authorized to send on its behalf? They say nothing about whether the content of that message is safe, and nothing about what happens after a recipient clicks a link the authorized sender included.
Microsoft’s framing is precise: when the sending domain is itself a legitimate service, and an attacker has either compromised an account on that service or is abusing a feature of it, authentication checks confirm the sender is who it says it is while saying nothing about intent. The trust that Calendly, SendGrid, and Google have spent years earning with mailbox providers becomes the attacker’s cover. That is laundering in the literal sense – taking something illegitimate and passing it through a legitimate system until it comes out clean.
This is a meaningfully different failure mode from the domain-spoofing and hybrid-Exchange misconfigurations that have dominated DMARC-bypass headlines this year. Nobody forged a header. Nobody exploited a parsing bug. The attacker rented, phished, or otherwise obtained access to one real account on one real SaaS platform, and every authentication mechanism downstream did exactly what it was designed to do.
What This Means If You Run a DMARC-Protected Domain
If your domain enforces DMARC at p=reject, this campaign does not spoof you. Your own domain’s authentication posture is irrelevant to whether your staff receives this exact email, because the message is not pretending to be from your domain – it is a real message from Calendly’s domain, forwarded through Google’s domain, about something happening at your business.
That is precisely the point. DMARC enforcement protects your domain’s identity. It does not, and cannot, protect your organization from being targeted through someone else’s authenticated infrastructure. The two problems are related but distinct, and conflating them is how organizations end up confident about email security they do not actually have.
Three practical takeaways follow from that distinction:
Enforce DMARC on your own domain regardless. It remains necessary. It just is not sufficient here, and no configuration change to your own DNS records would have stopped this specific campaign.
Treat every authorized third-party sender as part of your attack surface. Scheduling tools, CRM notification systems, e-signature platforms, and marketing automation services that you have authorized in your SPF record or that your staff trust by habit are exactly the channels this technique is built to exploit. An account compromise on any of them arrives in your inbox with a clean authentication result.
Watch your own DMARC aggregate reports for the sending services you rely on, not just for spoofing of your own domain. If a vendor’s sending volume, IP footprint, or destination patterns for mail addressed to your organization change abruptly, that is a signal worth investigating even when SPF, DKIM, and DMARC all report a pass.
For security teams evaluating photo-themed ZIP attachments, unexpected csc.exe activity spawning small DLLs, or Node.js processes launched from AppData\Local\Nodejs with a random filename and a domain argument, Microsoft’s full indicator list is worth reviewing directly. For everyone else, the lesson is simpler: a DMARC pass tells you who sent a message. It has never told you, and was never designed to tell you, whether that message is safe to act on.
Continuous visibility into your DMARC aggregate reports is what lets you catch anomalies in the sending patterns of the third-party services you have authorized, before an authentication-laundering campaign like this one reaches your team. Sign up for free to Excello Mail and get clear, ongoing visibility into every source sending mail on your behalf.