Gappssmtp Dkim

[Jeff]

Werecommend you always set up a DKIM key for your domain, following the steps in this article. If you don't set up your own DKIM key, Gmail signs all outgoing messages with a default DKIM key: d=*.gappssmtp.com. Messages sent from non-Google servers aren't signed with the default DKIM key.

Important: The Authenticate email page in your Google Admin console might continue to display this message for up to 48 hours: You must update the DNS records for this domain. If you've correctly added your DKIM key at your domain provider, you can ignore the message.

The goal is to determine if the signed-by field was generated by a DomainKeys Identified Mail (DKIM) or a service. A DKIM attaches a domain identifier to the signature to display an email generated by a user in the domain. For example, if you received an from [email protected], you would see a DKIM in the signature that looks like this datto-com.20150623.gappssmtp.com. This is how all emails through a domain are processed.

Emails shared through a service (i.e. Drive, Calendar, Dropbox, Box, Etc) do not have a DKIM. Instead, you would see the signature of the provided service. If something is shared through Dropbox, for example, you would see signed-by dropbox.com.

Gmail is sending email from alternative email addresses (secondary domain) with the Return-Path set to the primary email address. Even though DKIM (and SPF) is setup for the secondary domain, DMARC is failing due to the Return-Path being different.

I have raised this with Google support staff on 2 occasions now.. no one seems to fully understand why this is such a big issue or how to get it in front of the right people.

Here is a redacted example header:

So, I thought I was smart to come up with a workaround and route emails from this alternative email address to an external SMTP server.. but this isn't possible as Google Workspace "hosts" section doesn't have provision for authentication. On top of this, there is no way to force using a 3rd party SMTP server in Gmail "send mail as" if the domain is already added as a secondary (or alias domain) in workspace.

I'm frustrated and looking for either a fix from Google or a working workaround.

Here is one DMARC analyser tool's explanation:

It turns out I have quite an unusual setup. My primary domain is A, and my alias domain is B. In addition, I sign into my Google admin console with a third (legacy) domain, C. This is technically a secondary domain, but I don't really use it for anything other than signing in. So I have Google admin user accounts under both A and C.

What happens is that DKIM configuration works perfectly for my primary domain A, no matter which admin account I use to log in. BUT - DKIM configuration completely fails for the alias domain (B) unless I log into the console using the primary domain (A), even though it misleadingly generates a key and shows as authorizing when you set up the DNS records.

Let's see if I understood. Are you trying to say that I should create a new DKIM record and update the DNS? So that it re-authenticates and the Domain B authentication doesn't fail again. Is that correct?

Regards

That's right. If you're not logged into the console using your *primary* domain (the one for which you'd like the alias domain set up), then the DKIM config/authentication will not work for the alias, despite the UI lying to you and saying that it's authenticating. You need to log in under an admin account from the primary domain for the process to work. (FYI, you don't need to do this if you're just trying to set up DKIM for a primary domain).

Thanks for the response. I'm referring to the "DKIM-Signature" header on an email received from my alias domain email (see screenshot, tested on an email sent from my alias email to my personal address):

My understanding is that if DKIM is authenticating properly, we should see the alias domain in the signature (see help article here ... "If you don't set up your own DKIM key, Gmail signs all outgoing messages with a default DKIM key: d=*.gappssmtp.com. Messages sent from non-Google servers aren't signed with the default DKIM key.").

Thanks @jsstamour - I'm trying to figure out what that wrong thing is. I checked and triple checked TXT record, also waited 24+ plus for each iteration, and GW authentication for the alias shows it's working (see below).

Ok, I see. So the email is signed by Google instead of your domain. What's the outcome of this? Are you using any DMARC reporting tools like EasyDMARC or DMARCician? Would be interesting to see whether they classify this as non-compliant. From my perspective, if the email is properly signed with a key that is published in your domain's DNS record, it should be fine, regardless of the domain name provided in the header.

No, sorry for the misunderstanding. DMARC (with a relaxed policy) will check out fine even if only DKIM aligns. If DKIM aligns, but SPF doesn't, DMARC is still good. If both DKIM and SPF don't align, then DMARC is red.

Thanks for the clarification, that makes sense. I tried a few different reporting tools and DMARC is showing as non-compliant. Even though DKIM itself "passes," the google-signed DKIM domain doesn't match the "from" alias domain, which I assume is what we're talking about re: alignment.

Thanks. Unfortunately, I've had to explain this to five support reps already, and the issue seems to be going in circles without any escalation. But I'll try what you suggest before possibly changing this alias to a secondary/primary domain. Really appreciate your help!

i notice you have said it is a legacy free account, so I wonder if that may be the issue. Since there is no support available for these legacy account, I also wonder how to managed to open a ticket with support?

sadly most of the support agents are clueless and don't even know how their own system works, it all went downhill after the support was outsourced to India. They give out bad and wrong advice all the time.

To your point, i agree with the struggles on getting any functional support sometimes, it would be phenomenal, if we all had access to a directory to escalation managers, from different locations (there are some that are located in Japan or the Philippines i believe), for when we have a extremely urgent support request, to make it easier to actually get support and follow up, as partners acting, or becoming our clients liaisons.

I am a partner/reseller, and it's no better for me. Partner support is even worse, they take weeks or months to reply and are less help than 3 colorblind hedgehogs in a bag. It is not even possible to speak to them on the phone, not even tech support can contact partner support.

I have the same scenario with the primary and secondary domains and the envelope from and the header from mismatching. I was able to get the headers aligned by updating the user account and setting the domain for the users email account to the secondary domain.

We are still awaiting contact from the Google team in hopes of finding a solution to the SPF alignment issue. We have discovered that some of our accounts managed by Google, when sending emails to Hotmail/Outlook destinations, are often rated with an X-MS-Exchange-Organization-SCL value of 5. This causes those emails to be directed straight to the SPAM folder.

The current routing settings, in our view, could be enhanced to provide more flexibility and sense, especially for businesses utilizing alias domains. Return path for alias domain emails to the alias domain itself RATHER THEN set default to the primary domain(CORE ISSUE).

We started on one domain, and then started using another domain which we added as our secondary domain. As far as we can see we have everything (DKIM etc) set up correctly.

We frequently find that people we email will reject our emails. because the Return-Path uses our primary domain but we are sending from our secondary domain.

I can email several people at a company, and find that only one of them will reject the email. It basically means that our Google Apps email is unreliable.

It is unbelievable for me that Google cannot just set the Return Path to be the same domain as the sending domain, then the problem is solved.

while the issue in this discussion is not a problem for me, the solution I have given before works fine, the incompetent Google Workspace support have driven me insane now.

They also accidentally suspended by domain which caused a huge number of domino issues, as everything connected to my google account stopped working. All 3rd part apps were no longer connected, all authentication broke, emails started bouncing, which caused my email address to get blocked on all systems which sent out notifications and alerts.

All my google business profiles get suspended.

this affected no only me but every client whose website, GBP or any service I manage.

Note that Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records may take some time to become fully propagated in DNS and therefore the issue may persist for a little while longer after setting these records up.

Customer messages sent to Yahoo/AOL recipients may be bounced with the error "This mail has been blocked because the sender is unauthenticated. Yahoo requires all senders to authenticate with either SPF or DKIM."If you're seeing this error message, please set up SPF ( ) or DKIM ( ) for your sending domain(s). For DKIM, you should set up a record for your own sending domain. You should not rely on the default DKIM key applied by Google (*.gappssmtp.com) to avoid this error.

3a8082e126