A Voicemail That Never Rang: How Attackers Chained Three ESPs to Launder Email Authentication

SPF passed. DKIM passed. The email arrived from a real person at a real school. And the voicemail it referenced never existed.

On May 5, 2026, an employee at a SaaS company received what looked like a routine voicemail notification. The sender appeared to be a named staff member at a legitimate K-12 educational institution. The subject line read "Fwd: You have an unheard voice msg awaiting your review." A blue "Play Voicemail" button sat in the middle of a clean, well-formatted HTML template. Nothing about the visual presentation screamed phishing.

But the infrastructure underneath told a different story. The attacker had stitched together three separate email service providers (SendGrid for delivery, Mailchimp for click tracking, and ActiveCampaign Pages for the landing page) to build an authentication chain that would pass initial checks while hiding the actual credential harvesting payload behind two layers of redirects.

Three Services, Zero Compromises, One Laundered Chain

This attack did not require compromising a single account. Every service in the chain was used as designed. The Microsoft Digital Defense Report 2024 documented a sharp rise in adversary use of legitimate cloud services for email delivery, and this case is a textbook example. That is precisely what makes it effective.

Hop 1: SendGrid handles delivery. The email was sent through SendGrid's infrastructure (134[.]128[.]127[.]204 via vsvhtfcc[.]outbound-mail[.]sendgrid[.]net). SendGrid signed the message with its own DKIM key and the sending IP was authorized under SendGrid's SPF record. Both checks passed cleanly at the recipient's mail gateway.

Hop 2: Mailchimp obscures the destination. The "Play Voicemail" button linked to hxxps://click[.]mailchimp[.]com/track/click/30010842/ecspgh[.]ac-page[.]com?p=..., a Mailchimp click-tracking URL. At delivery time, a link scanner evaluating the email sees a click.mailchimp.com domain with a strong reputation. The actual destination is encoded in a base64 parameter and only resolved at click time.

Hop 3: ActiveCampaign Pages hosts the payload. The Mailchimp tracker redirected to hxxps://ecspgh[.]ac-page[.]com/newrec5526available, a page hosted on ActiveCampaign's landing page infrastructure. This is where the credential harvester lived. By the time a user clicks, they have passed through two trusted intermediaries, and the URL bar shows a subdomain of ac-page.com, a domain most users would not recognize as suspicious.

Each hop borrows the reputation of a legitimate marketing platform. None of them are compromised. The attacker simply created accounts (or abused existing ones) on services that millions of businesses use daily.

The DMARC Blind Spot That Made It Possible

Here is where the authentication story gets interesting. The email's header From claimed to be lbayle@ the educational organization's domain. But because the message actually traveled through SendGrid's infrastructure, DMARC alignment failed. The DKIM signature was valid for sendgrid.net, not for the school's domain. SPF passed for the SendGrid bounce address, not for the From header.

Under a strict DMARC policy (p=reject or p=quarantine), this email would have been blocked or flagged. But the school's domain published p=none, which is monitoring-only. As NIST defines it, phishing exploits trust relationships, and a p=none DMARC record is an open invitation for exactly that. The policy tells receiving servers: "note the failure, but deliver the message anyway."

According to the Verizon 2024 Data Breach Investigations Report, phishing remains the top initial access vector in breaches. What makes ESP-chain attacks particularly dangerous is that they exploit the gap between authentication (did the message come from an authorized server?) and authorization (did the domain owner actually send this?). SPF and DKIM answered the first question correctly. DMARC was supposed to answer the second, but p=none turned it into a suggestion.

IRONSCALES telemetry flagged this incident with 81% confidence as phishing based on community threat intelligence, link analysis, and sender behavior signals. The combination of a first-time sender, a voicemail lure from a non-telephony domain, and a multi-hop redirect chain triggered automated resolution before the recipient could click.

Anatomy of the Lure

The social engineering was competent but not exceptional. The email used a "Voicemail Forwarding Notice" header, referenced a caller number (+1 562-687-2506), and included a reassuring note: "The original message is still in your voicemail account." A 1x1 SendGrid tracking pixel (u106401866[.]ct[.]sendgrid[.]net) monitored whether the recipient opened the email.

The Fwd: prefix in the subject line was a deliberate social engineering choice, not evidence of an actual forwarded message. There was no forwarding chain in the headers. The prefix exists to create a false sense that the message had already been handled by an internal system before reaching the recipient.

See Your Risk: Calculate how many threats your SEG is missing

The lack of personalization is notable. No recipient name, no account identifiers, no organization-specific branding. This is a spray-and-pray template designed to work across thousands of recipients. The attacker traded conversion rate for scale, relying on volume and the credential harvesting landing page to do the heavy lifting.

IOCs From the Voicemail Lure Chain

### MITRE ATT&CK Mapping

• T1566.002 (Phishing: Spearphishing Link): Voicemail lure with embedded link to credential harvester
• T1583.006 (Acquire Infrastructure: Web Services): Abuse of SendGrid, Mailchimp, and ActiveCampaign as attack infrastructure
• T1656 (Impersonation): Spoofed identity of a real employee at a legitimate educational institution
• T1204.001 (User Execution: Malicious Link): Relies on recipient clicking the "Play Voicemail" button

What This Means for Your Stack

Traditional secure email gateways that rely on SPF/DKIM pass results will not catch this. The authentication checks did exactly what they were designed to do. They confirmed SendGrid sent the message. They did not confirm that the claimed sender authorized it.

If your organization depends on DMARC for inbound protection, you are only as safe as the weakest domain your users receive mail from. A school, a vendor, a partner with p=none becomes an open door for impersonation.

Actionable steps for this pattern:

1. Monitor DMARC alignment failures separately from SPF/DKIM results. A message that passes SPF and DKIM but fails DMARC alignment is a stronger phishing signal than one that fails all three.
2. Treat multi-hop redirects through marketing platforms as elevated risk. If a link passes through click.mailchimp.com or similar tracking domains before reaching a final destination, the delivery-time scan may not reflect what the user actually lands on.
3. Flag first-time senders with voicemail or fax lure templates. This pattern (transactional notification from an unknown sender) has a high base rate of malicious intent, according to the FBI IC3 2024 Annual Report.
4. Push your own domains to p=reject. Every domain at p=none is a domain an attacker can borrow. The CISA phishing guidance recommends enforcing DMARC as a foundational control.
5. Evaluate whether your email security stack analyzes links at click time, not just at delivery. The Mailchimp redirect in this case resolved to a completely different domain than what appeared in the email body.