Note that it doesn't help avoid Google actually sending out a message with user-provided text in it, but it does stop it being replayed to you without Google intending it, because the SMTP FROM/TO are protected.
The motivation draft doesn't include technical detail, see early drafts of the technical detail in the various related docs at:
I actually have had the FBI seize all of my Google account materials before when I was convicted of computer hacking. The search took place in 2016 and 2018 as they came back and took everything a second time.
Anyhow, they don't do it at all like this. I would have to check my discovery for some details and it's in cold storage, but they basically just send an e-mail to a specific department at Google and have that communication. They go through a decent amount of trouble to try to NOT tip you off.
I've seen a similar attack in my inbox recently where people do the same trick by sending an email to yourgoogleaccount@google.com instead of Gmail.com and then forwarding the bounce from Google's mail servers to yourgoogleaccount@gmail.com with a spam message smuggled at the end.
Passes all checks. Just kinda weird that a postmaster error is intertwined with a phishing campaign. But easy to gloss over as a non-technical user.
In my case the phishing campaign told me I won some construction tools or something.
IMO the real vulnerability here is that you can put a URL in the App Name for a Google OAuth app, and Google will render that in no-reply emails to arbitrary addresses from its root domain. (And even if that render is not clickable, if you make the surrounding text scary enough, the victim will navigate there.)
The fact that any number of keep-DKIM-intact forwarding services can be stacked on top is almost secondary - though educational.
There should be no legitimate reason for the App Name of an OAuth app to contain a URL, and especially one containing google.com. That is where this should be fixed.
This is a very confusing read. It gives the impression that the attacker managed to manipulate the email body to insert their phishing link, by talking at length about how the sites.google.com link is suspicious (of course it is, no doubt about that). But at the same time, they don’t say or show evidence that the body was manipulated; in fact quite the opposite.
My understanding is that the DKIM signature contains a bh= field with a hash of the email body. While you can technically also include an optional I= field to limit the body length for hashing, so that an attacker can append to the body, which is a pretty big security hole, it’s probably never used by Google for such short emails (I checked some of my own emails from no-reply@accounts.google.com and they certainly don’t have I=). Therefore to pass DKIM and DMARC the body had to be intact, so the “phishing link” was actually from Google, just intended for a different recipient.
If my analysis is correct then TFA really is a lot of words to say a scary email was forwarded to wrong people to scare them. Scary of course, but much less scary than the “DKIM replay attack” title implies to technical people who are not deep into this subject.
Edit: Oh, I thought “The Takeaway?” was the end of TFA since it had CTA for their product. Apparently there’s an update below explaining the link was actually part of a Google OAuth app name which was then inserted into Google’s email template. Terrible writing and structuring of the article, burying arguably the most important part of the attack that made it somewhat convincing, and misleading readers to believe the attack can be used to send arbitrary content.
Edit 2: Other commenters pointed out that the screenshot of the email is conveniently cut off so the fixed part of the Google email template isn't shown. The attack is probably even more clumsy then it seems from the quite deceptive crop.
I received almost exactly this email a couple of months ago, but targeted at a google domains admin! I was, of course, also spooked by it. I did wait out and avoided clicking links in it, but I could not really find any references to this scam.
What gave it away was that all email-addresses were masked, and those masks did not match up with any emails that I administer as a workspace admin. But yes, the email itself was legit, I googled that and the text passage matched. In my case it was an email for a deceased persons email, which ofc also did not match reality. But I was almost 100% at some point that someone had actually convinced Google I was deceased, and was going to access my entire Google account, talk about scary!
AFAIK you can't spoof the path listed in the Received: headers as all the servers on the path will add their own. That's always been my way of verifying where emails come from, and it's reassuring to know that I would've caught this one too. Emails coming from Google aren't going to take a detour through Microsoft servers.
This is terrifying. Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass… it doesn’t feel good to imagine their reaction.
This is still limited in what you can do though. For example you can’t use this to forge messages from other people’s Gmail accounts.
> When the message is forwarded, the original DKIM signature usually remains untouched as long as the email content and headers covered by the signature are not modified
It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature. They should just change how their signing is configured, and email clients should warn when the email is legit but the intended recipient could have been changed.
This to me just appears to demonstrate what a house of cards email security really is....surely with the collective brains on this forum we can come up with an alternative that solves all of this. And surely Google needs to serve these sites under a different domain name....why aren't these sites published under something like 'hostedbygoogle.com'?
Okay, the technical breakdown is wild. But my first thought was: how on earth do I explain this risk to my non-technical boss or clients? If I say 'they can bypass DKIM with a replay attack,' their eyes will just glaze over. We need a simple, powerful way to communicate this stuff. Anyone have a good one-liner for this?
I consistently get the same phishing emails. From the headers I assume they are coming from a google service. I have been reporting them using google's reporting page for over a year.
People keep trying to use DMARC as some sort of sender authorization scheme. It continues to be a server reputation scheme.
An unsigned email is still anonymous, no matter what DKIM and SPF say. It should be treated as such. No one should ever think: This email passed through a Google email server at one point. It must be legit.
Post is several months old, and it appears that the underlying OAuth issue was fixed by Google a while back - you can't make arbitrarily long app names anymore...
Google allows you set input long paragraphs and URLs into a field called "App name" and they then send you an email with the paragraph you entered in (malicious with phishing links) to your inbox. Since this is sent by Google, it's DKIM signed and passes DMARC so you can simply download the entire email and just send it as a raw email to other people and it'll continue to be signed and land in their inboxes.
The other thing is that with these we cannot change the "To" header in the email (not envelope TO (which is where email is delivered to) but rather what shows up in the "To" when the client renders the email) and so the attacker bought a domain that looks like it's google owned "(rand)goog-ssl.com". When looking at emails in your inbox ensure that the "To" is always valid along with the "From".
>The branding and language were polished and professional
>There were no obvious grammar issues or suspicious attachments.
Really? No. Not even close to true. That looks nothing like professional, native-english-speaking legalese (which it would be if it were actually a notification from Google).
This trick of stuffing a huge mass of text into the title of something to make a Google email like this isn't a new trick and is a much bigger issue than this email not properly showing up as being forwarded.
It seems the issue is that the to: field is signed, but the whole email can be forwarded afterward as though it were being sent from the source server to a person who wasn't actually a recipient.
In this case Google really did send an email to the strange domain, which then forwarded it to the recipient and made it seem as though it was coming from Google's server directly to the recipient.
This works as long as the recipient doesn't realize that they are not in the "to:" field.
Google spoofed via DKIM replay attack: A technical breakdown
(easydmarc.com)289 points by frasermarlow 25 July 2025 | 95 comments
Comments
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
Note that it doesn't help avoid Google actually sending out a message with user-provided text in it, but it does stop it being replayed to you without Google intending it, because the SMTP FROM/TO are protected.
The motivation draft doesn't include technical detail, see early drafts of the technical detail in the various related docs at:
https://datatracker.ietf.org/wg/dkim/documents/
Anyhow, they don't do it at all like this. I would have to check my discovery for some details and it's in cold storage, but they basically just send an e-mail to a specific department at Google and have that communication. They go through a decent amount of trouble to try to NOT tip you off.
Passes all checks. Just kinda weird that a postmaster error is intertwined with a phishing campaign. But easy to gloss over as a non-technical user.
In my case the phishing campaign told me I won some construction tools or something.
The fact that any number of keep-DKIM-intact forwarding services can be stacked on top is almost secondary - though educational.
There should be no legitimate reason for the App Name of an OAuth app to contain a URL, and especially one containing google.com. That is where this should be fixed.
My understanding is that the DKIM signature contains a bh= field with a hash of the email body. While you can technically also include an optional I= field to limit the body length for hashing, so that an attacker can append to the body, which is a pretty big security hole, it’s probably never used by Google for such short emails (I checked some of my own emails from no-reply@accounts.google.com and they certainly don’t have I=). Therefore to pass DKIM and DMARC the body had to be intact, so the “phishing link” was actually from Google, just intended for a different recipient.
If my analysis is correct then TFA really is a lot of words to say a scary email was forwarded to wrong people to scare them. Scary of course, but much less scary than the “DKIM replay attack” title implies to technical people who are not deep into this subject.
Edit: Oh, I thought “The Takeaway?” was the end of TFA since it had CTA for their product. Apparently there’s an update below explaining the link was actually part of a Google OAuth app name which was then inserted into Google’s email template. Terrible writing and structuring of the article, burying arguably the most important part of the attack that made it somewhat convincing, and misleading readers to believe the attack can be used to send arbitrary content.
Edit 2: Other commenters pointed out that the screenshot of the email is conveniently cut off so the fixed part of the Google email template isn't shown. The attack is probably even more clumsy then it seems from the quite deceptive crop.
I received almost exactly this email a couple of months ago, but targeted at a google domains admin! I was, of course, also spooked by it. I did wait out and avoided clicking links in it, but I could not really find any references to this scam.
What gave it away was that all email-addresses were masked, and those masks did not match up with any emails that I administer as a workspace admin. But yes, the email itself was legit, I googled that and the text passage matched. In my case it was an email for a deceased persons email, which ofc also did not match reality. But I was almost 100% at some point that someone had actually convinced Google I was deceased, and was going to access my entire Google account, talk about scary!
AFAIK you can't spoof the path listed in the Received: headers as all the servers on the path will add their own. That's always been my way of verifying where emails come from, and it's reassuring to know that I would've caught this one too. Emails coming from Google aren't going to take a detour through Microsoft servers.
This is still limited in what you can do though. For example you can’t use this to forge messages from other people’s Gmail accounts.
> When the message is forwarded, the original DKIM signature usually remains untouched as long as the email content and headers covered by the signature are not modified
It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature. They should just change how their signing is configured, and email clients should warn when the email is legit but the intended recipient could have been changed.
> "Here is the URL from that email [..] https://sites.google.com[...]"
THAT link is the first red flag, and I think the author should say so right there, not three paragraphs later.
https://support.google.com/mail/contact/abuse
Only in the last couple of weeks have a seen a decrease in one particular source. I always thought they were using a gmail mailing list service.
An unsigned email is still anonymous, no matter what DKIM and SPF say. It should be treated as such. No one should ever think: This email passed through a Google email server at one point. It must be legit.
Google allows you set input long paragraphs and URLs into a field called "App name" and they then send you an email with the paragraph you entered in (malicious with phishing links) to your inbox. Since this is sent by Google, it's DKIM signed and passes DMARC so you can simply download the entire email and just send it as a raw email to other people and it'll continue to be signed and land in their inboxes.
The other thing is that with these we cannot change the "To" header in the email (not envelope TO (which is where email is delivered to) but rather what shows up in the "To" when the client renders the email) and so the attacker bought a domain that looks like it's google owned "(rand)goog-ssl.com". When looking at emails in your inbox ensure that the "To" is always valid along with the "From".
I guess they edited the screenshot.
>The branding and language were polished and professional >There were no obvious grammar issues or suspicious attachments.
Really? No. Not even close to true. That looks nothing like professional, native-english-speaking legalese (which it would be if it were actually a notification from Google).
It seems the issue is that the to: field is signed, but the whole email can be forwarded afterward as though it were being sent from the source server to a person who wasn't actually a recipient.
In this case Google really did send an email to the strange domain, which then forwarded it to the recipient and made it seem as though it was coming from Google's server directly to the recipient.
This works as long as the recipient doesn't realize that they are not in the "to:" field.