Huntress published research on July 7, 2026 detailing a phishing campaign that ran undisturbed for roughly eight months by exploiting something no authentication protocol was ever built to catch: a real feature, working exactly as designed, triggered by an attacker instead of a legitimate business. The emails came from [email protected]. They really did come from Meta’s own servers. They passed SPF, DKIM, and DMARC because there was nothing to fail. The deception started only after the recipient clicked.
A Feature, Not a Forgery
Meta Business Manager lets one business send a “partner request” inviting another account to collaborate on ad accounts or Pages, a routine workflow used constantly by agencies and marketing teams. Huntress found that threat actors, active since at least November 2025, had learned to set the display name and business name on their own attacker-controlled account to read like an official Meta initiative, something resembling a Meta Agency Partner Program invitation or a verification offer. Meta’s platform then did exactly what it was built to do: it generated a real notification email from its own infrastructure and delivered it, addressed as if it came from Meta itself, because as far as the mail system was concerned, it did.
From Google Sites to a Fake Chatbot
The campaign evolved as it went. An earlier version, active in May 2026, routed clicks to a fake Meta Agency Partner Program page hosted on Google Sites. By June, the operators had added a fraudulent Facebook Messenger chatbot to the chain, presenting victims with options like “Get Verification Badge” or “Enable Monetization” before redirecting them to Netlify-hosted phishing pages. The attacker-registered domains behind these pages were built to blend in with Meta’s own naming conventions: agency-ad-hub.com, agency-partner-register.com, marketing-partner-join.com. None of that infrastructure needed to touch the email itself. The email had already done its job by being real.
What the Kit Actually Took
The phishing pages harvested Meta account credentials, MFA codes, business and personal phone numbers, email addresses, and a photograph of the victim’s government ID or passport, enough to take over an account and defeat identity re-verification at the same time. Huntress traced the exfiltration to a Telegram bot, found Vietnamese-language strings in the client-side code, and identified the bot’s operator handle, pointing to likely Vietnamese-linked infrastructure behind a campaign that reached businesses across multiple regions before Meta shipped safeguards in June 2026 that researchers say have since stopped it.
Why DMARC Had Nothing to Flag
DMARC exists to confirm that the domain in a message’s From header is authorized to send on its own behalf. In this campaign, business.facebook.com sent the mail, signed it, and aligned it, all correctly, all genuinely. There was no lookalike domain, no spoofed header, no authentication gap of any kind for DMARC to catch, because the platform sending the notification and the domain the notification claimed to represent were, for once, exactly the same thing. The attacker never needed to impersonate Meta. They only needed to get Meta to send a message on their behalf, using an account-naming field that DMARC has no visibility into and no authority over.
What Businesses Should Do Now
Verify any “partner,” “verification,” or “agency” notification inside Meta Business Suite directly, never through the email’s own link. Navigate to the platform yourself and check pending partner requests from there.
Audit who can send your business partner requests, and review that access on a schedule. Business Manager’s partner and access settings control this directly; unreviewed standing permissions are exactly what this campaign relied on.
Never submit a government ID, passport photo, or MFA code in response to a link inside an email, regardless of how legitimate the sending address looks. Legitimate identity verification happens inside an authenticated session you started yourself.
Keep your own domain’s DMARC enforcement in place regardless. It will not stop your provider’s own notification system from being turned against you, but it still closes the far more common path where an attacker forges your name directly, so your team’s attention stays free for blind spots like this one.
The Takeaway
This campaign never needed to beat DMARC, because it never had to fight it. Meta’s own infrastructure sent a message Meta’s own infrastructure was fully entitled to send, on behalf of an account Meta’s own infrastructure had verified was real. The only thing fake was the intent behind it, a field DMARC was never designed to read. Authentication tells you who sent a message. It has never claimed to tell you why.
Excello Mail keeps every domain you manage fully authenticated and enforced, shutting the door on direct spoofing so your team’s attention goes to the blind spots that live one layer deeper, in the platform features and business logic that DMARC was never built to police. Sign up for free to Excello Mail to see your domain’s real authentication posture today.