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.

russ12

have you permed tests with external tools to check the email verification?

such as https://www.mailgenius.com/

just having "d=***-com.20221208.gappssmtp.com," in the headers doesn't mean the email failed DKIM tests, all it needs is the DKIM signature to pass.

maxkretchmer

I did indeed. I also just tried the service you referenced. DKIM passes, it's just that it's out of alignment, so DMARC is not compliant.

maxkretchmer

Hi Everybody - Thanks so much for your responses below. In case it helps anyone else in a similar position, I was able to solve the problem, after a month+ of haggling with Google support.

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.

Beware which admin account you use when logging into the console!

cc: @cryptochrome @russ12 @jsstamour

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.

alterhit

100% CONCUR WITH THIS. The Return path is the issue and the reason why @xyzulu created this thread.
The SPF, DKIM and DMARC conversations going on parallelly are pointless in relation to this issue, whilst giving value to other user issues.

Simply - why can alias2@secondarydomain.com simply not have a return path back to alias2@secondarydomain.com

the return path will show user1@primarydomain.com

utterly ridiculous and it is a BUG and not by design.

russ12

The solution I provided previously works perfectly for all my secondary
domains.
None of them are failing authentication checks.

KAM

@russ12 can you recap your solution? The problem we have is accounts with aliases and send mail as the secondary domain doesn't work because the wrong DKIM is used. It sounds like you are saying there is a way to add it and then contact support to fix something only they can fix? -KAM

russ12

I did not have to contact support, my secondary domains are using the
correct dkim after I set it up.

alterhit

No matter what you do, the RETURN PATH will always show the primary domain.
DKIM and SPF can be set correctly and DMARC policies will work. And the email will generally find its way into inboxes.

But the RETURN PATH is always going to be the primary.

This Russ guy keeps going on about DKIM without understanding the problem, I imagine to improve status.

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.

Alternative email address DKIM and incorrect Return-Path