How a genuine Google security alert was used to deliver a phishing instruction, with forensic analysis of DKIM, SPF, DMARC and email relay headers
Earlier today, a peculiar security alert landed in my primary Gmail inbox.
At first glance, it looked like another credential-harvesting attempt disguised as a Google account notification. The familiar branding, security language and instruction to visit a website were all there. But something about the message didn't add up.
I manage several Google accounts for different purposes, and some of their security notifications are forwarded to my primary inbox. So an alert addressed to another account isn't, by itself, unusual. Before dismissing this one, I checked my account register to see whether the address mentioned in the notification belonged to me. It didn't. That was the point at which I decided to look more closely.
As anyone who has spent time investigating suspicious emails knows, appearances only tell part of the story. The more useful evidence is often buried in the message headers, where authentication results and mail routing records reveal how an email actually reached its destination.
In this case, examining the raw message exposed something more interesting than ordinary sender spoofing. The apparent attacker had managed to place a phishing instruction inside a genuine Google security notification, then redistribute that notification through an unrelated mail server.
The result was an email that combined Google's legitimate infrastructure and cryptographic signature with a suspicious instruction pointing to a Google Sites page.
Here's what the evidence reveals.
The Bait aka Turning Google's Own Alert into a Phishing Message
When a third-party application receives permission to access information associated with a Google Account, Google may send a security notification describing that access.
The wording generally follows a recognisable pattern:
You allowed [App Name] access to some of your Google Account data.
That application name is the interesting part.
Rather than attempting to forge Google's notification template, the attacker appears to have exploited the way application names are inserted into legitimate security messages.
The suspicious application name embedded in the email was:
access to data, go to sites.google.com/view/auth-data to stopWhen inserted into the notification template, the resulting sentence became:
You allowed access to data, go to sites.google.com/view/auth-data to stop access to some of your Google Account data.
Grammatically, it's a mess. From a social engineering perspective, however, it accomplishes something useful for the attacker: it introduces an instruction to visit a website inside a message that genuinely originated from Google.
The address also matters. Instead of directing recipients to an unfamiliar domain, the instruction references sites.google.com, Google's own website publishing service.
A Google-hosted URL is not automatically trustworthy. Google Sites pages can contain content created by third parties, and the reputation of the hosting domain does not establish the legitimacy of an individual page.
Nevertheless, placing a suspicious instruction within a legitimate notification, while pointing it towards a familiar Google domain, creates a convincing combination.
The available evidence is consistent with an attacker-controlled application name being used to inject the instruction. It does not, by itself, establish exactly how the application was configured or whether the linked page successfully collected credentials.
The Cryptographic Reality: Google Really Sent the Original
The first significant finding was that the original notification appeared to be authentic.
The preserved headers included:
From: Google <no-reply@accounts.google.com>
To: couldexcited@gmail.com
Message-ID: <2Yh6LOMYg_NBznpmQzW5nA@notifications.google.com>
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@accounts.google.com
header.s=20260707;
spf=pass
smtp.mailfrom=...@gaia.bounces.google.com;
dmarc=pass
header.from=accounts.google.com;These results are important because they distinguish the original notification from an ordinary spoofed email.
- DKIM passed: The message carried a valid signature associated with
accounts.google.com. - SPF passed: The original sending infrastructure was authorised for the envelope sender domain recorded in the authentication results.
- DMARC passed: The authentication results satisfied the domain alignment requirements for the visible Google sender address.
In other words, the original message was not simply an attacker pretending to be Google.
It was a Google-generated notification containing attacker-controlled text.
That distinction changes the nature of the problem. Email authentication can establish that a message originated from an authorised sender, but it cannot guarantee that every piece of information included in that message is safe.
The Catch: Why Did It Arrive in My Inbox?
The original notification was addressed to couldexcited@gmail.com, the unfamiliar address that had prompted me to check my account register.
Yet the message had arrived in my own Gmail inbox. Forwarded notifications are normal for me, but this address wasn't associated with any of my accounts. The routing headers offered a way to understand how it got there.
The later routing headers show that the message passed through an external mail relay before reaching Gmail:
Received: from grh54.myukcloud.com
(trex-green-3.trex.outbound.svc.cluster.local
[100.98.43.105])
(Authenticated sender: 6rhlj5al9z)
by relay.mailchannels.net (Postfix)
with ESMTPA id 03B4E8C0FE6
for <[redacted_recipient]@gmail.com>;
Sun, 11 Oct 2026 22:53:16 +0000 (UTC)
X-Sender-Id:
6rhlj5al9z|x-authuser|
host_akibc3548@makanperfumes.comThe message had evidently travelled beyond its original delivery path.
The external relay accepted the message through an authenticated submission associated with a hosting account identified in the X-Sender-Id header.
The routing information identifies grh54.myukcloud.com and MailChannels infrastructure as part of the later delivery chain. Another recorded relay address was 23.83.209.6.
There are several plausible explanations for how the sender obtained and retransmitted the original message. One is that the attacker controlled the account receiving the initial Google notification and reused the message as a phishing template.
The headers establish that the later submission used authenticated relay access. They do not establish whether the hosting account was compromised, whether its credentials were stolen, or whether its legitimate operator knowingly sent the message.
The Envelope Recipient Didn't Match the Message Header
One of the clearest clues was the difference between the SMTP envelope recipient and the recipient displayed inside the email.
During the later delivery, the relay directed the message to:
RCPT TO: <[redacted_recipient]@gmail.com>But the preserved message header still identified the original recipient:
To: couldexcited@gmail.comThese two addresses serve different purposes.
The SMTP envelope recipient determines where the receiving mail server should deliver a message. The To: field is part of the message content and does not necessarily control delivery.
A mismatch is not automatically malicious. Mailing lists, forwarding services and blind carbon copy deliveries can produce similar differences.
In this case, however, the mismatch is particularly revealing when considered alongside the unrelated relay infrastructure and the suspicious instruction embedded in the notification.
It strongly suggests that a previously generated message was forwarded or retransmitted to another recipient without updating its original To: header.
The Forensic Breakdown and What the Authentication Results Actually Show
The authentication results recorded when the message reached Gmail provide another important piece of evidence.
Received-SPF: softfail
(google.com: domain of transitioning
no-reply@accounts.google.com
does not designate 23.83.209.6
as permitted sender)
client-ip=23.83.209.6;
Authentication-Results: mx.google.com;
dkim=permerror (no key for signature)
header.i=@makanperfumes.com;
dkim=pass
header.i=@accounts.google.com;
spf=softfail
smtp.mailfrom=no-reply@accounts.google.com;
dmarc=pass
(p=REJECT sp=REJECT dis=NONE)
header.from=accounts.google.com;
dara=fail
header.i=@gmail.comAt first glance, these results appear contradictory. SPF failed its authorisation check, one DKIM signature produced an error, and yet DMARC still passed.
There is a straightforward technical explanation.
SPF Softfail. The Relay Wasn't Authorised by Google
The SPF result was:
spf=softfail
smtp.mailfrom=no-reply@accounts.google.comThe connecting IP address, 23.83.209.6, was not authorised by the applicable SPF policy to send on behalf of the Google envelope sender domain.
This is consistent with the message being retransmitted through unrelated infrastructure.
An SPF softfail is not the same as an outright SPF fail. It indicates that the sending host did not satisfy the domain's published authorisation policy, with the result reflecting the policy's softer failure mechanism.
DKIM. One Signature Failed, but Google's Survived
This is perhaps the most interesting authentication detail.
The receiving server reported two separate DKIM results:
dkim=permerror (no key for signature)
header.i=@makanperfumes.com;
dkim=pass
header.i=@accounts.google.com;The additional signature associated with makanperfumes.com could not be verified because the necessary public key was unavailable to the verifier.
However, Google's original DKIM signature still passed.
That means the retransmission preserved the parts of the message covered by Google's valid signature sufficiently for verification to succeed.
This is a critical distinction. The later relay did not invalidate Google's original DKIM signature, even though it introduced a separate authentication problem.
The message therefore retained cryptographic evidence of its legitimate origin after being sent through unrelated infrastructure.
Why DMARC Still Passed
The final DMARC result was:
dmarc=pass
(p=REJECT sp=REJECT dis=NONE)
header.from=accounts.google.comDMARC does not require both SPF and DKIM to pass.
It requires at least one of those authentication mechanisms to pass with appropriate alignment to the domain in the visible From: address.
Because Google's original aligned DKIM signature remained valid, DMARC could still pass despite the SPF softfail.
The p=REJECT value describes the domain owner's published policy for messages that fail DMARC. It does not mean this particular message was rejected.
Similarly, dis=NONE indicates that no DMARC enforcement disposition was applied in the reported result.
The important lesson is that a DMARC pass does not necessarily mean the message travelled directly from the original sender to the final recipient.
It establishes successful aligned authentication, not the absence of subsequent redistribution or malicious content.
What Makes This Attack Different?
Traditional phishing often relies on impersonation. Attackers register lookalike domains, forge display names, reproduce familiar logos and hope the recipient overlooks the differences.
This example took a different approach.
Instead of fabricating the entire security notification, the attacker appears to have used a legitimate notification as the delivery vehicle for malicious instructions.
That approach creates several advantages for the attacker.
- Authentic sender identity: The original notification genuinely originated from Google's infrastructure.
- Valid cryptographic authentication: Google's DKIM signature survived the later retransmission.
- Trusted-looking destination: The instruction referenced a page under
sites.google.com, rather than an unfamiliar standalone domain. - Reusable message content: The evidence is consistent with a previously generated notification being redistributed to an unrelated recipient.
None of these characteristics makes the instruction legitimate. Together, however, they help explain why this type of phishing attempt can be harder to assess than an ordinary forged email.
The attack is better understood as an abuse of trusted notification infrastructure than as a straightforward failure of email authentication.
What the Headers Prove, and What They Don't
There is enough evidence in this message to establish several important points.
The preserved authentication results support the conclusion that the original notification was generated through Google's legitimate mail infrastructure. The suspicious application-name text was incorporated into that notification. The message was subsequently delivered to a different recipient through external relay infrastructure, while Google's original DKIM signature remained valid.
There are also limits to what can be concluded from a single message.
The headers do not prove that the external hosting account was compromised. They do not establish the attacker's identity, the full sequence of actions used to generate the notification, or whether the Google Sites destination successfully harvested any credentials.
Nor do they prove that a particular spam filter failed because the URL belonged to Google Sites.
Those questions would require additional evidence, including application configuration records, hosting logs, the contents of the destination page and potentially information held by the service providers involved.
Keeping those distinctions clear is part of sound forensic analysis.
Lessons from a Legitimate Message Used for Phishing
The first lesson is for providers operating automated notification systems.
Application names, document titles, organisation names and similar metadata can be controlled by third parties. When those values are inserted into security notifications, they can become vehicles for misleading instructions.
Appropriate validation, restrictions on potentially deceptive application names and clear visual separation between trusted notification text and third-party metadata can reduce that risk.
For recipients, the lesson is equally straightforward: a genuine security email can still contain untrustworthy information.
If a Google security notification asks you to visit an unfamiliar page to stop access to your account, don't assume the instruction is legitimate simply because the message is authenticated.
Instead, open your Google Account security settings independently by navigating to Google Account Security. Review connected applications and recent security activity there, rather than following an unexpected instruction embedded in an email.
And if something about a message seems unusual, Gmail's Show original feature can provide useful evidence. Look at the actual sending path, authentication results and recipient information rather than relying solely on the displayed sender name.
One caution, though: headers are evidence, not an infallible account of events. Some fields can be forged, and individual authentication results need to be interpreted in context.
What made this message interesting wasn't that Google's authentication failed. In one crucial respect, it worked exactly as designed.
Google's DKIM signature verified the original message, even after that message had been redistributed through unrelated infrastructure.
The problem was that the authenticated message itself carried an instruction that should never have been trusted merely because it appeared inside a legitimate security notification.
That's the uncomfortable reality of this particular phishing technique, sometimes the sender really is who the email says it is, and the message can still be part of an attack.
COMMENTS