How to avoid workspace/gmail emails going into spam folders?

[RaphaelNolens]

Dear @Lauren_vdv 
thank you for the invite to this community.
As you can see here below. Your email and invite got straight into the workspace spam folder

We regularly get feedback from clients, that also our workspace emails are entering their spam folders.  
How to avoid this?  

[kim_nilsson · Accepted solution]

Hi, @RaphaelNolens - the recommendation is to make sure you have set up SPF, DKIM and DMARC for your Workspace domain (SPF & DKIM most important, but don't forget to set up DMARC too), and then do not use third-party email clients (Apple Mail or Outlook), nor allow external (nor internal) services to spoof your users' addresses.

Services that need to send email should do so from a proper existing impersonal address, not spoofing one of your users, and not use a fake address.

[KAM]

I think they are referring to emails FROM GCC going into their spam folder... -KAM

[kim_nilsson]

Yup, but both actually.

Initially about the emails from GCC, but then adding that their own emails are ending up in clients' spam folders.

[kim_nilsson]

So, my advice can be picked up by both the GCC team and Raphael. 🙂

[Jan-Carlos]

Hello!

Funny thing, I searched on easy dmark to find the googlecloudcommunity.com dkim and didn't find any entries:

 

[Jan-Carlos]

Didn't find the entries for google.com either.

It's that normal?

[kim_nilsson]

They must be using another syntax than the one we use. Check MX doesn't run either. Read the comment in the yellow. 🙂

[Jan-Carlos]

Good Point! Now i'm more curious haha.

[nsmithmacktez]

This is because you need to change the selector to Google (assuming the domain is a Google Workspace domain)

[Lauren_vdv]

Hi @RaphaelNolens, thanks for asking! In this case, the email is coming from my individual Google email address. I would click the button in the email, "Report not spam," to mark the email as not spam. To stop a message from being sent to Spam in the future, you can add senders to your Contacts and create filters. More info on how to do this is in this help doc. 

And this help doc provides Google Workspace Admins more info and actions you can take to help prevent valid messages from being marked as spam.  

I hope this helps! 

[RaphaelNolens]

Thanks Lauren
Exactly this is the issue.
Humans using legit individual email accounts to sent perfectly legit emails that end up in spam folders. And actual spam still regularly ends up in inboxes 🤣
I guess the spam AI and technology is still pretty stupid instead of intelligent. 

In our company we have multiple brand names and domains. These domains are configured as an alias.  Maybe this is where it can go wrong?

Getting more specific instructions about what to do regards to DKIM & DMARC would be handy too.

[kim_nilsson]

My first post with links to the support articles about SPF, DKIM and DMARC should be all you need.

Alias domains should be recognised as internal domains for internal emailing, but for external users to know they are correct emails you will have to set up SPF, DKIM and DMARC for them separately.

[nsmithmacktez]

In my review of email headers sent from an aliased domain directly from web-based Gmail, the headers list primarydomain.com as the return path, while the DKIM selector indicates aliaseddomain.com - this results in a misaligned (but verified) SPF and a passing DKIM. As such, it doesn't appear that the SPF record for aliaseddomain.com is even in play when sending from an aliased email. Do you know if there's anything that can be added to the primarydomain.com SPF that will allow it to align SPF properly for emails sent from the aliaseddomain.com? Or is it just that aliased domains by nature can't be SPF aligned, as they don't have actual SMTP servers to align?

[kim_nilsson]

Do you have SPF set up for both domains?

Perhaps change them both to have -all att the end instead of ~all.

[nsmithmacktez]

We do have SPF set up for both domains:
primarydomain.com: 

v=spf1 include:_spf.google.com include:servers.mcsv.net +a +mx +ip4:xx.xx.xx.xx include:spf.mandrillapp.com ~all

aliaseddomain.com:

v=spf1 include:dc-aa8e722993._spfm.asliaseddomain.com ~all

I am unsure why the aliaseddomain.com SPF is set up this way, but the address in this record is a TXT record with the value 

v=spf1 include:_spf.google.com ~all

 It's not clear why the SPF record isn't just set to the above, but it seems to work per SPF checks (MXToolbox, etc)

However, I believe that emails sent from the aliasedomain.com address aren't even looking at the aliaseddomain.com SPF record - they are looking at the primarydomain.com SPF, and the aliaseddomain.com DKIM.

See the attached photos, from MX Toolbox's header analyzer, for an email that is sent from Gmail using the aliaseddomain.com address. (domain names have been edited out).

My question is if it is possible to have an Google aliased domain to pass SPF, and if so, how. (The answer might be that it is not possible, which is acceptable, as I just want to understand the situation). I'm not sure I understand how changing ~all to -all would help.

[kim_nilsson]

-all makes the check more strict, so it should allow less.

SPF for aliasdomain must contain the reference to Google, else it will not be relevant.

Also DMARC should be strict for each domain.

Also you may never have two SPF records for one domain.

Since you don't include the real address to your primary and alias domain, nobody can check the records and see if they appear correct.

[nsmithmacktez]

Thanks Kim - however the goal is to allow the aliased domain to pass both SPF and DKIM, not restrict those emails. I do agree that the aliaseddomain.com SPF record should be fixed, but again, it looks like that record isn't even being looked at it.

My guess is that an aliased domain simply cannot pass SPF, as the domain doesn't have its own SMTP servers.

[kim_nilsson]

That's reasonable.