Google Groups List-ID Masks a Cold Vendor Pitch

A hotel front-desk mailbox received a note that looked like a simple bit of outreach. The display name read like a real person, "Jomie Loiis," and the address behind it was an ordinary personal Gmail account. The body was a cold pitch: an offer of mobile and app-development services, unsolicited, closing with a request for the recipient to reply with their app idea and requirements. No attachment. No link the sender had placed. Nothing that trips a payload scanner. On its face, it was the kind of low-effort vendor email that lands in a hospitality inbox every week.

The friendly Gmail persona on the front of that message was not the identity the mail system actually authenticated. And the gap between the two is the entire story.

The From address and the authenticated address were different

When the message was inspected, DMARC failed. That is the part worth slowing down on, because it runs opposite to the usual authenticated-phishing pattern. DMARC failed specifically for gmail[.]com, the domain in the visible From header, because the cryptographic identifiers the message actually carried did not point at Gmail at all. They pointed at frantic[.]in, an unrelated domain hosted on Google Workspace.

For that hidden domain, the checks passed cleanly. SPF passed, with the sending IP resolving to Google's own mail infrastructure. DKIM passed, signed with a Google Workspace selector for frantic[.]in. Composite authentication returned a pass on that non-displayed identity, and the message carried a moderate spam-confidence score rather than a blocking one. In other words, the email was authenticated, just not as the sender it showed the recipient. It authenticated as the domain it hid.

And frantic[.]in itself published no DMARC record. A lookup for its policy returns nothing, an NXDOMAIN. So the domain doing the real sending had no alignment policy of its own to enforce, and the domain shown to the human, gmail[.]com, had a policy that the message could not satisfy. The result was a message with a genuine, verifiable sending identity that had nothing to do with the name in the recipient's inbox.

Google Groups mechanics doing the masking

The way those two identities were held apart was mailing-list infrastructure. The message carried a Google Groups signature: a List-ID header of jomieloiis51.frantic[.]in, and the aligned Sender and Return-Path resolved to jomieloiis51[at]frantic[.]in, the same address the message was blind-copied to as the group's posting address.

That is mass-distribution plumbing wearing the costume of a one-to-one email. Google Groups is a legitimate service, built to fan a single message out to a list. Here it was pointed at a cold-outreach campaign so that a personal Gmail display name could sit on top of list-send mechanics. The recipient sees an individual reaching out. The headers describe a mailing list broadcasting from an unrelated Workspace domain. A first-time sender with no prior relationship, presenting as a person but structured as a list, is not the shape of genuine one-to-one correspondence.

It is worth being precise about what was not part of this attack. The message did contain a handful of URLs pointing at Microsoft support pages, but those were security banners the recipient's own tenant inserted into the message, not links the sender supplied. There was no credential form, no malware, no attacker-controlled link. The payload was the pitch text and the reply request, which is exactly why an inspection that only weighs attachments and links comes up empty.

Why an authentication check alone waves this through

Point a purely authentication-driven gateway at this message and it finds a valid SPF pass, a valid DKIM signature, and mail genuinely originating from Google's infrastructure. Those facts are all true. They simply describe the wrong sender. This is the recurring blind spot in authentication-first email defense: the checks confirm that a message came from where its aligned domain claims, and they say nothing about whether the identity a human reads matches the identity the machine verified. If your controls stop at the auth verdict, it is worth understanding how wide that gap can get with the SEG email security gap calculator.

IRONSCALES read the message the way a suspicious analyst would. Our Adaptive AI weighed the signals authentication could not: a first-time sender with no established history, a personal Gmail persona wrapped in Google Groups list-send mechanics, and a visible From identity that did not match the domain the message actually authenticated as. Themis flagged the identity-masking pattern, not the crypto, because the crypto was, in its own narrow way, valid. The tell was behavioral. A one-to-one note should not be arriving through mailing-list infrastructure under a name the aligned domain does not support.

The technique is deliberately unglamorous, which is why it scales. The 2024 Verizon Data Breach Investigations Report found phishing present in 15 percent of breaches and the human element involved in 68 percent of them, with pretexting the leading social-engineering pattern. An unsolicited pitch engineered to hide its real sender and open a reply thread is a rapport-building opener, and it works precisely because it targets the human, not the filter.

Indicators of compromise

MITRE ATT&CK mapping

• T1566.003, Phishing: Spearphishing via Service: Google Groups mailing-list infrastructure used to mass-distribute a message that presents as personal one-to-one outreach, holding the displayed identity apart from the authenticated one.

What security teams should take away

An authentication pass answers a narrow question: did the message come from where its aligned domain says. It does not answer the question a human is actually asking, which is whether the person named in the inbox is the person who sent the mail. When those two identities split, as they did here, an auth-only control sees a valid signature and moves on, while the recipient sees a stranger's friendly name. Treat a mismatch between the visible From and the authenticated sending domain as a signal in its own right, and treat mailing-list mechanics behind a supposedly personal message as another. As the DMARC specification in RFC 7489 makes clear, alignment is measured against the From domain, so a fail there is telling you the displayed sender is not the one that authenticated. Put detection in front of that gap that reasons about identity and relationship, not just cryptographic pass or fail. If you want to see how that behavioral layer handles authenticated-but-misaligned mail against your own traffic, request a demo.