We’ve seen this happening to a few domains hosted on Google Workspace: DKIM is properly set up on the domain, email is okay, and DMARC passes.

All seems fine, except that DKIM is not authenticating emails “From” the user domain.

Because Gmail works, people think that DKIM is doing the right thing. But it is kind of not.

The reason is simple: setting up DKIM on Google Workspace is a two-step process. Some people do the first step, but forget to carry on with the second step.

Google Workspace DKIM setup – step one

The first step is to generate the DKIM public and private keys, grab the DKIM record, and configure DNS of the domain to serve the record under google._domainkeys.example.com (substitute example.com for the Google Workspace domain).

Apparently many people do this step and stop there.

They don’t realize that if they just do that, Google still won’t use DKIM to sign emails using their domain as the signing domain.

Google Workspace DKIM setup – step two

After generating the DKIM record, adding it to your DNS zone, and waiting for the changes to propagate, you need to go back to Google Workspace for the last step: actually enable DKIM.

That’s true. Just generating the DKIM record does not automatically enables DKIM on Google Workspaces.

You can enable DKIM by clicking the “Start Authentication” button.

But DMARC isn’t failing…

True. DMARC won’t fail if you forget step two with emails sent using Gmail.

Most people are concerned with deliverability of their emails. Since Gmail works, this issue passes unnoticed for some time, and until they try to implement DMARC.

Here’s the reason why DMARC “works” in this scenario:

1. Usually people configure SPF correctly, by including _spf.google.com in their SPF records, and
2. Gmail uses the sender address on the “Envelope-From” header

Item one is all you need to get a pass from SPF. Item two guarantees that the domain is the same in both “Envelope-From” and “From” headers.

So what happens is: DKIM is not aligned, but SPF is. That’s why you get a pass from DMARC.

That's why “it works”.

So why does it matter?

Some Google applications do not send emails with your domain on the “Envelope-From” header.

They will use yout domain on the “From” header, but “Envelope-From” will still have a Google domain.

SPF will never be in alignment in those cases, from a DMARC point of view. Therefore, emails from those applications will not pass DMARC checks, unless you configure and enable DKIM on Google Workspace.

One classic example is Google Calendar invitation replies. Those emails will have your domain in the “From” line, but a “Envelope-From” pointing to calendar-server.bounces.google.com. SPF will always fail alignment in this case, therefore DMARC can only rely on DKIM to get a pass. However, if DKIM has not been started, DKIM alignment will fail too, which will make DMARC fail. If this happen and you have a strict DMARC policy (i.e. p=reject), those confirmation emails will simply be rejected.

What’s the impact of starting DKIM authentication on an existing domain?

If you followed all the instructions to set up DKIM on Google Workspace carefully, the impact should be none.

To be on the safe side, we recommend clients to change their DMARC policy to something less strict, such as p=quarantine, and/or perhaps sample emails using pct=X, and use DMARC Record Explorer to monitor their records for a couple weeks. The objective is to try to spot any failing service and adjust.

After another couple weeks without any issues, they can return to more strict DMARC parameters (p=reject and/or pct=100).

For more information about how to enable DKIM on Google Workspace, see Google’s Turn on DKIM for your domain page.