The Web Design Pitch That Routed Through a Mailing List Nobody Subscribed To

The email looked like a routine cold pitch for web design services. The body was professional, the offer was plausible, and the formatting was clean. What distinguished it from a legitimate freelancer's outreach was the delivery infrastructure beneath it: a personal Gmail account posting through a Google Groups mailing list on a domain registered seven months earlier with privacy-protected WHOIS, distributing to undisclosed recipients via BCC, with the sender's display name not matching the signature.

The message contained no links in the body. No attachments. No credential request. Its purpose was to establish contact and validate the target mailbox for a future follow-up that would carry the actual payload.

Community intelligence classified it as phishing with 90% confidence. The mailbox was flagged by automated threat detection.

Two Domains, One Message, Split Authentication

The visible From header showed Luz Tate at luzkyptate@gmail[.]com. The envelope Return-Path, however, used an entirely different domain: luzkyptate03+bncBDG7P3EOWYKBBYMMZ3HAMGQEJQCY5QY@bluecoreinnovation[.]com. This mismatch is the result of the Google Groups relay pattern.

The sender posted the message from their Gmail account to a Google Groups mailing list (luzkyptate03@bluecoreinnovation[.]com). Google Groups then redistributed the message to the target, using the group address as the envelope sender while preserving the original Gmail address in the header From. This is standard Google Groups behavior, not a misconfiguration, but it creates an authentication split that attackers can exploit.

SPF evaluation differed depending on which domain was checked. For the Gmail address (the header From), SPF passed because Google's sending IPs are authorized for gmail[.]com. For the bluecoreinnovation[.]com envelope address, SPF returned "none" because the domain does not publish SPF records that authorize Google's group relay IPs. DMARC evaluated against the header From (gmail.com) and returned a pass under Gmail's p=NONE policy, while a separate DMARC evaluation against bluecoreinnovation.com returned anomalous results.

The net effect: the message arrives with mixed authentication signals. Some gateway evaluations will see SPF pass and DMARC pass (for Gmail). Others will see SPF none (for the envelope domain). This confusion can produce inconsistent filtering outcomes depending on which domain the receiving gateway prioritizes.

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

A Young Domain With a Familiar Name

WHOIS records for bluecoreinnovation[.]com show the domain was created on May 18, 2025, registered through Namecheap with privacy protection enabled. The domain is approximately seven months old at the time of this incident, which places it in the window where many throwaway domains are used for a single campaign before being abandoned.

The name "BlueCore Innovation" closely resembles Bluecore (bluecore.com), an established marketing technology company. Whether the similarity is intentional or coincidental, lookalike domain names that mirror known brands create trust signals that recipients and automated systems may misinterpret. A receiving gateway that performs domain reputation checks may find no derogatory records for a domain this young, interpreting the absence of negative signals as neutral rather than suspicious.

The Google Groups infrastructure on this domain (luzkyptate03@bluecoreinnovation[.]com) was configured as a mailing list, complete with List-Post, List-Help, List-Archive, List-Subscribe, and List-Unsubscribe headers. This full set of mailing-list metadata makes the message appear to be a legitimate group distribution, further reducing the likelihood of spam classification by gateways that give preferential treatment to messages with valid list headers.

The Body That Was Almost Too Clean

The message body was a short, professional cold pitch offering custom website design, UI/UX, WordPress, Shopify, CMS development, e-commerce, landing pages, and SEO services. The greeting was generic ("Hi there"). The tone was conversational. There were no spelling errors, no urgency cues, and no credential or payment requests.

Two details broke the pattern. First, the display name in the From header was "Luz Tate," but the signature at the bottom read "Lucky," an inconsistency that suggests a reusable template where the signature was not updated to match the current sender identity. Second, the message was sent to "undisclosed-recipients:;" with a BCC header, confirming mass distribution despite the personal, one-to-one tone.

A public identity search for "Luz Tate" or "Lucky" at the Gmail address returned no verifiable professional profile, portfolio, or business registration. The sender was a first-time contact to the recipient organization and was flagged as high risk.

IRONSCALES Adaptive AI classified the message as a vendor scam at 90% confidence. Community intelligence across the network reinforced the classification based on pattern matching against similar campaigns.

MITRE ATT&CK Alignment

IOC Summary Table

Detecting the Relay Behind the Pitch

Google Groups relay abuse is operationally distinct from direct-send phishing. The relay provides legitimate mailing-list headers, Google-signed ARC chains, and clean domain reputation inherited from the group infrastructure. Detection must look past the relay to the campaign behind it.

Flag envelope and header From mismatches involving young domains. When the Return-Path domain differs from the header From domain and the envelope domain is less than a year old with privacy-protected WHOIS, the message warrants elevated review regardless of whether authentication passes for the header domain.

Treat BCC distribution with mailing-list headers as suspicious for cold outreach. Legitimate mailing lists have subscribers. A Google Groups list on a young domain distributing unsolicited cold pitches via BCC to external recipients is a distribution technique, not a subscription service.

Evaluate display-name and signature consistency. When the From display name does not match the signature block, the template was reused across identities. This is a low-confidence but high-specificity signal for mass-campaign infrastructure.