A recent phishing message targeting an emailexpert mailing list highlights a persistent problem in email security: authentication signals are frequently misunderstood.
At first glance, the message appeared technically credible. It landed in our Gmail inbox. It arrived through legitimate infrastructure, passed SPF, carried DKIM signatures from trusted systems, and was delivered via Google. The subject line: “Workspace: Release Incoming Messages” attempted to create administrative urgency, claiming that four messages to hello@agency.cm had failed delivery and required manual release.
The call-to-action directed recipients to a phishing page hosted at:
alertbot.kashoke.com
- a domain with no relationship to Google or Google Workspace.
Authentication Looked Clean(ish)
The message carried the following results:
- SPF: PASS
- DKIM: PASS
- DMARC: FAIL
That combination alone should immediately raise suspicion.
SPF passed because the message was legitimately transmitted through SendGrid infrastructure (149.72.123.24). DKIM signatures were present because intermediary systems — including Google infrastructure associated with the EmailExpert Google Group — added their own signatures during delivery.
To a superficial inspection, the message therefore appeared to have been authenticated successfully.
But authentication results are meaningless without identity alignment.
The Identity Didn’t Match
The visible sender was:
Workspace via Mail Management <management_google_workspace@gmail.hu>
DMARC evaluates whether authenticated domains align with the visible From domain.
In this case:
- SPF authenticated sendgrid.net
- DKIM authenticated emailexpert.org / Google infrastructure
- The visible sender domain was gmail.hu
Neither SPF nor DKIM aligned with the From domain.
DMARC therefore evaluated the message as a failure.
DMARC Detected the Problem: But Couldn’t Stop It
The authentication results show:
dmarc=fail (p=none) header.from=gmail.hu
This is an important nuance.
DMARC did exactly what it was supposed to do: it detected that the message was not authenticated for the sender it claimed to represent.
However, the domain policy for gmail.hu is p=none, which means monitoring only. The domain owner is requesting reports but not enforcement.
As a result, the message was still delivered.
This is not a case of attackers bypassing DMARC. DMARC flagged the problem. The policy simply did not request receivers to act on it. It seems in this case Google chose not to.
Trusted Infrastructure Adds Credibility
The delivery path also demonstrates how attackers increasingly exploit legitimate email ecosystems.
The message originated through SendGrid, then passed through a Google Group associated with emailexpert.org, which applied additional DKIM signatures as part of normal mailing-list processing.
That behavior is entirely legitimate.
But it also means the message accumulated trusted authentication signals as it moved through the system.
Recipients and sometimes filtering systems often interpret these signals as proof of legitimacy, even though they only validate message handling, not sender identity.
Classic Phishing Signals Remain
Even without header analysis, several indicators reveal the fraud:
- A supposed Google Workspace alert sent from
gmail.hu - A Reply-To address pointing to
joshua@tamanartebureaux.com - A phishing link hosted on a non-Google domain
- Generic operational language designed to trigger urgency
The attack is straightforward credential harvesting targeting mailbox administrators.
The Real Lesson
This example reinforces a critical distinction that is still widely misunderstood:
SPF and DKIM validate infrastructure.
DMARC validates identity alignment.
In this case:
- Infrastructure authentication passed
- Identity alignment failed
- Enforcement was not requested
The result is a phishing message that appears technically authenticated while still failing the one check that actually evaluates sender identity.
Authentication confirmed the message moved through legitimate systems.
It did not confirm that Google Workspace sent it.
