How to enable DKIM in Google Workspace

29 May 2026 · 12 min read

When you create a Google Workspace domain, Gmail starts sending your mail straight away, and it looks like everything is handled for you. It is not. By default Google signs your outbound mail only with a generic key tied to a Google-owned domain, which does nothing for your own domain's authentication. Until you generate a DKIM key, publish it in your DNS and switch on signing in the Admin console, your messages carry no DKIM signature that aligns to your domain, and that gap quietly undermines DMARC, deliverability and your protection against spoofing.

This guide is the focused, end-to-end version of that one task: generating a 2048-bit DKIM key in Google Workspace, publishing the DNS record correctly, and turning on signing so every message you send is verifiably yours. It assumes you control your domain's DNS, wherever it lives, and that you have a Google Workspace super administrator account. The whole job takes about ten minutes of clicking and one short wait for DNS to propagate. The reason people get it wrong is almost never the clicking; it is the DNS record, so that is where most of this guide concentrates.

If you want the broader walkthrough that places DKIM alongside SPF and DMARC for a Google Workspace domain, read /blog/dmarc-google-workspace afterwards. This article zooms in on DKIM alone.

What DKIM actually does, in one paragraph

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to the headers of every message you send. The signature is created with a private key that lives on Google's sending infrastructure, and it can be verified against a public key that you publish in your own DNS. When a receiving server like Yahoo or Microsoft gets your message, it fetches your public key from DNS, recomputes the signature over the signed headers and body, and checks that the two match. If they match, the receiver knows two things: the message genuinely came from a system holding your private key, and the signed content was not altered in transit. That is the whole point. For the deeper mechanics, see /blog/what-is-dkim and the DKIM glossary entry.

The reason this matters for a Google Workspace domain specifically is alignment. DMARC passes a message if either SPF or DKIM passes and the passing identifier aligns with the domain in the visible From address. Google's default signing uses a selector under a Google domain, so it never aligns to yours. Once you turn on domain DKIM, your selector lives under yourdomain.com, the signature aligns, and DKIM becomes a reliable second leg holding up your DMARC policy. That second leg is what keeps you authenticated when SPF breaks, which it routinely does on forwarded mail. The relationship between DKIM and forwarding is covered in /blog/dkim-alignment-forwarding.

Before you start: the two things that bite people

There are exactly two preconditions worth checking before you touch anything, because both cause confusing failures later.

• You need super administrator rights. The DKIM controls live under Gmail settings in the Admin console, and a normal user or a delegated admin without the right privilege will not see the option to generate a key. If the menu path below does not appear, this is almost always why.
• Your DNS provider must accept a long TXT value. A 2048-bit DKIM public key does not fit in a single 255-byte DNS character string, so it has to be stored as multiple chunks. Most providers now handle this transparently when you paste the value, but a few older control panels do not. Knowing this in advance turns a baffling failure into a five-minute workaround, which we cover in the publishing section.

While you are at it, run your domain through the DKIM checker now, before any changes. If it reports no record at the google selector, you have confirmed DKIM is not yet active and the steps below are exactly what you need. If it reports an existing record, note the selector name so you do not overwrite a working setup.

Step 1: generate the DKIM key in the Admin console

This is the part Google controls. You are asking Google to create a key pair: it keeps the private half on its signing servers and hands you the public half to publish.

1. Sign in to the Google Admin console at admin.google.com with a super administrator account.
2. In the navigation, go to Apps, then Google Workspace, then Gmail, then Authenticate email. The label "Authenticate email" is Google's name for the DKIM panel.
3. If your account has more than one domain, select the domain you want to sign for from the drop-down at the top right of the panel. DKIM is per-domain, so you repeat this whole process for each domain that sends mail.
4. You will see a message saying DKIM authentication is not set up yet, and a button labelled Generate new record. Click it.

A small dialog appears with two choices that matter.

• DKIM key bit length. Choose 2048. This is the value every major receiver now expects, and the longer key is meaningfully harder to attack than the older 1024-bit default. There is no deliverability downside to 2048 bits and a real downside to a key receivers consider weak. The full argument, including the DNS gotcha that pushed some people to 1024 in the past, is laid out in /blog/dkim-key-length-1024-2048. Pick 2048 unless your DNS provider genuinely cannot store the longer value, which is rare now.
• Prefix selector. Google defaults this to google. The selector is just a label that lets you have more than one key in DNS at once, which is what makes painless key rotation possible later. Leave it as google unless you have a specific reason to change it, for example you already use that selector for something else. If you want to understand why selectors exist and how to name them, see /blog/dkim-selectors-explained.

Click Generate. Google now shows you the public key as a DNS record, in two parts:

• A DNS host name (also called the name or hostname), which will be google._domainkey if you kept the default selector. Some control panels want this relative form; others want the fully qualified google._domainkey.yourdomain.com.
• A TXT record value, a long string beginning v=DKIM1; k=rsa; p= followed by a block of base64 characters and usually ending in QIDAQAB.

Leave this Admin console tab open. You are about to copy that value into your DNS, and you will come back here to flip the switch once the record is live. Do not click Start authentication yet. Turning on signing before the public key is published and visible means your mail gets signed with a key receivers cannot find, and the signature fails verification. Publish first, verify, then enable. That ordering is the single most important thing in this guide.

Step 2: publish the public key in your DNS

Now switch to your DNS provider's control panel, wherever your domain is hosted: Cloudflare, GoDaddy, Namecheap, Squarespace, Route 53, your registrar, whoever holds the authoritative zone for yourdomain.com.

Create a new record with these values:

• Type: TXT
• Name / Host: google._domainkey (use the selector Google showed you; if your provider appends the domain automatically, the relative google._domainkey is correct, and the full record will resolve at google._domainkey.yourdomain.com)
• Value / Content: the entire TXT value Google gave you, starting v=DKIM1; k=rsa; p=...
• TTL: leave the default, or set 3600 (one hour). TTL does not affect correctness here.

A few mechanical points decide whether this works on the first try.

Copy the whole value, exactly

Copy from the leading v=DKIM1 all the way to the final character of the base64 block. A common failure is grabbing only the p= portion, or dropping the trailing QIDAQAB, or accidentally including a stray space or line break that the Admin console wrapped for display. The value is a single logical string. If your provider's box shows visible line wrapping, that is just the display; do not insert real line breaks.

The 255-byte chunking problem

This is the issue that causes most 2048-bit DKIM failures, so it is worth understanding rather than just working around. A DNS TXT record is built from one or more character strings, and each individual string can be at most 255 bytes. A 2048-bit public key is longer than that, around 400 to 420 bytes once the v=, k= and p= syntax is included. So it physically cannot live in one string; it must be split into two or more chunks.

The good news is that when a resolver reads a multi-string TXT record, it concatenates the chunks back together with no separator: no space, no comma, nothing. So as long as the pieces are stored as adjacent quoted strings, the reassembled value is byte-for-byte identical to the original key.

What this means in practice depends on your provider:

• Most modern providers (Cloudflare, Google Domains, Namecheap, Route 53 console) accept the full value pasted as one block and handle the chunking for you behind the scenes. You paste, you save, you are done.
• Some older or zone-file-based systems require you to split the value yourself into quoted strings of up to 255 bytes each, like "v=DKIM1; k=rsa; p=MIIBIjANBg..." "...rest of the key...QIDAQAB". The chunk boundary can fall anywhere in the string; what matters is that there is no character inserted between the closing quote of one chunk and the opening quote of the next.

If your provider rejects the value as too long, that is the signal you are in the second category. Split it into two quoted strings and save again. There is a worked example of correct chunking, including how the canonical zone-file form looks, in /blog/dkim-key-length-1024-2048.

Do not create a second conflicting record

If a google._domainkey record already exists from a previous attempt, edit it rather than adding a second one. Two TXT records at the same selector confuse verification. One selector, one record.

Step 3: wait for propagation, then verify before enabling

DNS changes are not instant. Google's own guidance is to allow up to 48 hours, and it warns that turning on authentication before the record has propagated will cause signing to fail. In practice most providers publish within minutes to a couple of hours, but the safe move is to verify the record is visible from the public internet before you go back and switch signing on.

Verify it two ways.

First, use the DKIM checker. Enter your domain and the selector google, and it will look up google._domainkey.yourdomain.com, confirm the record parses as a valid DKIM key, and tell you the key length it found. A green result here means the public key is live and well-formed, which is precisely the precondition for enabling signing safely.

Second, if you prefer the command line, query it directly:

dig TXT google._domainkey.yourdomain.com +short

You should see the reassembled record beginning v=DKIM1; k=rsa; p=.... If dig returns nothing, the record has not propagated yet or the host name is wrong; wait, then recheck. If it returns the value but split across what looks like separate quoted strings, that is normal and correct for a chunked 2048-bit key. Resolvers stitch it together.

Only once the checker shows a valid, full-length key should you move to the final step.

Step 4: turn on signing in Google Workspace

Return to the Admin console tab you left open at Apps > Google Workspace > Gmail > Authenticate email, with the right domain selected.

1. Click Start authentication.
2. The status changes to indicate that authentication is active, and Google begins adding a DKIM signature with your google selector to outbound mail for that domain.

Signing now applies to new mail. It can take up to a further 24 to 48 hours for the change to be fully in effect across Google's infrastructure, though most senders see it almost immediately. If you ever need to stop signing, the same panel offers Stop authentication, but you should not need that in normal operation.

That is the complete enabling process. Generate at 2048 bits, publish the TXT record, verify it is live, then start authentication. The discipline that prevents pain is doing those in that order.

Step 5: confirm real mail is signing and aligning

Switching on the toggle is not the same as proving your live mail is signed correctly. Two quick confirmations close the loop.

Inspect a real message. Send an email from a Google Workspace mailbox to a personal Gmail account. Open it in Gmail, choose Show original from the three-dot menu, and look at the authentication results. You want to see DKIM: PASS with the domain shown as your own domain, not a Google domain. That "with domain yourdomain.com" detail is the alignment you were after. If DKIM shows PASS but the domain is something google-owned, the record published but the Admin console toggle has not taken effect yet, or you enabled it on the wrong domain.

Watch your DMARC reports. If you have a DMARC record collecting aggregate reports, the data will start showing DKIM as a passing, aligned identifier for your Google-sent mail within a day or two. This is the real proof at scale, because it reflects how actual receivers evaluated your mail, not a single test message. If you are not yet collecting those reports, that is the natural next thing to set up; the difference between reports and inbox checks is explained in /blog/dmarc-reports-vs-inbox, and our monitoring service turns the raw XML into plain-English alerts when something changes.

Common problems and how to read them

A handful of failure modes account for nearly every DKIM problem on Google Workspace. Here is how to diagnose each from the symptom.

• The checker finds no record at all. The TXT record has not propagated, or the host name is wrong. Confirm the name is google._domainkey (with the trailing _domainkey and the selector prefix), not google alone or _domainkey alone. Re-query with dig after a wait.
• The record exists but the checker calls it invalid or truncated. This is the chunking problem. The 2048-bit value was stored in a way that lost a piece, usually because the provider silently cut it at 255 bytes. Re-enter it, splitting into quoted 255-byte strings if the provider demands it, and make sure no character sits between the chunks.
• DKIM shows PASS but with a google-owned domain, not yours. Signing is on but using the default generic key, which means your domain DKIM is not actually active. Recheck that you clicked Start authentication for the correct domain in the Admin console.
• DKIM passed yesterday and fails now. Either the DNS record was edited or removed, or you rotated keys without publishing the new selector. Key rotation has its own correct sequence, covered in /blog/dkim-key-rotation: publish the new selector's public key, let it propagate, then switch signing to it, and only retire the old record afterwards.
• Mail to a mailing list or forwarder fails DKIM. Some forwarders alter the message body or headers, which breaks the signature. This is expected and is exactly why DMARC accepts either SPF or DKIM. The behaviour and the ARC mechanism that addresses it are explained in /blog/dkim-alignment-forwarding.

How DKIM fits the bigger authentication picture

Enabling DKIM is one of three records that make a domain trustworthy, and on its own it does not stop spoofing. DKIM proves a message that carries your signature is genuinely yours. It does not, by itself, tell receivers to reject messages that lack a valid signature. That instruction is DMARC's job. SPF, meanwhile, authorises which servers may send for you. The three work as a unit.

The sensible order for a Google Workspace domain is: get SPF correct (a single TXT record including _spf.google.com), enable DKIM as you have just done, then publish a DMARC record starting at p=none to gather reports, and ratchet it up to p=quarantine and finally p=reject once the reports prove every legitimate sender is authenticating and aligning. Moving to enforcement before DKIM is solid is how people accidentally send their own newsletters to spam. The policy progression is laid out in /blog/what-is-dmarc, and you can build a correct DMARC record with the DMARC generator. To pressure-test SPF, including the ten-lookup limit that quietly breaks growing domains, the SPF checker and the guide to fixing SPF permerror are the tools to reach for.

If you would rather not manage selectors, chunked TXT records, key rotation and the move to p=reject by hand, that is precisely what the done-for-you platform exists for. The hosted DKIM product generates and publishes 2048-bit keys, rotates them on a schedule without an outage, and keeps the records correct so DKIM never silently breaks. You can see the full set of free diagnostics at /tools, and review the current bulk-sender requirements that make all of this non-optional at /requirements.

The practical takeaway

Enabling DKIM in Google Workspace is genuinely quick, and the only real trap is sequence and the DNS record itself. Generate a 2048-bit key under Authenticate email in the Admin console, leave the google selector as is, publish the full v=DKIM1 TXT value at google._domainkey.yourdomain.com, and confirm with the DKIM checker that the public key is live and full-length before you click Start authentication. Then prove it with Show original on a test message and watch your DMARC reports show DKIM passing and aligned. Do those steps in that order and you have closed one of the three gaps that leave a Google Workspace domain spoofable, with the other two, SPF and DMARC, the logical next moves.