Is Your Google Workspace DKIM Setup Broken?
Deploying and configuring DKIM on Google Workspace is a two-step process, and administrators often skip the second step. In such cases, DKIM and DMARC function properly, and email delivery is not impacted either. However, DKIM doesn’t authenticate emails using your custom domain.
Let’s see what these two steps are and how you can avoid breaking up the Google Workspace DKIM setup.
Step One of Google Workspace DKIM Setup
Start by generating a pair of cryptographically secured public and private keys. Then, use your DKIM record to set up DNS for the domain to serve the record under google._domainkeys.example.com, where you have to replace example.com with the Google Workspace domain.
Image sourced from fastercapital.com
Many administrators mistakenly believe that the DKIM setup is complete after the first step. However, it’s crucial to understand that this step alone doesn’t enable Google to sign emails using your domain as the signing domain. To achieve this, the second step is essential.
Step Two of Google Workspace DKIM Setup
Create a DKIM record, add it to your DNS, and wait for the changes to propagate. After that, you must revisit the Google Workspace and enable DKIM by clicking the ‘Start Authentication’ button.
What About DMARC?
Most domain owners or admins don’t realize that Google is not signing emails with their domains, as DMARC works fine. Malfunctioning of DMARC is one of the signals for erroneous DKIM and SPF settings, but in the case of Google Workspace, this indicator doesn’t blink.
Two reasons why DMARC works fine in this condition are-
- SPF records generally include the _spf.google.com domain, which is why emails pass SPF authentication checks.
- By default, Gmail uses the sender address on the ‘Envelope-From header,’ which validates that the ‘Envelope-From’ and ‘From’ domains are the same.
Because of these two reasons, the SPF gets aligned, even if DKIM doesn’t, and to clear DMARC checks, only one of the protocols has to pass.
Why Should You Fix the Issue?
Some specific Google applications don’t use your domain in the ‘Envelope-From’ header of the outgoing emails. Instead, they use your domain in the ‘From’ header, and a Google domain is used in the ‘Envelope-From’ address.
In this case, SPF alignment won’t happen from a DMARC perspective. As a result, emails sent from these applications will fail DMARC checks unless DKIM is configured and enabled in Google Workspace.
You may understand this better with the Google Calendar invite example, where even if the emails carry your domain in the ‘From’ address, the ‘Envelope-From’ line points to calendar-server.bounces.google.com.
Given this setup, SPF alignment always fails, leaving DMARC dependent solely on DKIM for a pass. However, if DKIM is not initiated, DKIM alignment will also fail, resulting in DMARC failure. Should this occur with a strict DMARC policy (e.g., p=reject), these confirmation emails will be outright rejected.
What Happens if you Start DKIM Authentication on an Existing Domain?
If you properly follow the steps mentioned above, there won’t be any adverse effects. However, to be safe, it’s better if you change your DMARC policy to ‘quarantine’ instead of ‘reject.’ This way, instances of false positives won’t dump your conversations outright.
