Re: Alternative email address DKIM and incorrect R... - Page 3

xyzulu · 01-09-2023 02:47 PM

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:

Received-SPF: pass (google.com: domain of user@primarydomain.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;

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:

google.com is authorized to send on behalf of secondarydomain.com, however it looks like SPF is still failing DMARC’s alignment test. DMARC looks at the Return-Path of a message to make sure the domain there matches the domain in your From address. If the Return-Path path doesn’t match your From address, those messages will fail DMARC’s SPF alignment test. Check with this source because you may need to set up a custom Return-Path.

JosePerez

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

maxkretchmer

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).

JosePerez

Well, thank you very much for the information. We always log in to Google Admin with the A account.

I'll discuss the process with my colleagues, to see if we can try GENERATING a new DKIM record.

Regards

russ12

yes this is a known issue, which I also found out the hard way,

Please make sure you harass them to report this as a bug to their dev team.

--

Russ Michaels
IT Jedi Master
phone: 01843 808480 <441843808480>
website: michaels.me.uk
Join my mailing list
<>
<>
<>
<>
[image: skype:russmichaels?chat]
IMPORTANT: The contents of this email and any attachments are confidential.
It is strictly forbidden to share any part of this message with any sith
lord or member of the galactic empire, without a written consent of a
member of the Jedi Order. If you received this message by mistake, please
use the force to let me know or contact your local Jedi Council
representative.

maxkretchmer

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):

Expected: ***.com

Actual: ***-com.20221208.gappssmtp.com

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.").

As a result, DKIM is not aligning with the "from" email, leading to (what I think is) failure in DMARC, even though I don't expect SPF to align:

@cryptochrome Are you saying that relaxed DMARC should still check out even if **BOTH** SPF and DKIM are unaligned?

jsstamour

if you have "Actual: ***-com.20221208.gappssmtp.com" you have something wrong with the custom dkim signature and authentication, be sure the authentication is enabled for ALL your domains you want that,.

be sure, from your dns entries that your dkim txt record has a valid format.
wait 24hrs before doing new test, just in case.

good luck .

@maxkretchmer wrote:
Are you saying that relaxed DMARC should still check out even if **BOTH** SPF and DKIM are unaligned?

on your dmarc report, you will always have the "check" for both spf and dkim, and then you will see if those are aligned or not. then make adjustement, if needed.

maxkretchmer

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).

GW:

...

DNS:

Open to the possibility, however, that maybe it doesn't matter at the end of the day for DMARC (per @cryptochrome ) -> if that's the case, I may not waste any more time on it

maxkretchmer

Also, FWIW, it looks like there's an ongoing ticket for this, so possible this is just a bug on the Google side? https://issuetracker.google.com/issues/201556406

jsstamour

be sure to not use an alias domain , but a primary domain.

if you want to use the dkim on a "alias domain" follow this : https://webapps.stackexchange.com/questions/84859/how-can-i-send-a-dkim-signed-email-from-a-domain-a...

cryptochrome

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.

@maxkretchmer wrote:
Are you saying that relaxed DMARC should still check out even if **BOTH** SPF and DKIM are unaligned?

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.

maxkretchmer

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.

russ12

if the wrong DKIM signature is being used on the alias, then you are going to have to contact support for that as they are the only ones who will be able to fix that.

the only DIY solution I can suggest is to try deleting and re-adding the alias and do the authentication setup again

maxkretchmer

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!

maxkretchmer

@KarisaE Any chance you can help with this? I think it's related to the issue here: https://issuetracker.google.com/issues/201556406 But unfortunately there's no way to know for sure, as support agents refuse to escalate this

russ12

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?

You could try upgrading the account to a paid plan and see if that fixes anything, then you can downgrade it back to free again afterwards.

maxkretchmer

It's a paid account, unlike what's in that bug report...but it is G Suite legacy, that could be connected

KarisaE

Hi @maxkretchmer , I'm very sorry for my delay - I am in a new role and am just seeing this. Is this still an issue you are experiencing?

russ12

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.

You have to keep arguing and insist that the case is escalated to a senior engineer that actually understands the issue.

GuibsonPrieto

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.

russ12

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.

anoopjohn

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.

JosePerez

Hello everyone,

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.

Has anyone had any experience with this Microsoft filter?

Thank you very much.

russ12

this is usually as a result of you not having your email authentication setup in the past, which resulted in you ending up on Microsoft internal blacklist.

the best thing to do in this case is to start doing inbox warmup to improve you deliverability.

JosePerez

Thanks for the response.
We have DKIM / SPF / DMARC successfully configured.
The problem is about some company accounts that come to SPAM.

Not the whole domain

russ12

I didn't say you do not have those things setup, please read my response again more carefully.
Simply setting them now cannot fix problems caused in the past.

JosePerez

You're right.

dpk89

Dmarc Relaxing the policy is not an ideal solution

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 are optimistic about this discussion and look forward to potential solutions. We hope that this feature could be considered for implementation in near future !! looking forward for solution.

GCalTools

Thank you for this, finally passing all checks after setting up DKIM for the alternate domains! Confusing because it was saying DKIM Pass and DMARC Fail... but this is indeed the solution.

russ12

if anyone is still struggling with getting their email authentication sorted and would like it done for you, feel free to get in touch.

https://michaels.me.uk

xyzulu

OP here... this issue still persists. A summary.. since many replies here seem to be heading down some other rabbit holes:

"DMARC looks at the Return-Path of a message to make sure the domain there matches the domain in your From address. If the Return-Path path doesn’t match your From address, those messages will fail DMARC’s SPF alignment test. Check with this source because you may need to set up a custom Return-Path." (taken from somewhere else I can't remember)

The behaviour still has not changed since my original post. That being said, DMARC does technical pass (if you have DKIM configured correctly) despite the SPF check failing. To "fix" this, Google would need to do something like Postmark do, see: https://postmarkapp.com/blog/how-dmarc-and-a-custom-return-path-work-together

Take home: I don't think Google are going to adjust this/help us here BUT for most people this is probably not a deal breaker.

PS you will want to avoid aspf=s in your DMARC policy if you are facing this exact issue.

Major_Grooves

Just to add - we have an identical problem.

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.

Major_Grooves

We have been advised today to update our DMARC policy for our secondary domain from "reject" (which is best practice) to "none". I will update here if this seems to solve the problem.

russ12

setting your dmarc policy to none basically disables it and says "allow any spoofed email form my domain that fails authentication to be delivered to the recipient"

scheived

This is a big problem as gmail doesn't allow a different from domain as the reply-to domain to pass dmark.

russ12

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.

It took me weeks to find and fix all the issues this caused.
Google didn't care and have refused to pay me any compensation for their mistake.

So I have now started using FastMail instead, and am now offering this to my clients instead.

Alternative email address DKIM and incorrect Return-Path