Alternative email address DKIM and incorrect Return-Path

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:

 

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@secondarydomain.com header.s=ggl header.b=kWE8YvVK;
       spf=pass (google.com: domain of user@primarydomain.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=user@primarydomain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=secondarydomain.com
Return-Path: <user@primarydomain.com>
Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
        by mx.google.com with SMTPS id o20-20020a67dfsdfdfsdfdsfdsfdfdsffd982760vsp.47.2023.01.09.13.39.36
        for <testaccount@gmail.com>
        (Google Transport Security);
        [timestamp]
Received-SPF: pass (google.com: domain of user@primarydomain.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@secondarydomain header.s=ggl header.b=kWE8YvVK;
       spf=pass (google.com: domain of user@primarydomain.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=user@primarydomain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=secondarydomain.com

 

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.



9 130 25.8K
130 REPLIES 130

DMARC is something different to DKIM and won't be configured in Google Workspace, instead you will need to do this at the DNS level. Here is one site that can help you do this: https://easydmarc.com/tools/dmarc-record-generator

Thanks @xyzulu , I've got a DMARC policy defined on both the primary and addon/alias domain DNS records, and seems to have the same alignment issue @pcothenet had as well. Have it set to "v=DMARC1; p=none; rua=mailto:admin@example.com" on each domain (with actual email addresses defined).

What do you see in the message headers (show original)?
For example: 

dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=domain.com 

 

dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Run a check using the real domain here: https://mxtoolbox.com/SuperTool.aspx?action=dmarc 

MXToolbox doesn't show any issues with the DMARC record itself, it seems to strictly be the alignment of the primary vs alias domain (since Workspace addon/alias domains still send email with the primary domain for the envelope).

We have discussed this at length in this thread. If you are sending from an alias domain, your SPF will never align, because your mail-from: header will be different from your from: header (one will show your alias domain, the other your primary domain). This is why some tools will show you that DMARC failed. However, this is just a "soft fail", as in a relaxed DMARC policy SPF alignment is not required if DKIM checks out.

By default, DMARC is using a relaxed policy, unless you manually override this in DNS by setting it to strict. 

In other words: You are fine. 

Hi,
Did you ever solve this issue? How?

I find SPF fails (using secondary domain) but DKIM will pass at least (if setup correctly).

Hi @xyzulu ! Thank you so much for posting your question here and for the continued discussion. Was your issue resolved? If so, would you be able to mark this as solved? If not, please let us know. 

@pcothenet , let us know if you're still having issues after the additional troubleshooting advice from yesterday.

Hi @cryptochrome , @GuibsonPrieto and @ajojose33333344 , thank you so deeply for your help troubleshooting with @xyzulu and @pcothenet ! We truly appreciate your time, effort and expertise!

@KarisaE  It's not really resolved, secondary domains are sending email with the Return-Path of the primary domain still.

This is by design. It can't be fixed. 

The only way to get around this would be setting up an actual, real account in the secondary domain and not use it as an alias. This *should* avoid the return path being set to the primary domain, but I might be wrong. 

I'm sorry to hear that you are still having the secondary domain issue @xyzulu . @cryptochrome , thank you for clarifying that. I personally don't have the answer, but I am happy to double check with some internal Google experts and get back to you here. 

Hi @xyzulu ! I have a response from an internal Google expert (see below). Let me know if you have any questions from there! 

Yes, you can configure the user's primary email address to be on ANY registered (primary or secondary) domain within the workspace tenant. That will have implications around authentication, as the user will then need to sign in as user@secondary.com.

As to the DMARC question in the post, I wanted to clarify how DMARC alignment works. It's correct that SPF alignment won't work here, because the mail from/return path address doesn't match the sender's from address. That's okay, because the DKIM signature does match the sender's from address, so we have DMARC alignment covered through DKIM. This is normal and acceptable within the standard (one or the other must align). Here's more information on how alignment works: https://www.rfc-editor.org/rfc/rfc7489#section-3.1.

It's possible that there are other misconfigurations causing confusion or DMARC failures here, but without actual domain names and non-redacted headers, we don't have enough information to assist. Google support should be able to help with a deeper dive.

No you can't.
Domain aliases are not available when I am trying to change user's primary email address.
And it is not okay, even gmail itself marks such messages as spam, even though it itself had just sent it.

The issue is the returnpath.

Emails sent from a secondary domain alias, show the return path for the primary domain.

It is a bug.

@KarisaE I am sorry but that is not a resolution, you provide the right informations, but if the spf alignement fails with the secondary domain and even the dmarc pass and relaxed policy, when you apply the "quarantine/reject" action, you will sent your emails in spam or blackhole. 

I am in the same situation where our company has changed the company name and need to change the main domain. so I need to contact Google Support for a solution ?

thanks for new advices on this.

There is no real solution ๐Ÿ™‚  What you are seeing is "by design". That's just how SPF, DKIM and DMARC work. The important piece to understand in this situation is this: Even though SPF alignment fails, DMARC still checks out, because the DKIM signature is in place. 

In this situation, your emails should *not* end up in spam folders or quarantines, even when the DMARC policy is set to quarantine or reject. If it does, you have a problem in your setup elsewhere. 

Others in this thread had the problem that they did not fully enable DKIM for the new domain (the Google Workspace admin UI is a bit confusing here and it's easy to miss). 

@cryptochrome indeed, I understand.

but by design, it implies other things. Our company has changed its name. The primary domain is @123.com and we use secondary domain @456.com , right, you can send emails and be dmarc compliant, not full compliant but at least with dkim.  

now when you sent invite from  your agenda/calendar, it always sent from your main domain. I am not able to find a way to change that owner. So, it could be a great option to change the main domain here or rename it, or any other methods.

or maybe I miss something, let me know, 

 

Check out https://support.google.com/a/answer/7009324?hl=en#zippy=%2Cstep-switch-to-new-primary-domain for how to switch to a new primary domain (while leaving the old one as a secondary domain). 

Hope that helps,

Ian

What @icrew said - make your new, primary domain, the actual primary domain. From what I understand, this is the domain your are going to use going forward, anyways, so there is no reason to keep it as the secondary domain in GWS. 

indeed it works now. thanks to all. 

yeah, in my case, I have the dkim dns thing related above, and, don't know why, but our users were using the wrong main domain, so obviously, the "by design" cannot aligned everything. 

So, now, full DMARC compliant, the FROM and "return-path" match. 

thanks again, you make my day. 

 

 

@icrew thanks, but I am not able to do this, an error message appears and as we are Google workspace reseller, it ain't work.

@cryptochrome @KarisaE I think I found the way to change things to make DMARC full compliant. it's weird, I already take that look before, maybe, some updates were made. 

  1. (maybe not required) Change your principal administrator to have the domain name you want under that page: https://admin.google.com/ac/accountsettings?hl=fr_CA  
  2. Go under each users and update the domain name, not as alias, but as main email. 
  3. Sent an email and check the header: the from and return-path will be with the same domain name and the SPF will be aligned. 

 

 

From: redacted <redacted@123.com>
Date: Wed, 17 May 2023 11:23:31 -0400
Message-ID: <CAL5predactedZX85Dw@mail.gmail.com>
Subject: test 11h22
To: redacted@outlook.com
Content-Type: multipart/alternative; boundary="0000000000005dd0b505fbe5462d"
X-IncomingHeaderCount: 13
Return-Path: redacted@123.com

 

 

And I can confirm, now the DMARC is full compliant. 

jsstamour_0-1684337793197.png

 

thanks to all, 

 

If the documented method is not working, maybe ask Google Support for help?

I did in past, but now, my last post shows that work now. thanks, 

So glad to hear the issue was resolved @jsstamour !!!

this is caused by using STRICT mode for your SPF. If you change it to relaxed, then you will no fail authentication, as long as DKIM is properly setup.
I have tested and confirmed this, as I had the same issue. I have written an article explaining it here.

https://domainadmintools.com/dmarc-strict-vs-relaxed-alignment-how-to-fix-spf-alignment-failed/

Hello everyone, We have the same problem mentioned in the messages. We have domain1 (primary) and domain2 (alias). Every time we send an email from domain2, the return-path is domain1. We have DKIM configured and activated on the Google Workspace side. The same goes for the DNS settings. We have SPF records for both domains set to relaxed mode. And yet, we are still facing this problem. It's hard for us to believe that they said here that it's resolved by simply "activating" authentication on the Google Workspace side. I repeat, both domains have their records activated and working properly, both in DNS and in Workspace. Every email we send shows up as FAIL, except for the first two, which always pass. This means that our clients receive the emails in the SPAM folder. We have conducted numerous tests by sending emails to external providers, and a large majority of them end up in the SPAM folder. We have contacted Google support, and their configuration guides for SPF/DKIM/DMARC are very nice and pleasant, but they don't solve anything. Any other ideas?

Ugh, no... you're not alone. Mine are also correct from what I can tell and all activated, DNS checks and SPF authentication checks within Google Admin all pass; but emails still get flagged the same way. I've just about given up on it for a bit in hopes that others with the same issue and more drive can get it resolved. ๐Ÿ˜›

Spf will always fails on secondary domain due to return path, but it will
pass dkim authentication as long as you have this enabled, which is is all
that is required as long as you have your dmarc also set to relaxed mode
for spf, then it will also pass dmarc as well since this only requires dkim
authentication to pass.

As stated in my earlier reply this is how i have it setup and it works fine.


@jsstamour wrote:

 

  • (maybe not required) Change your principal administrator to have the domain name you want under that page: https://admin.google.com/ac/accountsettings?hl=fr_CA  
  • Go under each users and update the domain name, not as alias, but as main email. 
  • Sent an email and check the header: the from and return-path will be with the same domain name and the SPF will be aligned. 

 


@JosePerez  those are my steps I did to align the "returnpath" and "from" for a specific domain (even with multiples domains). it works for me and get my dmarc full compliant. 

 

@michaelkatzman your issue seems at another level, check your dmarc report to get more details. 

 

Thank you for the responses.
We hope to resolve this somehow.
The solution we found is to separate the domains so that each one has its own return-path,
but that implies more expenses in the area and for now, we cannot afford another expense in Google Workspace.

We have also tried adding functions like include or redirect to the SPF record, but it still fails.

Thank you very much again to everyone.

Did you check the link/instructions I sent you previously?

Sorry, Monday first thing, I'm going to give it a try.
I have to share the information with my colleagues.

Very informative thread - thank you! I've been following all of these instructions to get my alias domain in good shape. However, I can't get the DKIM header to display my alias domain properly (as mentioned previously, this is needed for alias DMARC authentication, since SPF alignment won't work).

Here's my situation: I set up DKIM for my alias domain, making sure to follow all of the instructions for generating the key in Google Workspace. I added the key to my DNS records (GoDaddy), and made sure workspace is authenticating DKIM (the status says: "Authenticating email with DKIM."). However, any receiving email header continues to print something like "d=***-com.20221208.gappssmtp.com," when it should be displaying the domain (i.e. ***.com).

I've tried so many things to make this work, including:

  • Experimenting various selectors, including "google" and "mail"
  • Trying both 2048 vs. 1024 bits (and also making sure my DNS record isn't being truncated)
  • Ensuring that SPF, DKIM, and DMARC are all working for my primary domain (they are)
  • Waiting 48 hours on most of these iterations (though I know in practice it shouldn't take this long)

One last thing: I had previously set up Wix nameservers in GoDaddy for my primary domain, and Google MX records are set up in Wix. I'm not sure why this would make a difference... as I said previously, primary domain (spf/dkim/dmarc) is working fine, and my alias domain has it's own DNS setup. This could be the culprit, but I'd rather rule out any other problem before modifying the primary domain nameservers.

Any ideas of what could be going wrong? @cryptochrome ? Would greatly appreciate any advice!

 

 

 

What is the actual problem, precisely? All I can see from your message is that some header (not sure which one) is displaying something.gappsmtp.com where you assume it should be displaying your own domain name. 

What outcome do you expect and what outcome do you get instead?

As a reminder: DMARC will check out ok even if SPF and DKIM are not fully aligned, as long as your DKIM signature is verifiable and correct and your DMARC policy is set to "relaxed" (which is the default). 

It doesn't really matter what some random headers contain, as long as this checks out. 

As I explained previously, the return path cannot be changed, period.
But the issue is likely caused by using STRICT mode for your SPF. If you change it to relaxed, then you will not fail authentication, as long as DKIM is properly setup.
I have tested and confirmed this, as I had the same issue. I have written an article explaining it here.

https://domainadmintools.com/dmarc-strict-vs-relaxed-alignment-how-to-fix-spf-alignment-failed/

Thanks @russ12 - The issue I'm having isn't with the return path, though, it's with the DKIM signature (sorry, I accidentally replied on a new thread, but you can see more details below). Already had the settings as relaxed (i.e. "adkim=r; aspf=r" )

sorry I didn't read it properly.

WIX is notorious for having issues with their system, their DNS editor is also very limited.
So I would suggest using mxtoolbox.com to verify your DKIM record has been saved correctly EXACTLY as per the google admin instructions and is returning the correct response.

Thanks @russ12. Yep I did those inspections (and it also works for the primary domain). That said, I agree there could be something wonky going on with WIX DNS, so I may migrate the primary domain off those nameservers to see what happens.

Top Labels in this Space
Top Solution Authors