Enabling DKIM on Google Workspace: the step-by-step guide

Key length: 2048 bits, unless the DNS says otherwise

The preselected choice is 2048 bits, and it is the right one. A 1024-bit RSA key has been considered too short for years by cryptographic guidelines; the major providers still accept 1024-bit signatures, but nothing justifies creating a weak key in 2026. Google itself proposes 2048 by default.

The only genuine reason to downgrade is mechanical: a 2048-bit public key produces a value of roughly 400 characters, beyond the 255-character-per-string limit of a TXT record. The DNS standard solves the problem — a TXT record accepts several concatenated strings — and most modern interfaces split the value automatically. A few older control panels, though, refuse the long input. In that case, two ways out: splitting the value by hand into two quoted strings, or, as a last resort, regenerating a 1024-bit key. The full trade-off — strength, compatibility, rotation — is laid out in the comparison of 1024 and 2048-bit keys. The sane reflex: try 2048 first, and only downgrade after the zone has demonstrably refused it.

Publishing the google._domainkey TXT and starting authentication

The generation dialog displays two values to carry over into the DNS zone: the host name, google._domainkey, and the TXT value, which starts with v=DKIM1; k=rsa; p=. Once published, the record looks like this:

google._domainkey.example.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" )

Two entry precautions. First, the host name: depending on the DNS interface, the field expects either google._domainkey alone (the interface appends the domain) or the full name google._domainkey.example.com — the classic mistake produces google._domainkey.example.com.example.com, which no verifier will ever query. Second, the value: the key must be copied whole, without stray spaces or truncation; a key missing a single character produces unverifiable signatures, which is worse than no signature at all. A quick dig TXT google._domainkey.example.com confirms what the world actually sees.

With the record live, back to the console: the "Start authentication" button asks Google to verify the key's presence, then switches the signing of outgoing messages to d=example.com with the google selector. When the check fails, propagation is almost always the culprit: depending on TTLs and resolvers, the key takes anywhere from a few minutes to 48 hours to become visible everywhere. The error is not final — the button can simply be pressed again later. Once authentication has started, subsequent messages are signed immediately; those already sent obviously keep the old signature.

Verification: DKIM-Signature and s=google

The proof sits in the headers. The simplest test: sending a message from the domain to an external mailbox — any personal Gmail address will do — then opening "Show original" in Gmail. The page summarizes the three verdicts (SPF, DKIM, DMARC) and shows the full header.

Two lines matter. The first, DKIM-Signature, must carry the right domain-selector pair:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=google; h=from:to:subject:date; …

d=example.com and s=google: the signature now commits the domain itself. The second, Authentication-Results, must show dkim=pass header.i=@example.com. If the d= still mentions gappssmtp.com, authentication has not actually started — or the message left before the switch.

At scale, confirmation comes from the aggregate DMARC reports: within a few days, the volume sent from Google's IPs should show up as DKIM-aligned. One important nuance: dkim=pass alone says nothing about alignment — an intact gappssmtp.com signature also shows pass. The match between the d= and the From domain is what makes the difference, and it is exactly what the reports measure.

What activation changes for DMARC alignment

DMARC validates a message when at least one of its two mechanisms passes and aligns: SPF against the Return-Path domain, DKIM against the d= domain. On a Google Workspace domain, SPF is usually already in place and aligned for direct sending. DKIM activation is therefore not redundant: it adds the leg that survives where SPF falls over.

The decisive case is forwarding. A message forwarded automatically — a forwarding mailbox, a former employee's address, an internal list — reaches the final recipient from the forwarding server's IP, not from Google's: SPF fails. The DKIM signature, by contrast, travels inside the message and remains verifiable as long as the signed content is untouched. With aligned DKIM, those forwarded flows keep passing DMARC; without it, they turn into false positives the moment the policy hardens.

That is why DKIM activation is a de facto prerequisite for moving to p=quarantine and then p=reject: it turns reports full of ambiguous failures into a clean baseline where the only remaining failures are the suspicious ones. The policy stages and their exact syntax — p=, rua=, strict or relaxed alignment via adkim= — are walked through in the annotated DMARC record examples, the natural next stop once the signature is live.

The pitfalls: recent domains, aliases and multi-domain setups

The recently added domain. On a domain freshly connected to Google Workspace, key generation can stay unavailable for several hours, and starting authentication can fail even though the TXT record is correctly published. Google's own documentation mentions a delay of up to 72 hours after Gmail becomes active on the domain. The symptom — an inert button, a persistent error — is cured by patience, not by frantically regenerating keys.

Alias domains. Every alias sends mail under its own name, and DKIM alignment is judged alias by alias. The primary domain's key does not cover an alias: the alias must be selected in the drop-down, given its own key, published in its own DNS zone, and have its authentication started. A forgotten alias keeps signing as gappssmtp.com — and its messages will fail alignment the day the policy hardens.

Multi-domain setups. Same logic: the procedure repeats domain by domain. The google selector can be reused in every zone without conflict — a selector is local to its zone. Aggregate reports remain the best detector of a forgotten domain.

Third-party senders. The key generated in the console signs only what leaves Gmail. An emailing platform — Mailchimp, Brevo, SendGrid — signs with its own keys, configured on its side. And on the Microsoft side, the mechanics differ noticeably (two CNAME records, selector1/selector2 selectors): the equivalent guide for Microsoft 365 covers that ground.

Key rotation. A later rotation follows the same sequence — generate, publish, restart — while leaving the old public key published for a few days, so that messages still in transit remain verifiable.

In summary

By default, Google Workspace signs DKIM with a technical gappssmtp.com domain that does nothing for DMARC. Activation on the custom domain follows a short path: Admin console (Apps → Google Workspace → Gmail → Authenticate email), generation of a 2048-bit key, publication of the google._domainkey TXT record, starting authentication, and a header check (d= on the domain, s=google). The operation repeats for every domain and every alias, and covers only Gmail traffic — third-party platforms sign separately. The payoff is substantial: an authentication leg that survives forwarding and makes the move to p=reject realistic.

What remains is measuring the actual state: a free DMARC analysis of the domain shows within seconds whether Google Workspace traffic leaves aligned — and what is still missing. To follow the progression in the reports and harden the policy at the right pace, opening an account takes a few minutes; the signature, for its part, is already in place.