Guides

Google Workspace DKIM not authenticating: fixes

4 November 2026

When Google Workspace says DKIM is not authenticating, one of four things is usually true. The TXT record is not in DNS where Google expects it, the key was cut short or changed on the way in, you have not clicked Start authentication, or not enough time has passed. Google says it can take up to 48 hours to start working. Check the record with a DNS lookup first, because that tells you which of the four it is.

Google’s own setup is covered in our Google Workspace DMARC guide. This page is for when the status will not turn green. If you would rather hand the DNS check over, a $129 Snapshot reads your google._domainkey record and the rest of your authentication records and tells you what is wrong.

What working looks like

In the Admin console, go to Apps, Google Workspace, Gmail, then Authenticate email, and pick your domain. Google’s DKIM setup page says that when DKIM is working, the status reads Authenticating email with DKIM. Anything else means one of the steps is incomplete.

The steps, in order, are:

1. Generate the key in the Admin console. Google says to wait 24 to 72 hours after turning on Gmail before you do this, and that generating the key needs super administrator access.
2. Add the TXT record at your DNS host.
3. Click Start authentication.

Most problems come from doing step 3 before step 2 has taken effect, or from step 2 going slightly wrong.

Step one: look the record up

From a terminal:

dig TXT google._domainkey.example.com +short

Replace example.com with your domain, and google with your selector if you changed it. Google’s DKIM troubleshooting page suggests the Dig tool in the Google Admin Toolbox if you prefer a browser. Its tip: when you look up the record there, add a period and your domain to the selector, as in google._domainkey.example.com.

You will get one of three results.

Nothing comes back

The record is not where Google looks. Check:

• The name. Many DNS hosts add your domain to the name for you. If you typed the full google._domainkey.example.com, the record may now sit at google._domainkey.example.com.example.com. Google’s troubleshooting page says not to add the domain again to the record name. Look up the doubled name to confirm, then fix the record.
• The DNS host. If your domain’s nameservers point somewhere other than the panel you edited, the record is in a zone nobody reads. Run dig NS example.com +short and edit the zone at the host it names.
• The record type. Google’s key is a TXT record. A CNAME or a "DKIM" record type that your host offers may not produce what Google expects.
• Time. If you saved it in the last hour, wait and try again.

A value comes back, but it does not match

Compare the value with what the Admin console shows, especially the first and last ten characters. Google’s troubleshooting page says a key can be truncated, or have its parts out of order, at the DNS host. Common causes:

• The 255-character limit. A 2048-bit key is too long for one TXT string. Google says that if your host has this limit, you should split the key into several strings, put each in quotes, and enter them one after another in the same Value field. Do not create two separate TXT records.
• Quotes inside the key. If your host adds quotes for you and you added your own, the published value may contain literal quote marks.
• Pasted spaces or line breaks. A key copied through an email or a document can pick these up.
• An old key. If you generated a new key in the Admin console after publishing the first one, DNS still has the old value. Replace it with the current one.

Google gives two other options for the length problem: use a 1024-bit key, or ask your host whether it accepts longer TXT records. Its setup page recommends 2048-bit where the host supports it. Our guide to adding a DKIM record shows what a split value looks like.

The value matches

Then DNS is right, and the console needs to catch up.

• Click Start authentication. Google’s troubleshooting page lists a "not authenticating" status as the case where you open the Authenticate email page and click Start authentication.
• Wait. Google says the console may keep showing a DNS warning for up to 48 hours even after a correct setup.

When the status is green but messages still fail

A green status means Google is signing. It does not prove every message passes at the other end. Send a message from the account to a personal Gmail address and use Show original. If DKIM shows FAIL, Google’s troubleshooting page lists these causes:

• The message changed after signing. An Authentication-Results line that says "body hash did not verify" means something modified it in transit. Google points to outbound gateways that add footers or disclaimers, and to forwarding services.
• Too many signatures. Gmail checks only the first five DKIM signatures. If a gateway adds several of its own, the Google signature can fall outside that set.
• The length tag. If you send through a non-Google system as well, Google says not to use the DKIM l= tag in outgoing messages.

Google also suggests sending to a personal Gmail address to rule out the receiving server, and using the Admin Toolbox Messageheader tool to read the headers.

Other services on the same domain

The Google key signs only mail that leaves through Google. Your newsletter platform, store, and help desk each need their own DKIM selector on your domain. A Gmail bounce with 5.7.30 on a campaign does not mean the Google key is broken. Our guide to Gmail authentication bounces explains how to tell which sender failed.

Changing selectors or rotating keys

If you change the selector prefix, Google publishes the key under the new name, so the old google._domainkey record no longer matters. Add the new record before you start authentication with the new key. When you replace a key, leave the old record in place for a few days so mail already in transit still verifies, then remove it.

After DKIM is authenticating

With SPF including _spf.google.com and DKIM authenticating, Google’s mail is ready for DMARC. Google’s DMARC setup page suggests waiting 48 hours after SPF and DKIM before you add the DMARC record. Start at p=none with an rua address and read the reports before tightening.

Sources

• Google Workspace: Set up DKIM (steps, key length, 48 hours, status text)
• Google Workspace: Troubleshoot DKIM issues (record name, character limits, body hash, five signatures, l= tag)
• Google Workspace: Set up DMARC
• RFC 6376: DKIM