I feel like I’m always consistently seeing a Google IP that ends in “69” that fails DKIM with the same selector as all of the other IPs that are fine. Often, that same server is also listed as having passed DKIM too.
Maybe I’m just trying to get too granular, but I’d love to at least know why this happens and more importantly, is there something I’m supposed to be doing to fix this.
I see this across many different clients all of whom have their primary email and MX on Google Mail. I suppose the 69 thing may just be Bill&Ted stuck in my head like the number 22… but it does feel real and might be an extra clue to someone, particularly if they reserve that server for something like autoreplies or bounces or something that might be causing this to happen.
Our tools can help solidify any trend or pattern that you see. For instance, If you are looking as Google as a source, you can expend our filters using the “advanced filters” drop down and specify Google as the sending source. Further more, you can specify the DKIM raw verdict of fail, expend the time period of the search to the entire month of February. You will find that doing so returns result overwhelmingly sent from the IP you singled out.
If you can get your hands on an actual sample, I would follow up with Google with this search result and sample after confirming that all of your NS are properly configured into answering the DNS query with the correct DKIM record.
I dug way too far into this and what I think is happening is that Google chooses to report the IP 209.85.220.69 as the source IP address in the DMARC XML reports… though when I find the actual headers it is a different IP address like 209.85.220.41.
So this is less about what actually happened and more about how Google chooses to report… and why I think I keep seeing a disproportionately sized amount of forwarded gmail from this 69 IP address.
I’ve been dealing with the exact same problem. I’ve yet to turn on a quarantine or rejection policy because this IP address constantly shows up in our DMARC logs and I’m worried about breaking something.
@cheyennethrock Did you manage to dig up anything else in research regarding this? Were any of these legitimate emails that Google was incorrectly flagging? Any theories as to why Google is changing the IP it reports to this 69 IP address?
Long story short, after some very detailed digging, we’ve been ignoring it with no issues. I really do think this is more of a Google reporting mechanism… maybe even something to try and understandably hide some of their infrastructure and then say in the reports “oh yeah, right, it was the 69 server that it… smirk”.
You should feel free to escalate your policies without worrying over this idiosyncrasy. That’s what we’ve been doing to 100’s of domains for our clients. Let us know if you do ever see an issue.
@cheyennethrock I set our policy to quarantine back in October, and interestingly this IP address has completely disappeared from the weekly reports. Before it would show up most weeks (sometimes multiple times) in the DMARC report.
I’ve also noticed that the amount of non-aligned emails has gone done considerably overall.
Is it possible that spammers see the quarantine policy and don’t even bother trying to send as our domain now?
Hi, I arrived here because I’ve been having issues sending emails recently and the only clue I have is this IP.
I have a Google Apps Script app that sends emails via MailApp. It used to run fine, but recently I started to see Mail Delivery Subsystem emails in my Google Workspace email account assigned to receive DMARC reports. The email looks like this (some info scrubbed):
The response was:
550 5.7.26 Unauthenticated email from mydomain.com is not accepted due to domain's DMARC policy. Please contact the administrator of mydomain.com domain if this was a legitimate mail. Please visit https://support.google.com/mail/answer/2451690 to learn about the DMARC initiative. m21-20020a056870a41500b001ef38a85f51sor3934375oal.10 - gsmtp
Reporting-MTA: dns; googlemail.com
Arrival-Date: Tue, 07 Nov 2023 02:16:31 -0800 (PST)
X-Original-Message-ID: <autogen-java-...@google.com>
Final-Recipient: rfc822; someone@gmail.com
Action: failed
Status: 5.7.26
Diagnostic-Code: smtp; 550-5.7.26 Unauthenticated email from mydomain.com is not accepted due to domain's
550-5.7.26 DMARC policy. Please contact the administrator of mydomain.com domain
550-5.7.26 if this was a legitimate mail. Please visit
550-5.7.26 https://support.google.com/mail/answer/2451690 to learn about the
550 5.7.26 DMARC initiative. m21-20020a056870a41500b001ef38a85f51sor3934375oal.10 - gsmtp
Last-Attempt-Date: Tue, 07 Nov 2023 02:16:31 -0800 (PST)
Looking at the DMARC report, everything passed except for one IP which failed:
I tried sending a test email through the GAS app to my personal Gmail, and sure enough it never arrived and I received the rejection notification email in my Workspace account. Any ideas on how to resolve this?
In the future I do recommend you post a new topic as it is unrelated to the current discussion.
What you are describing is a common issue with emails sent from Google Apps Script.
Emails sent this way will never achieve SPF alignments. The MAIL FROM is always going to be “maestro.bounces.google.com”. This is an expected behaviour. To bring these emails into compliance, you will need to deploy custom DKIM signing in your Google Apps account.
Hi, apologies for posting in a stale thread, and thanks for the info. I found out the cause thanks to your link (I’m on Google Domains, but the reason DKIM wasn’t automatically set up was because I’m not on the correct subscription plan).
