How to Set Up DKIM in Google Workspace

Setting up DKIM in Google Workspace is one of the most practical ways to strengthen outbound email trust. When configured correctly, it helps recipients verify that your messages are legitimate, improves deliverability, and makes spoofing harder. 

This guide walks through the setup process, common pitfalls, and how to connect DKIM to SPF, DMARC, and broader email security.

What is DKIM and why does it matter?

DKIM, or DomainKeys Identified Mail, is an email authentication method that lets a sending system attach a cryptographic signature to outbound email. The recipient’s mail system uses the public key published in DNS to validate the DKIM signature and confirm the message was authorized by the sending domain and was not altered in transit.

There’s a few reasons why DKIM matters for security and email authentication:

• Helps verify message integrity
• Strengthens trust in your domain’s email
• Supports better inbox placement and deliverability when paired with SPF and DMARC

See how Mimecast DMARC Analyzer can simplify monitoring, reporting, and enforcement across your domains.

Prerequisites before setting up DKIM

Before you start the Google Workspace DKIM setup, make sure the basics are in place. Google’s setup flow assumes the domain is already active for Gmail and that the administrator can make changes both in Workspace and at the DNS layer.

You should confirm:

• Domain verification is complete in Google Workspace.
• You or a teammate has access to the domain’s DNS provider or registrar.
• The team handling setup can work with DNS records, including a new text record, selector names, and TXT values.
• Gmail is already activated for that domain in Google Workspace before trying to generate the DKIM key.

If Gmail was only recently enabled for the domain, Google may not let you generate the DKIM key immediately in the Google Workspace admin console. This waiting period is normal and can delay the next step.

It also helps to review your outbound mail path first. DKIM can break if messages are modified after signing. That can happen when outbound gateways, secure mail tools, or routing services change headers or message bodies after the signature is applied. 

After confirming that you have the necessary requirements, you can now proceed with setting up DKIM in Google Workspace.

Step 1: Generate the DKIM key in Google Workspace

The first step is to generate the DKIM key in the Admin console. In Google’s documented flow, go to:

Admin console > Apps > Google Workspace > Gmail > Authenticate email

From there, select the correct domain before generating the record. This matters in environments with multiple domains or subdomains, because the DKIM settings are domain-specific.

When you click Generate New Record, Google asks you to make two key choices:

• DKIM key bit length: Google recommends 2048-bit if your domain provider supports it; 1024-bit is the fallback for hosts with TXT-length limitations.
• Selector: Google uses the default selector Google, which is usually fine unless that selector is already in use. If it is, choose a prefix selector or another clear, unique selector instead.

Step 2: Publish the DKIM TXT record in DNS

After Google generates the key, you need to add the DKIM DNS record at your domain host. Google provides two important values:

• Hostname, such as Google._domainkey
• TXT value, which begins with v=DKIM1; and includes the public key (p=)

Add that TXT record to the DNS management area of your registrar or DNS provider and save it. This is the actual DNS record that receiving systems will query during DKIM authentication.

If your provider supports multiple DNS TXT record fragments for long values, follow its formatting rules exactly. If not, the record may publish incorrectly even if the text looks right in the console.

Step 3: Start DKIM authentication in Google Workspace

Once the DNS entry is published, return to the Google admin console and go back to:

Apps > Google Workspace > Gmail > Authenticate email

Select the same domain and click Start authentication, but only after the DNS record has actually been added. Google’s documented success state is that the page changes to indicate the domain is Authenticating email with DKIM.

It’s normal for the console to show a warning or pending state for a while, even when the DNS update is correct. That delay is often caused by DNS propagation, not by a broken setup.

Step 4: Verify that DKIM is working

Do not assume setup succeeded just because the record is published. It’s equally important to test live mail flow.

To do this, send a test message from the configured account to a separate Gmail or Google Workspace inbox, not to the same sender mailbox. Google specifically notes that you can’t verify DKIM by sending yourself a test message.

Then open the received message in Gmail and use Show original to inspect the headers. You want to confirm that DKIM passes for the expected selector and domain. This is the most direct way to validate live signing.

The fastest verification methods are:

• Checking the message headers in Gmail
• Running a DNS lookup to confirm the selector’s public key is visible

A DKIM record checker can also help confirm the record is published, but it should be treated as a supplement, not a substitute for header verification. A visible DNS record alone does not prove that live email is actually being signed correctly.

Step 5: Troubleshoot common Google Workspace DKIM issues

The most common causes of DKIM problems after setup are straightforward:

• DNS propagation delay
• Wrong hostname or selector
• Truncated TXT values
• Selecting the wrong domain in the admin console

Even when the DNS record is correct, DKIM can still fail if something modifies the message after Google signs it. That includes changes made by gateways, filtering tools, or secure mail platforms. In those cases, the problem is not the record itself; it is the message path.

This gets more complex in enterprise environments where third-party platforms send on behalf of the same domain. Google Workspace mail signing only covers mail sent through Google’s systems. If a CRM, marketing platform, or ticketing tool also sends from that domain, it may need its own different selector, its own signing configuration, and its own alignment review.

Step 6: Connect DKIM to SPF, DMARC, and broader email security

DKIM is an important control, but it is strongest as part of a layered strategy. Google recommends setting up SPF, DKIM, and DMARC together for your domains. Those methods work as a stack:

• DKIM signs the message
• Sender Policy Framework validates whether the sending infrastructure is authorized
• DMARC in Google applies policy and reporting when authentication fails

That means your Google workspace DKIM project should sit alongside your SPF record and DMARC record , not apart from them. If you use Google as a sender, Google’s SPF guidance commonly references an SPF include such as include:_spf.google.com; just make sure your final SPF syntax is correct for your environment.

When implemented together, these controls reduce spoofing, improve email deliverability, and help build trust in executive and employee email. They also support human-risk reduction by making impersonation and suspicious emails harder to deliver successfully.

Set up Google Workspace DKIM to strengthen trust

The setup steps for Google Workspace DKIM are not complicated, but they do require careful coordination across Workspace, DNS, and mail flow. Generate the key in the Google Workspace Admin console, publish the TXT record correctly, start authentication only after DNS is live, and verify results through live header inspection.

Most importantly, treat DKIM as part of a broader email security strategy. Each sending domain needs its own valid configuration, and the best long-term results come when DKIM is combined with SPF and DMARC for stronger protection, stronger trust, and more reliable deliverability.