Google Workspace secondary domain invalid SPF

Google Workspace secondary domain invalid SPF
Photo by Pawel Czerwinski / Unsplash

Google Workspace (formerly GSuite) is Google's "Secure Online Productivity & Collaboration Tools" paid product used for (amongst other things) sending emails using a non-Gmail domain - a key benefit over (free) Gmail.

With Google Workspace you can add multiple domains. However, it seems this has some limitations when it comes to correctly implementation of SPF/DKIM.

You specify a primary domain when creating your Google Workspace account. Additional domains can be added as aliases or secondary domains. More information on the differences here.

It seems that , whichever email address/domain you select when sending an email, the Return-Path in the email header is always stated as the primary domain.

The image above shows the message headers of an email sent from paul@domainsafe.au.

To view the full email message headers in Gmail:
1. From a browser, open Gmail.
2. Open the email you want to check the headers for.
3. Next to Reply , click More. Show original. In a new window, the full header shows.

My Google Workspace account uses the primary domain name photography-courses.com.au (an old business that no longer exists).

When I send an email from paul@domainsafe.au (a secondary domain in my Workspace account) the header includes the smtp.mailfrom value info@photography-courses.com.au.

So why does SPF fail?

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.

In my case, the Return-Path does match the smtp.mailfrom address (both info@photography-courses.com.au), but the smtp.mailfrom and header.from are not the same.

According to Valimail's article "How can I tell if an email is passing SPF?":

...check if the visible header.from is aligned with the smtp.mailfrom (return path/envelope from)...they both need to be your domain (the domain the email in sent on behalf of).

The misalignment occurs between the Return-Path domain, photography-courses.com.au, and the header.from domain, domainsafe.au, which is the domain name associated with the sending email address.

The solution? A custom Return-Path, which you can't configure in Google Workspace.

The alternative solution...according to this article from DMARCdigests, Google only uses the primary domain it detects that the DMARC policy is set to 'none' (do nothing). If the DMARC policy for the secondary domain is set to the stricter quarantine or reject options, they will update the sending domain smtp.mailfrom to match the header.from/sending email address.

I've updated my DMARC policy and will report findings when they're available.

Note that this isn't a huge problem. DMARC only requires either SPF or DKIM to pass in order to be authenticated. It seems Google just assumes your DKIM is set up properly (and it is), so this shouldn't affect deliverability.


Update:

It didn't work...until I changed the primary email address of my user. Now the smtp.mailfrom is my primary domain, domainsafe.au. But it does seem that Google Workspace will now use that domain name as the smtp.mailfrom for all my other seconday domains.

Time to move to Microsoft, maybe?