Real Case: How They Tried to Slip Us a 'Stripe Compliance' Email (and What to Learn from It)

In October 2025, we received an email with the subject “Review Required: Compliance Update — Support Case #3989843”.

It appeared to come from Stripe, with a button to access the dashboard. However, the URL did not correspond to Stripe’s legitimate dashboard URL.

What’s interesting: the message was displayed “via eevidence.com” in Gmail, which to a distracted user increases trust. How is this possible?

Quick Attack Summary (for non-technical users)

• The sender, who was not Stripe, sent the email via Mailchimp (headers X-Mailer: Mailchimp, mail73.sea31.mcsv.net).
• It passed SPF, DKIM and DMARC… with the attacker’s domain.
• The email entered a distribution list managed by Google (gpdr@eevidence.com), without Google identifying the phishing.
• When forwarding it to members, Google Groups added the DKIM signature of our organization (d=eevidence.com; s=corp). Result: the message appeared to be “ours”.

What Happened Technically (step by step)

1. Origin and platform

   From: Stripe <FAKE>
Received: from mail73.sea31.mcsv.net …
X-Mailer: Mailchimp Mailer

   → Campaign sent from Mailchimp using the FAKE domain.

   Note. “FAKE” refers to the attacker’s email address or domain. We don’t show the real domain for security reasons.

2. Original sender authentication (from the attacker)

   spf=pass … mail73.sea31.mcsv.net
dkim=pass header.i=@FAKE
dmarc=pass header.from=FAKE

   → The attacker properly configured SPF/DKIM/DMARC for their domain and Mailchimp used this configuration to add the corresponding DKIM signature. That’s why the first hop is legitimate.

3. Entry through an internal Google Group

   To: <privacidad@eevidence.com>
List-ID: <gpdr.eevidence.com>
X-Google-Group-Id: 32262899634

4. Forwarding to list members by Google Groups including DKIM signing with our domain

   DKIM-Signature: … d=eevidence.com; s=corp
ARC-Authentication-Results: … dkim=pass header.i=@eevidence.com

   → When forwarding, Google Groups adds a new DKIM signature based on the list’s domain. To the final recipient: it looks like an internal/legitimate email, despite the original header.from being external.

Key: DMARC verification doesn’t invalidate the email because the DKIM signatures are valid, both the one Google adds when forwarding the list email to its members and the one Mailchimp added based on the sender’s domain.

Signs That Reveal the Fraud (visible to any user)

• Sender address is not from Stripe.
• Misspelled link domain.
• Urgency and generic “Compliance” case are common in phishing campaigns to force clicks.

Lessons and Mitigation Measures

1) Harden Your Google Groups

• Moderate externals: enable “Moderate messages from non-members” or “Outside the organization”.

2) Policies and Training

• Train users to always check the correspondence between email content and its sender. What sense does it make for Stripe to send a notification demanding action from an account with a domain different from stripe.com?
• “Zero-click” policy: instead of using email links, type the official URL in the browser and access the content there.
• Dual channel: validate any urgency through an alternative channel (phone, official portal).

3) About SPF/DKIM/DMARC

• Keep DMARC at p=quarantine or p=reject when possible, and periodically review your SPF settings. Use DKIM on all sending platforms, whether your own or third-party.

Frequently Asked Questions (FAQs)

Why did Gmail show it “via eevidence.com”?

Because the message was forwarded by a Google Group from our organization. When forwarding, Google signed it with DKIM from our domain, giving it the appearance of an “internal email”.

Won’t blocking externals in all Groups break things?

You can allow externals but under moderation and only in Groups that need it. The rest, members only.

Would DMARC reject have saved us?

DMARC protects your email domain from cybercriminals who want to use it as a sender. If in this case the domain used as sender had been stripe.com, Google would have rejected the incoming email due to DMARC. This email wasn’t rejected because Google checked DMARC for the attacker’s FAKE domain.

Conclusion

This case demonstrates that security is not just authentication technology, but also email architecture and governance. An open Group can turn an external message into something that looks internal.

Close what you don’t use, moderate what’s necessary, train your team and always distrust urgent links.