DMARC Analyzer

TL;DR

• Google Workspace DKIM uses one TXT record per sending domain at google._domainkey.<your-domain> containing the public-key bytes directly (v=DKIM1; k=rsa; p=<base64> per RFC 6376 §3.6.2). Operators generate the key inside the Admin Console and publish the resulting TXT at their DNS provider.
• Four steps: (1) generate the key on the Admin Console Authenticate email panel (admin.google.com > Apps > Google Workspace > Gmail > Authenticate email), (2) publish the displayed TXT at google._domainkey.<your-domain>, (3) wait 15 minutes to 48 hours for DNS propagation, (4) click Start authentication on the same Admin Console panel.
• The #1 Workspace DKIM failure mode: outbound mail signed under <tenant>.gappssmtp.com instead of your custom domain. Cause: the Start authentication step was skipped. Fix: verify the TXT resolves, then click Start authentication.
• Single selector with manual rotation: Workspace uses one selector (google._domainkey by default) that the operator rotates manually via the Admin Console Generate new record button. Microsoft 365 uses a different model: two selectors published as CNAME records.
• 2048-bit keys are today's baseline: RFC 8301 requires at least 1024 bits and recommends at least 2048. Legacy 1024-bit keys should be rotated to 2048-bit by generating a new key with DKIM key bit length: 2048 selected.
• Operator owns the key lifecycle: you decide when and how often to rotate, and you publish the new record in DNS. Annual rotation is a sensible baseline; rotate immediately after any suspected key-compromise event.
• Verification: dig +short TXT google._domainkey.<your-domain> must return a v=DKIM1; k=rsa; p=… record; Authentication-Results in delivered mail must show dkim=pass header.d=<your-domain> (NOT header.d=<tenant>.gappssmtp.com).
• DKIM alone does not stop spoofing; DKIM is one of two authentication signals DMARC consumes. Pair DKIM with SPF (see SPF for Google Workspace) and DMARC (see DMARC for Google Workspace) for end-to-end spoof-resistance.

What this guide covers

A focused operator-implementation walkthrough for DKIM on Google Workspace / Gmail-for-business tenants. Sibling pages cover the broader rollout (DMARC for Google Workspace walks the full SPF + DKIM + DMARC deployment), the protocol primer (DKIM explained), the canonicalization deep dive (DKIM canonicalization), the selector deep dive (DKIM selectors), and the replay-attack analysis (DKIM replay attacks). THIS page is the Workspace-specific operator reference: the single-selector TXT-publication model, the Admin Console workflow, operator-controlled 2048-bit key generation, manual rotation cadence, and the gappssmtp.com signing-identity failure mode.

The page is anchored against the Feb 2024 Google/Yahoo bulk-sender requirements: a domain sending more than 5000 messages per day to gmail.com or yahoo.com must have SPF and DKIM set up and must pass DMARC with alignment through SPF or DKIM. Without DKIM enabled for the custom domain (the most common Workspace misconfiguration), bulk mail from your Workspace tenant does not meet these requirements and may be junked or rejected by Google and Yahoo - exactly the same bulk-sender enforcement Google applies to all senders.

How Google Workspace DKIM works

Workspace DKIM is structurally different from Microsoft 365, cPanel, and self-hosted DKIM. Three architectural choices define it:

1. TXT publication (not CNAME delegation)

Workspace publishes a TXT record at google._domainkey.<domain> containing the public-key bytes directly per RFC 6376 §3.6.2:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv..."

The Admin Console Generate new record panel produces the full TXT value (often spanning multiple 255-byte chunks joined per RFC 1035 §3.3.14); the operator copies the panel's displayed value verbatim into their DNS provider. This contrasts with Microsoft 365's CNAME-delegation model where the actual p= public key lives in Microsoft's infrastructure under <tenant>.onmicrosoft.com.

2. Single selector with manual rotation

Workspace uses ONE selector (google._domainkey by default; operators may pick a custom prefix when generating a new key). Rotation is a manual two-step process: generate a new key under a new selector (e.g., google2024._domainkey), publish the new TXT, then click Start authentication using new key on the Admin Console. The old selector TXT remains published during transition so in-flight messages signed under the previous selector still verify; remove the old TXT 48-72 hours after switching active signing.

3. Operator-controlled key custody

Workspace generates the key inside Google's infrastructure (the operator never sees the private-key bytes directly) but exposes the rotation controls to the operator. The operator decides when to rotate, which selector prefix to use, and which key size (1024-bit or 2048-bit on the Admin Console panel; pick 2048-bit whenever your DNS provider supports it - RFC 8301 recommends at least that). A new key only takes effect once the operator has published the new TXT record. In M365 the administrator also starts the rotation, but the new key appears behind the same CNAME records with no change in the domain's DNS. Tradeoff: in Workspace every rotation means a DNS change, in return for full control over how it runs.

Prerequisites

• An active Google Workspace tenant with at least one verified sending domain (the domain you want to DKIM-sign mail from). Verify the domain status at admin.google.com > Account > Domains > Manage domains.
• Administrative role assignment: Super Admin or a custom admin role with the Gmail privilege scope (the Authenticate email panel requires one of these roles).
• DNS administration rights at your sending domain's authoritative nameservers (to publish the TXT record the Admin Console generates).
• An SPF record already published with include:_spf.google.com — see SPF for Google Workspace. SPF + DKIM together are the alignment prerequisite for DMARC enforcement.
• A modern web browser to access the Admin Console at admin.google.com. The Authenticate email panel is UI-only; Workspace does not expose a Cloud-SDK or Admin-SDK command-line equivalent for DKIM management on this panel.

Step 1: Generate the DKIM key

Sign in to the Google Admin Console at admin.google.com with a Super Admin or Gmail-privileged account. Navigate to Apps > Google Workspace > Gmail > Authenticate email.

1. From the Selected domain dropdown, pick your custom sending domain.
2. Click Generate new record.
3. In the dialog:
   • DKIM key bit length: select 2048 (default; never pick 1024 for new keys).
   • Prefix selector: accept the default google for your first key. For a rotation pick a new prefix (e.g., google2024) so the old and new TXT records coexist during transition.
4. Click Generate. Workspace generates the key pair, retaining the private key inside Google infrastructure and displaying the public-key TXT for the operator to publish.

The Admin Console now displays two values:

DNS Host name (TXT record name):  google._domainkey
TXT record value:                  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Leave this Admin Console panel open while publishing the TXT - you will return here for Step 3 (activation).

Step 2: Publish the TXT record

Publish the Admin-Console-displayed TXT at your authoritative DNS provider:

; Replace example.com with your sending domain.
; The TXT value is what the Admin Console displays - copy verbatim.

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

Two publication notes specific to TXT records longer than 255 bytes:

The 255-byte TXT-chunk rule

RFC 1035 §3.3.14 limits each TXT character-string to 255 bytes. A 2048-bit DKIM public key in base64 encoding is approximately 400 bytes; most DNS providers automatically chunk it into multiple "..." "..." strings that the receiver concatenates per RFC 6376 §3.6.2.2. Verify chunking is correct:

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA" "v..."

In the dig output the two chunks appear side by side as separate quoted strings; the verifier joins them with nothing in between, so the split must not add or drop a character (DNS providers handle the chunking automatically when you paste the full Admin Console value into a single TXT field).

DNS provider UIs

Each DNS provider has its own input form (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, Google Cloud DNS, etc.). Three fields to fill in:

• Type: TXT
• Name / Host: google._domainkey (some providers auto-append the apex domain; confirm the final FQDN is google._domainkey.example.com)
• Value: the full v=DKIM1; k=rsa; p=… string from the Admin Console, including the v=DKIM1 and k=rsa prefix.

Save the record. Wait 15 minutes to 48 hours for DNS propagation. Workspace's typical propagation window is 24-48 hours but a short-TTL provider may complete within minutes.

Step 3: Activate DKIM signing

Return to the Admin Console at Apps > Google Workspace > Gmail > Authenticate email. With your domain selected:

1. Click Start authentication.
2. Workspace performs a lookup to verify the TXT resolves at the expected name. If propagation is incomplete the panel displays an error - wait and retry.
3. On success, the panel updates to Authenticating email with DKIM. From this moment Gmail signs outbound mail from the domain with the DKIM key.

The activation step is mandatory. Publishing the TXT alone is NOT sufficient - until you click Start authentication, Gmail continues signing your outbound mail under the default <tenant>.gappssmtp.com identity. See the gappssmtp.com section below for the consequences if this step is skipped.

Verify DKIM signing is working

Three verification gates: DNS, Admin Console status, and end-to-end delivery.

Gate 1: DNS resolution

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The TXT must resolve and contain a valid v=DKIM1 record with a non-empty p= public-key field. An empty p= (i.e., v=DKIM1; k=rsa; p=) means the key has been revoked: the verifier returns a permanent error (key revoked, RFC 6376 §6.1.2). You publish such a record yourself in DNS when you want to retire a selector.

Gate 2: Admin Console status

In the Authenticate email panel, the domain must show Authenticating email with DKIM as its current status (not Not authenticating email or Starting).

Gate 3: End-to-end delivery

Send a message from the Workspace domain to an external mailbox you control (a personal Gmail or Yahoo account, Outlook.com, or DMARC Analyzer's Email Header Analyzer). Open the message headers and locate the Authentication-Results stack:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=google header.b=AbCdEf12;
       spf=pass (google.com: domain of admin@example.com designates ...)
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Three requirements: (1) dkim=pass, (2) header.i=@example.com (your custom domain, NOT @<tenant>.gappssmtp.com), (3) header.s=google (or whichever custom selector prefix you chose). If item 2 shows the gappssmtp.com tenant domain, return to the gappssmtp.com section below.

DKIM key rotation on Google Workspace

Workspace operators rotate manually via the Admin Console, and every rotation requires publishing a new record in DNS. A sensible cadence for routine maintenance is annual rotation; rotate immediately after any suspected key-compromise event.

Four-step manual rotation

1. Generate new key with new selector: On the Admin Console Authenticate email panel, click Generate new record. Pick a NEW selector prefix (e.g., google2024 if your current selector is google) so the old and new TXT can coexist during transition.
2. Publish the new TXT: Add a new TXT record at <new-selector>._domainkey.<your-domain>. Do NOT delete the existing google._domainkey TXT yet.
3. Switch active signing: After DNS propagation, return to the Admin Console and click Start authentication using new key. Workspace switches signing to the new selector; existing messages signed under the old selector continue to verify because the old TXT remains published.
4. Retire the old TXT: Wait 48-72 hours after switching active signing (longer if your previous key's TXT had a high TTL). Then remove the old TXT at google._domainkey.<your-domain>. In-flight messages signed under the retired selector that arrive after retirement will fail DKIM verification - the 48-72h window minimizes that population.

Selector-naming conventions

No fixed convention exists. Common patterns:

• google → google2024 → google2025 (year-based rotation log)
• google → google2 → google3 (sequential rotation log)
• googlejan2024 → googlejul2024 (semi-annual rotation log)

The selector value is operator-internal - receivers do not care what your selector is named, only that the TXT resolves at the name the s= tag identifies. Pick a naming pattern that helps you track which rotation generation a selector belongs to.

Key-size posture

Always pick 2048-bit RSA for new keys: RFC 8301 (Cryptographic Algorithm and Key Usage Update to DKIM) requires at least 1024 bits and recommends at least 2048. The Admin Console offers both 1024-bit and 2048-bit - according to Google's documentation the 1024-bit option is for domain hosts that do not support 2048-bit keys (usually because of TXT record length limits). 2048-bit is today's baseline and what receivers expect.

The gappssmtp.com signing-identity gotcha

The number-one Workspace DKIM failure mode: outbound mail from example.com arrives at receivers with header.d=<tenant>.gappssmtp.com instead of header.d=example.com. The DKIM-signing domain then does not align with the visible From: header domain, so DMARC can rely on SPF only.

Why it happens

Workspace always signs SOMETHING. When DKIM is not explicitly enabled for the custom domain, Gmail falls back to signing under <tenant>.gappssmtp.com using a default DKIM key Workspace automatically provisions at tenant creation. The default key is real, valid, and signs successfully - but its d= tag points at the Workspace routing domain, not at your custom domain.

Symptom in Authentication-Results

Authentication-Results: mx.example.net;
       dkim=pass header.i=@tenant.gappssmtp.com header.s=20221208
       spf=fail (example.net: domain of admin@example.com does not designate ...)
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Note: dkim=pass is True (signature verifies cryptographically), but header.i is @<tenant>.gappssmtp.com, not @example.com. As long as SPF passes and aligns, DMARC still passes; once SPF fails, for example after a message is forwarded, nothing is left to carry it. Aggregate DMARC reports surface this as dkim=pass + spf=fail + dmarc=fail rows for messages your Workspace tenant sent.

Symptom in Admin Console status

The Authenticate email panel shows the domain as Not authenticating email rather than Authenticating email with DKIM. Two sub-cases:

• Key never generated: the panel offers Generate new record but no published TXT exists. Run through the full four-step workflow above.
• Key generated and TXT published but Start authentication never clicked: the panel shows the displayed TXT value and an active Start authentication button. Click it.

The fix

One click: Start authentication in the Admin Console (after confirming the TXT resolves via dig +short TXT google._domainkey.<your-domain>).

Seven common Google Workspace DKIM mistakes

1. Publishing the TXT but never clicking Start authentication - the gappssmtp.com gotcha above. The Admin Console activation step is mandatory; the TXT alone does not flip Gmail to signing under your custom domain.
2. Picking 1024-bit on the Admin Console generate panel without need - pick 2048-bit, as RFC 8301 recommends. The 1024-bit option is for DNS providers that do not support 2048-bit keys; if yours does, there is no reason to use it.
3. Publishing the TXT at the wrong name - the host must be google._domainkey (the Workspace default selector), not _domainkey.google, google._domainkey.www, default._domainkey, or any other variation. If you picked a custom selector prefix during generation, the host is <your-prefix>._domainkey.
4. Deleting the old TXT before rotation completes - during rotation, both old and new selector TXTs must coexist for at least 48-72 hours after switching active signing so in-flight messages signed under the old selector still verify. Removing the old TXT too early breaks DKIM verification for those in-flight messages.
5. Copying the TXT value without the v=DKIM1 prefix - the Admin Console displays the full record including v=DKIM1; k=rsa;. Some operators paste only the p=<base64> portion, producing a malformed TXT that receivers reject as not a DKIM record.
6. Setting an excessively-low TTL on the DKIM TXT - while a low TTL during initial rollout speeds DNS propagation, leaving the TTL at 300 or less in steady state shortens the rotation overlap window. Use TTL 3600 (1 hour) or 86400 (1 day) for the steady-state DKIM TXT after the initial rollout completes.
7. Assuming DKIM stops spoofing on its own - DKIM authenticates that a specific signing domain produced the message, but receivers do not enforce on DKIM alone. DMARC is the enforcement layer that consumes DKIM and SPF verdicts. Without DMARC at p=quarantine or p=reject, spoofed mail still delivers regardless of DKIM state.

Troubleshooting decision matrix

Map the observed symptom to the diagnostic next step:

• Symptom: Authentication-Results shows dkim=none.
  Diagnosis: DKIM is not enabled for the sending domain. The Admin Console Authenticate email panel shows the domain as Not authenticating email; no google._domainkey TXT published.
  Fix: Run through the four-step workflow (Generate, Publish, Activate, Verify) above.
• Symptom: Authentication-Results shows dkim=pass but header.i=@<tenant>.gappssmtp.com and DMARC fails.
  Diagnosis: The gappssmtp.com gotcha. TXT may be published but Start authentication was never clicked.
  Fix: Click Start authentication in the Admin Console.
• Symptom: Authentication-Results shows dkim=fail (body hash mismatch).
  Diagnosis: Message body was modified after signing - a forwarder, mailing list, or security gateway rewrote the body or added a footer. Workspace uses c=relaxed/relaxed canonicalization, which tolerates whitespace and header-case changes but not body content modification.
  Fix: For forwarders/gateways in your control, configure ARC sealing (see ARC explained); for upstream forwarders out of your control, accept the failure and rely on DMARC's relaxed-mode SPF + DKIM any-pass-wins alignment.
• Symptom: Start authentication button shows Error: DKIM record not found.
  Diagnosis: DNS propagation is incomplete.
  Fix: Verify the TXT resolves from your local resolver (dig +short TXT google._domainkey.<your-domain>); wait the remaining propagation window; retry.
• Symptom: Authentication-Results shows dkim=permerror (no key for signature).
  Diagnosis: The s= tag in the DKIM-Signature header references a selector whose TXT no longer exists. Common after rotation: the old TXT was removed before all in-flight messages signed under that selector were delivered.
  Fix: Re-publish the retired TXT temporarily (Workspace archives the old key value, or re-generate from the operator records). Future rotations should wait the full 48-72h overlap window before retiring the old TXT.
• Symptom: DKIM verifies for messages sent from Gmail web UI but fails for messages sent via SMTP relay from a third-party application through Workspace.
  Diagnosis: Workspace's SMTP relay service has separate DKIM signing rules - it signs only for domains explicitly registered in the SMTP relay configuration.
  Fix: At admin.google.com > Apps > Google Workspace > Gmail > Routing > SMTP relay service, verify the relay configuration includes your domain and DKIM signing is enabled for relayed traffic.

Frequently asked questions

How do I enable DKIM on Google Workspace?

Four steps. (1) Open the Google Admin Console (admin.google.com), navigate to Apps > Google Workspace > Gmail > Authenticate email. (2) Select your sending domain from the dropdown and click Generate new record, choosing DKIM key bit length 2048 and the default selector prefix google (the resulting record name is google._domainkey.<your-domain>). (3) Publish the displayed TXT record at your DNS provider: google._domainkey.<your-domain> TXT "v=DKIM1; k=rsa; p=<base64-public-key>" - copy the exact TXT value the Admin Console displays. (4) After DNS propagation (15 minutes to 48 hours), return to the same Admin Console panel and click Start authentication. From that moment Gmail signs outbound mail from your domain with DKIM-d=<your-domain> using the operator-controlled private key held inside Workspace.

Why does Google Workspace use only one DKIM selector?

Because the operator generates and controls the key, with manual rotation rather than automatic switching. Workspace uses one selector (google._domainkey by default, configurable on the Admin Console Generate new record panel) and one TXT record holding the public-key bytes directly per RFC 6376 §3.6.2. The operator clicks Generate new record to create a new key pair, then publishes the new TXT (typically under a new selector like google2024) and switches signing to the new selector on the Admin Console - manual two-step rotation. The Workspace single-selector design contrasts with Microsoft 365 DKIM, where each domain has two selectors (selector1 and selector2) published as CNAME records and the keys sit in Microsoft's infrastructure; rotation is started by the administrator there too, but needs no DNS change. The practical tradeoff in Workspace is operator control over the entire key lifecycle in exchange for publishing a new record at every rotation.

What is the difference between Google Workspace DKIM and Microsoft 365 DKIM?

Three structural differences. (1) Record type: Workspace publishes a TXT record at google._domainkey.<your-domain> containing the public-key bytes directly (v=DKIM1; k=rsa; p=<base64>); M365 publishes CNAMEs delegating to the tenant key material under <tenant>.onmicrosoft.com. (2) Selectors: Workspace uses ONE selector (google._domainkey) and the operator creates a new one at rotation; M365 uses TWO selectors (selector1 and selector2) and switches between them during a rotation. (3) Key publication: in Workspace a new public key reaches DNS only when the operator publishes a new TXT record; in M365 the new key appears behind the same CNAME record with no change in the domain's DNS. In both services the private key stays with the provider and the administrator starts the rotation. The practical consequence: a Workspace rotation requires a DNS change, an M365 rotation does not. Both produce RFC 6376 §3.6.2 compliant v=DKIM1 records that receivers verify identically.

Why are my Google Workspace messages signed under gappssmtp.com instead of my custom domain?

Because DKIM was never enabled for your custom domain in the Admin Console. Google Workspace always signs outbound mail with SOME DKIM key - the default is your tenant identity under <your-tenant>.gappssmtp.com (an automatically-provisioned Workspace key). Operators see this when DKIM verifies cryptographically (dkim=pass) but Authentication-Results shows header.i=@<tenant>.gappssmtp.com instead of header.i=@<your-custom-domain>. Such a signature does not align with the visible From: header domain, so DMARC can rely on SPF only and fails whenever SPF fails or does not align, for example after a message is forwarded. To get DKIM signing under your custom domain, you must (1) generate the DKIM key for your custom domain on the Admin Console Authenticate email panel, (2) publish the displayed TXT record at google._domainkey.<your-domain>, (3) wait for DNS propagation, then (4) click Start authentication in the Admin Console to flip the active signing identity. This is by far the #1 cause of DMARC failures on Workspace tenants.

How do I rotate Google Workspace DKIM keys?

A four-step manual rotation in the Admin Console. (1) Navigate to admin.google.com > Apps > Google Workspace > Gmail > Authenticate email, select your domain. (2) Click Generate new record, choose 2048-bit key length, and pick a NEW selector prefix (e.g., google2024 if your current selector is google) so the old and new TXT can coexist during the transition. (3) Publish the new TXT record at <new-selector>._domainkey.<your-domain> alongside the existing google._domainkey TXT - never delete the old TXT before the rotation completes. (4) On the same Admin Console panel, click Start authentication using new key. Wait at least 48-72 hours after switching active signing before removing the old TXT, so in-flight messages signed under the previous selector still verify at receivers whose DNS caches have not yet flushed. Rotation cadence: annually is the industry baseline; after any suspected key-compromise event rotate immediately.

Why does my DKIM-Signature header still show gappssmtp.com after I generated a key for my custom domain?

Most likely the Start authentication button in the Admin Console was never clicked, or DNS propagation is incomplete. Google Workspace falls back to signing with the gappssmtp.com tenant identity when (a) the google._domainkey TXT for your custom domain does not yet resolve from the public DNS, (b) the public-key TXT was published but the Admin Console Start authentication call never fired, or (c) the sender is mailing through a non-primary domain identity that has not been DKIM-enabled. Diagnose with three checks: dig +short TXT google._domainkey.<your-domain> must return a v=DKIM1 record with a non-empty p= public-key field; in the Admin Console the Authenticate email panel must show status DKIM authenticated for <your-domain>; the failing message DKIM-Signature header d= tag must match your custom domain. If all three pass, send a test message and inspect the Authentication-Results stack at a Gmail mailbox you own.

Do I need a 2048-bit DKIM key on Google Workspace?

Yes - 2048-bit is the current baseline. RFC 8301 (Cryptographic Algorithm and Key Usage Update to DKIM, 2018) requires RSA keys of at least 1024 bits and recommends at least 2048. Google's documentation says to select 2048 if your domain provider supports 2048-bit keys and notes that longer keys are more secure; the 1024 option is for domain hosts that do not support 2048-bit keys. Legacy Workspace tenants with 1024-bit keys should rotate to 2048-bit by generating a new key with the 2048 selection on the Admin Console panel. 1024-bit RSA keys are considered factorable by well-resourced attackers, and 2048-bit is what receivers expect from senders today. For new keys always pick 2048-bit.

Can I bring my own DKIM key to Google Workspace?

Not for native Gmail signing. The Workspace model generates the private key inside Google infrastructure and surfaces only the public-key TXT for the operator to publish - operators do not import an externally-generated key. Two workarounds exist: (a) for third-party senders relayed via Workspace (e.g., a marketing platform, transactional ESP, or security gateway that signs before relaying through Gmail), the upstream sender can sign with its own key and own d= signing domain; Gmail preserves DKIM-Signature headers it did not generate; (b) for full DKIM control over the d=<your-domain> identity, an organization must move outbound mail flow out of Gmail (custom MTA, third-party signing relay) - incompatible with native Workspace send. The pragmatic recommendation: keep native Gmail signing on google._domainkey with the Workspace-generated key, and rotate annually via the Admin Console.

Related guides

• DMARC for Google Workspace — the full deployment walkthrough where DKIM activation is one of three SPF + DKIM + DMARC steps. Read once you have DKIM enabled to advance through DMARC p=none → p=quarantine → p=reject.
• DKIM DNS TXT-record byte syntax — the WORKSPACE-DKIM-PUBLISHER-TXT-RECORD- BYTE-SYNTAX companion documenting the precise byte-syntax of the DKIM public-key TXT record the Workspace Admin Console emits at the google._domainkey.<domain> selector during DKIM activation — the v=DKIM1 version tag, the k=rsa key-type tag, the p=<base64> public-key material (the 1024-bit or 2048-bit RSA modulus + exponent), the critical RFC 1035 §3.3.14 byte-string concatenation rule (the Workspace-emitted base64 is broken into 255-byte chunks via "chunk1" "chunk2" "chunk3" adjacent-quoted-string DNS-master-file syntax that EVERY DNS-hosting provider must preserve through the publication path). Where THIS page documents the Workspace- specific DKIM ACTIVATION PROCEDURE (the Admin Console workflow at admin.google.com → Apps → Google Workspace → Gmail → Authenticate email, the "Generate new record" button that produces the public-key blob, the manual publication step at the customer's DNS provider, the "Start authentication" button that switches Workspace egress from unsigned to DKIM-signed once propagation verifies), the DKIM-DNS-syntax spoke is the BYTE-LAYER PUBLICATION-CORRECTNESS contract documenting the exact byte-format the Admin-Console-produced public key must match when published at the customer's DNS zone. The four-axis WORKSPACE-ACTIVATION-VS- PUBLISHER-TXT-SYNTAX comparison exposes the structurally-distinct DEPLOYMENT-BOUNDARY- FAULT-MODE roles: (i) the Workspace Admin Console emits the DKIM TXT record content as a single string that the customer's IT team must copy-paste into their DNS hosting provider's TXT-record editor; the copy-paste boundary is the most common Workspace DKIM-deployment failure mode — the DKIM-DNS-syntax spoke documents the byte-syntax that MUST be preserved verbatim through the copy-paste (any character substitution, whitespace introduction, or DNS-provider auto- formatting breaks the published key); (ii) DNS hosting providers vary in how they handle the 255-byte TXT-string chunk boundary — some auto-split, some require manual quoting, some store the entire Workspace-emitted blob as a single oversized string that fails to publish; the DKIM-DNS-syntax spoke documents the canonical adjacent-quoted-string syntax every Workspace-customer DNS provider must produce, regardless of editor UX; (iii) Workspace emits a single google selector by default — but the byte-syntax for adding a SECOND rotation selector (google2._domainkey) during DKIM key rotation must match the first selector's byte-syntax exactly; the DKIM-DNS-syntax spoke documents the per-selector TXT record format used by every Workspace DKIM key (the default, rotation, and any custom CNAME-delegated keys); (iv) Workspace's Admin- Console-side DKIM activation requires DNS-propagation verification BEFORE the "Start authentication" button enables DKIM signing of outbound mail — the Workspace-side propagation check retrieves the published TXT record and parses it as DKIM byte-syntax; if the publication failed to preserve byte-syntax through the customer's DNS provider, the Workspace-side check returns "DKIM record not found" and outbound mail remains unsigned (silent fault — Workspace does NOT alert the operator that mail is un-signed and consequently mis-aligned under DMARC). Read the DKIM-DNS-syntax spoke when an operator asks "the Workspace Admin Console says my DKIM activation is complete but RUA reports show DKIM=fail on every Workspace-egress message — what's broken?" — the answer is most often a byte-syntax preservation failure during the copy-paste-and-publish boundary at the customer's DNS provider, which the spoke documents as the byte-level publication- correctness contract this Workspace DKIM activation depends on.
• DMARC for SaaS senders — the WORKSPACE-TENANT-VS-SAAS-PLATFORM- DKIM-DEPLOYMENT-CONTRAST companion to this Workspace DKIM deployment guide. Where THIS page documents the per- Workspace-tenant single-customer single- selector google._domainkey TXT-record publication architecture (operator-controlled 2048-bit key- generation step, manual rotation cadence, gappssmtp.com signing- identity gotcha), the SaaS-senders spoke is the MULTI-TENANT-PLATFORM-OPERATOR- VIEW documenting the structurally- distinct per-customer-domain CNAME- delegation discipline customer- engagement-platform operators (Mailchimp / HubSpot / Marketo / Pardot / Klaviyo / Salesforce Marketing Cloud / Shopify / BigCommerce) apply to the same DKIM publication primitive at FOUR per- Workspace-tenant-vs-SaaS-platform deployment-contrast dimensions: (i) single-customer-domain TXT- publication vs multi-tenant-shared-pool CNAME-delegation key-management — Workspace publishes one per-tenant TXT record carrying the public key directly in the customer's own DNS zone; SaaS platforms publish per-customer CNAMEs pointing at a master-zone per-customer key target the platform operator manages across the entire customer fleet; (ii) operator-controlled-2048-bit- key-generation manual-rotation cadence vs platform-managed-master-zone automatic-rotation cadence observability — Workspace key rotation is OPERATOR-managed (the operator manually re-generates and re- publishes the key on a documented cadence); SaaS-platform master-zone rotation is PLATFORM-managed and OPAQUE to the customer-domain operator (the platform operator rotates k1 → k2 → k3 on their schedule and customers observe the rotation only by watching the s= selector field in decoded-RUA dkim=pass entries cycle through the per-customer CNAME-target rotation cadence); (iii) per- tenant Workspace-egress IP-pool vs SaaS-platform shared-tenant-pool IP source-IP attribution — Workspace outbound mail egresses through the per-Workspace-tenant-attributable Google-egress IP pool spanning the five *.ASPMX.L.GOOGLE.COM canonical MX-hostname-glob population; SaaS-platform outbound mail egresses through the platform's shared-tenant pool IPs with NO sub-tenant differentiation in the RUA aggregate- report's source_ip column, creating the cross-tenant- attribution gap the SaaS-senders spoke documents; (iv) per-tenant Workspace-DKIM-failure-attribution vs platform-wide-DKIM-rotation-event- attribution operator coordination — Workspace DKIM-pass-rate troughs attribute directly to the per-tenant google._domainkey configuration the Workspace operator controls; SaaS-platform DKIM-pass-rate troughs attribute either to a per- customer CNAME-target misconfiguration the customer can fix unilaterally OR to a platform-wide master-zone rotation drift the customer can only escalate through platform-side support — the spoke documents the per-attribution- class coordination workflow. Pair this Workspace DKIM deployment guide (the single-customer-domain per-tenant TXT- publication reference) with the SaaS- senders spoke (the multi-tenant- platform per-customer CNAME-delegation reference) for any operator running BOTH a Workspace tenant AND outbound mail delegated to a SaaS multi-tenant platform.
• DMARC for transactional email documenting the transactional-ESP per-customer-domain DMARC deployment discipline whose per-tenant DMARC TXT record at _dmarc.<customer-domain> structurally consumes the per-message DKIM-Signature header d=<customer-domain> identifier produced by the transactional-ESP egress signing pipeline per-OTP / per-MFA / per-password-reset / per-order-confirmation message-emission event. Four per-Workspace-tenant-vs- per-transactional-ESP DKIM publication contrast dimensions: (i) the per-Workspace-tenant single-customer single-selector google._domainkey.<workspace-tenant> TXT publication discipline THIS page documents is STRUCTURALLY DISTINCT from the transactional-ESP per-customer-domain CNAME-delegation discipline (e.g. SendGrid s1._domainkey + s2._domainkey dual-selector CNAME → SendGrid master DKIM zone; Amazon SES <identity>._domainkey + <rand1>._domainkey + <rand2>._domainkey Easy-DKIM three-selector CNAME → amazonses.com master zone; Mailgun mta._domainkey.<subdomain> TXT publication) — the Workspace operator publishes the cryptographic public-key DIRECTLY at the tenant-domain whereas the transactional-ESP operator DELEGATES the cryptographic-public-key publication to the ESP master zone via per-customer-domain CNAME. (ii) The per-Workspace-tenant single-selector rotation cadence (one-shot Workspace Admin Console "Generate new DKIM key" → operator manually publishes new google._domainkey.<workspace-tenant> TXT-RR at the customer-domain zone-editor surface) contrasts with the transactional-ESP platform-side zero-touch rotation discipline (the ESP operator rotates its master-zone keys WITHOUT customer involvement because the per-customer-domain CNAME-pointer targets the master zone) — the per-vanity-domain DMARC adkim= alignment evaluator sees the SAME d=<customer-domain> identifier in BOTH topologies but the rotation-cadence-vs-publication- observability primitive THIS Workspace DKIM publication page documents materially differs from the transactional-ESP equivalent. (iii) The per-Workspace-tenant gappssmtp.com default-signing-identity fallback (when the Workspace operator has NOT yet published google._domainkey at the custom-tenant-domain, the Workspace MTA still signs every outbound message with the platform-side d=<workspace-tenant>.gappssmtp.com identifier) is the structural parallel to the transactional-ESP per-customer DEFAULT-DOMAIN-EGRESS fallback (when the customer has NOT yet published the per-customer-domain DKIM CNAMEs at their vanity-domain zone, the transactional-ESP sends from <rand>@<sub>.sendgrid.net or <rand>@email.amazonses.com with d=sendgrid.net or d=amazonses.com signing) — both default-fallback identities produce dkim=pass but dmarc=fail at the receiver per RFC 7489 §3.1.1 alignment evaluation against the From:-header organizational-domain. (iv) The per-Workspace-tenant DMARC rua= aggregate-report observability surfaces per-message DKIM-Signature d=<workspace-tenant> identifier alignment attribution to a SINGLE Workspace MTA pool whereas the per-customer-domain DMARC rua= aggregate-report observability under the transactional-ESP egress topology surfaces per-message DKIM-Signature d=<customer-domain> identifier alignment attribution across MULTIPLE transactional-ESP shared-IP pools (e.g. SendGrid IP-warmup pools, Amazon SES dedicated-IP-vs-shared-IP pools, Mailgun region-specific IP pools) — the per-Workspace-tenant single-MTA-pool attribution discipline THIS page documents the per-tenant-DKIM-publication primitive of is the structurally distinct single-attribution-pool sibling-pattern to the transactional-ESP multi-attribution-pool deployment pattern at the per-message DKIM-Signature d=-tag-vs-DMARC-alignment evaluation boundary.
• SPF for Google Workspace — the SPF operator reference covering include:_spf.google.com and the SMTP relay service. SPF + DKIM together are the alignment prerequisite for DMARC enforcement.
• MTA-STS for Google Workspace — the SAME-PROVIDER TRANSPORT-SECURITY COMPANION to this DKIM-side Workspace deployment guide. Where DKIM (and SPF + DMARC) authenticate the SENDER identity of outbound Workspace mail at the application layer, MTA-STS protects the TRANSPORT layer for inbound Workspace mail by preventing opportunistic-TLS STARTTLS-stripping downgrades to cleartext between sending MTAs and the Workspace receivers aspmx.l.google.com / alt1-4.aspmx.l.google.com. The two protocol layers are COMPLEMENTARY rather than overlapping: DKIM signs the message at the application layer (defense against in-flight content tampering and From-header spoofing), MTA-STS pins the SMTP session to enforced TLS at the transport layer (defense against network-level MITM and STARTTLS-stripping). A DKIM-authenticated message can still leak in cleartext to a downgrade attacker if the receiving MX accepts cleartext SMTP; an MTA-STS enforced policy file at /.well-known/mta-sts.txt on mta-sts.<domain> prevents that downgrade. Operators completing this DKIM-for-Workspace deployment SHOULD also publish the MTA-STS policy file enumerating the four canonical Workspace MX hosts so the transport-security gap that DKIM does not address is closed. The MTA-STS-for- Workspace spoke documents the Workspace-specific deployment procedure: the _mta-sts.<domain> TXT-record format, the mta-sts.<domain> HTTPS hosting requirement (four common patterns — GCS bucket + Cloud CDN, Cloud Run + Cloud Load Balancing, Firebase Hosting, third-party static-site host), the policy-file version / mode / mx / max_age grammar, the four canonical *.aspmx.l.google.com MX entries, the TLS-RPT wire-up at _smtp._tls.<domain>, and the testing-mode burn-in workflow. This is the FIRST Workspace cross-protocol bridge from this DKIM-side guide to the transport-security-side MTA-STS procedural sibling.
• MTA-STS for Microsoft 365 — the WORKSPACE-TENANT-DKIM-SIGNED- OUTBOUND-MAIL-TO-M365-TENANT-RECEIVING- DOMAIN-AS-CROSS-PROVIDER-MTA-STS- ENFORCEMENT-BOUNDARY companion to this Workspace-tenant DKIM deployment guide. Where THIS page documents the Workspace-tenant DKIM-signing-identity publication infrastructure (the google._domainkey.<domain> TXT-record publication topology, the Admin Console "Authenticate email" activation workflow at admin.google.com → Apps → Google Workspace → Gmail → Authenticate email, the 1024- vs-2048-bit Workspace-managed RSA key-size choice, and the per-domain Workspace-DKIM-signing-egress signing path), the MTA-STS-for-Microsoft-365 spoke documents the CROSS-PROVIDER TRANSPORT-LAYER MTA-STS enforcement boundary the Workspace tenant's DKIM-signed outbound mail MUST cross when delivering to M365-hosted recipient domains. Concretely, the spoke documents FOUR Workspace-DKIM-to-M365-MTA-STS-cross- provider-coordination dimensions: (i) Workspace-tenant DKIM-signed outbound mail to M365 recipient domains traverses the M365-published MTA-STS-enforce-mode policy at the SMTP-session-establishment boundary — when a Workspace tenant's outbound mail-stream (DKIM-signed at the Workspace egress per THIS page's publication topology) is delivered to an M365-tenant recipient domain whose operator has published an MTA-STS policy file at https://mta-sts.<m365-tenant- domain>/.well-known/mta-sts.txt in mode: enforce, the Workspace-side sending MTA's STARTTLS negotiation with the M365 receive- side MX (<m365- tenant>.mail.protection.outlook.com) MUST succeed under the M365-published TLS-enforcement contract — STARTTLS downgrade or cleartext-fallback causes the Workspace-side delivery attempt to FAIL at the transport layer BEFORE the M365 receive-side DKIM verification of the Workspace- signed message ever fires; (ii) Workspace-side sending MTA's MTA-STS-policy-cache-lookup is receiver-side-driven at the M365 recipient-domain boundary — the Workspace sending MTA fetches the M365 recipient-domain's MTA-STS policy file via HTTPS to https://mta-sts.<m365- domain>/.well-known/mta-sts.txt and consults the policy's mx: directive (typically mx: *.mail.protection.outlook.com for M365-tenant-hosted domains) plus the max_age:-bounded cache window to decide whether to ENFORCE TLS — the Workspace sending MTA caches the M365 policy file per the spoke's documented policy-cache- lifecycle semantics; (iii) Workspace-tenant DKIM-signed mail to M365 recipient domains is ENVELOPE-LEVEL transport-encrypted even though application-layer DKIM signing provides no transport-layer confidentiality — DKIM signing (the application-layer identity primitive THIS page publishes) and MTA-STS enforcement (the transport-layer confidentiality primitive the spoke publishes at the M365 recipient-domain boundary) are STRUCTURALLY ORTHOGONAL protections: DKIM defends against in-flight content tampering AND From-header forgery at the application layer, while MTA-STS defends against STARTTLS-stripping downgrade AND cleartext-interception at the transport layer — both must succeed for the Workspace-to-M365 cross-provider delivery to be application-authenticated AND transport-encrypted; and (iv) cross-provider Workspace- to-M365 TLS-RPT report-correlation requires per-MX-target failure attribution — when a Workspace-side sending MTA's STARTTLS negotiation to an M365 recipient MX fails (STARTTLS unsupported, certificate-validation failure against the BIMI-WG- approved CA chain, MTA-STS policy host unreachable), the Workspace sending side emits a TLS-RPT failure-report payload addressed to the M365-recipient-domain's rua=mailto: address for the M365 operator to investigate — the M365 operator SHOULD coordinate the M365-published MTA-STS policy file the spoke documents AGAINST the Workspace- side TLS-RPT failure-report stream to detect cross-provider STARTTLS-stripping events that threaten the Workspace-to-M365 delivery path. Read the MTA-STS- for-Microsoft-365 spoke alongside THIS Workspace DKIM deployment guide when the Workspace tenant operator is RECONCILING the Workspace-tenant DKIM-signing- identity coverage with the cross- provider MTA-STS-enforcement boundary coverage at every M365-hosted recipient domain the Workspace tenant delivers outbound mail to — the spoke documents the M365-side TLS- enforcement publication contract the Workspace sending MTA's SMTP-session negotiation MUST succeed under for the Workspace- DKIM-signed outbound message to reach the M365 recipient mailbox.
• MTA-STS policy-file byte syntax (RFC 8461 §3.2 policy-file grammar) — the WORKSPACE-TENANT-MTA-STS-POLICY-FILE-AUTHORING-AT-mta-sts-PERIOD-DOMAIN-WELL-KNOWN-PATH-PUBLICATION-CONSUMER-OF-POLICY-FILE-BYTE-LAYOUT companion documenting the per-field byte-level grammar (version: STSv1 / mode: enforce|testing|none / mx: <hostname> / max_age: <seconds>) of the MTA-STS policy file the Workspace tenant authors and serves at https://mta-sts.<domain>/.well-known/mta-sts.txt when extending this DKIM-side Workspace deployment with the transport-security-side MTA-STS layer, across FOUR Workspace-tenant MTA-STS policy-authoring dimensions: (1) Workspace four-canonical-MX enumeration as mx:-field byte-content prerequisite — the Workspace tenant publishes one mx: aspmx.l.google.com line and four mx: alt1.aspmx.l.google.com through alt4.aspmx.l.google.com lines (or a single wildcard mx: *.aspmx.l.google.com); the per-line byte-syntax MUST honor the RFC 8461 §3.2 hostname grammar (LDH-only, no trailing whitespace, one line per MX) — any byte-syntax error in the mx:-list produces a receiver-side policy-parse-failure that defaults to opportunistic-TLS rather than enforced; (2) Workspace policy-host LF-vs-CRLF line-ending discipline as policy-fetch byte prerequisite — the /.well-known/mta-sts.txt file served via GCS bucket / Cloud Run / Firebase Hosting / third-party static-site host MUST use LF line endings per RFC 8461 §3.2; CRLF line endings serialised by some Windows-based editors produce receiver-side parse failure at the sending MTA's policy-fetch step; (3) Workspace mode: testing → mode: enforce ramp byte-token discipline as policy-evolution gate — the Workspace tenant ramps from mode: testing (TLS-RPT reports delivered but no actual blocking) to mode: enforce (actual TLS-MX enforcement) at a measured cadence; the per-policy-version mode:-field byte-token is the load-bearing ramp-control signal; (4) Workspace per-policy max_age: seconds-byte-value rotation-cadence discipline — the Workspace tenant typically publishes max_age: 604800 (7 days) during burn-in and max_age: 2419200 (28 days) at steady state; the per-policy max_age:-field byte-value controls how long receivers cache the policy, which directly affects rotation cadence when the Workspace tenant changes the id=-tag on the _mta-sts.<domain> TXT-record. Byte-syntax correctness across these four Workspace MTA-STS policy-authoring dimensions is the load-bearing prerequisite for the transport-security closure of THIS DKIM-side Workspace deployment.
• MTA-STS vs DANE — the WORKSPACE-TENANT-PER-CUSTOMER- DOMAIN-TRANSPORT-LAYER-PROTOCOL-CHOICE companion reference. Where THIS page documents the Workspace-tenant DKIM activation discipline (Admin Console Generate-new-record → 2048-bit RSA key-pair generation → per-customer- domain google._domainkey.<customer> TXT publication → Start-authentication flip → manual rotation cadence), the MTA-STS-vs-DANE spoke is the BINARY- TRANSPORT-LAYER-PROTOCOL-CHOICE companion each per-customer-domain Workspace-tenant transport-security publication discipline MUST resolve across four Workspace- tenant protocol-choice dimensions: (1) Workspace inbound-MX infrastructure DNSSEC coverage constraint — the five canonical Workspace inbound MX hostnames (aspmx.l.google.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com) sit under the l.google.com / google.com parent zones which Google does NOT DNSSEC-sign as of 2026 — DANE STRUCTURALLY requires DNSSEC on the MX-hostname parent zone for TLSA-record validation, which means Workspace inbound paths cannot publish DANE TLSA records and force MTA-STS as the only viable transport-security protocol for the Workspace inbound-MX infrastructure regardless of the per- customer-domain operator's preference; (2) Workspace outbound MTA MTA-STS compliance — Workspace's outbound MTAs (the google.com-sourced outbound relays delivering per- customer-domain-signed DKIM mail to external receivers) implement the RFC 8461 §4.3 policy-fetch-and-cache algorithm natively, so the per- customer-domain Workspace operator's outbound TLS-policy-respect coverage is uniform and does not require per- customer-domain DANE/MTA-STS dual- protocol configuration on the Workspace outbound path — the spoke documents the Workspace-outbound-MTA protocol-compliance guarantees the per-customer-domain Workspace operator inherits without additional configuration; (3) per-customer-domain inbound-receiver-population enforcement coverage — the per-customer-domain inbound mail-stream (consumer Gmail / Yahoo / Microsoft 365 / Apple iCloud where MTA-STS dominates vs European B2B t-online.de / GMX / web.de / posteo.de / mail.de where DANE dominates) determines whether the per- customer-domain Workspace operator's receive-side requires only MTA-STS (the typical Workspace small-business consumer-mail use case) or BOTH MTA-STS and DANE coexistence (the Workspace B2B European-market use case where the operator publishes BOTH MTA-STS on Workspace and DANE on a per-domain secondary-MX hosted on a DNSSEC-signed zone) — the per-customer- domain receiver-population mix is the load-bearing per-Workspace-tenant protocol-choice input the spoke documents; (4) per-customer-domain MX-publication-discipline divergence with Workspace — DANE TLSA records would need to key on the _25._tcp.aspmx.l.google.com record etc. (which Google cannot publish without DNSSEC-signing the parent zone); MTA-STS policy files key on the mta-sts.<customer-domain> HTTPS-policy-host at the per-customer- domain apex with the customer operating the HTTPS-policy-host certificate infrastructure — the per- Workspace-tenant per-customer-domain protocol-choice decision is bounded by Workspace's MX-infrastructure DNSSEC- coverage gap to "MTA-STS only" on Workspace, with DANE only available when the per-customer-domain operator configures a per-domain secondary-MX on a DNSSEC-signed zone. Read the MTA-STS-vs-DANE spoke alongside this page when scoping the per-Workspace- tenant per-customer-domain transport- security publication discipline — the binary protocol choice and the Workspace-infrastructure DNSSEC-coverage constraint are the load-bearing transport-layer publication decisions every Workspace-tenant operator MUST resolve per-customer-domain before the per-customer-domain receive-side TLS- enforcement coverage guarantee can be declared consistent with the per- customer-domain Workspace-DKIM-signing identity THIS page documents.
• TLS-RPT record syntax — the WORKSPACE-TENANT-CO-DEPLOYED-DKIM- AND-TLS-RPT-AT-SAME-PER-DOMAIN-DNS-ZONE- PUBLICATION-CADENCE companion documenting the byte-anatomy of the TLS-RPT _smtp._tls.<domain> TXT-record the Workspace operator publishes ALONGSIDE the google._domainkey.<domain> DKIM record this page's Admin Console workflow activates. Where THIS page documents the Workspace-specific DKIM activation workflow (the Admin Console DKIM-key-generation, the google._domainkey.<domain> selector publication, the v=DKIM1; k=rsa; p=<base64> TXT-record byte-shape), the TLS-RPT- record-syntax spoke documents the STRUCTURALLY-CO-DEPLOYED TLS-RPT-record the Workspace operator publishes at the SAME per-domain DNS zone in coordinated publication windows. The four-axis WORKSPACE-TENANT-DKIM-AND-TLS-RPT-CO- DEPLOYMENT comparison exposes the structurally-distinct PER-DOMAIN-DNS- ZONE-PUBLICATION-COORDINATION dimensions: (i) Workspace google._domainkey.<domain> DKIM publication → Workspace _smtp._tls.<domain> TLS-RPT publication at SAME per-domain forward-zone — both records publish at the customer-domain- controlled per-domain forward-zone (Cloudflare / Route 53 / GoDaddy / Squarespace DNS provider tenancy under the customer- controlled apex), both use underscore- prefixed subdomain conventions, both require the same DNS-provider-UI access-credentials to publish; the spoke documents the TLS-RPT-specific byte- anatomy parallel to this DKIM-side publisher byte-anatomy reference, and the operator-side workflow whereby a single DNS-provider-UI session activates BOTH records in coordinated cadence; (ii) Workspace DKIM-rotation per-90-day-cadence publication window → Workspace TLS-RPT rua=-endpoint per-rotation- cadence publication coordination — the per-90-day DKIM-rotation cadence this page's Admin Console workflow embodies STRUCTURALLY PARALLELS the per- TLS-RPT-reporting-endpoint rotation cadence operators apply when reorganizing DMARC-analyzer-vendor tenancy or consolidating the reporting infrastructure — the spoke documents the per-rotation publication-quality KPI operators monitor across BOTH record families in a single DNS-publication-pipeline observability view; (iii) Workspace per-tenant DKIM-publication-quality observability → Workspace per-tenant TLS-RPT- publication-quality observability — this page's Workspace DKIM-monitoring workflow (Admin Console alerting on DKIM-rotation overdue, daily-RUA-monitoring of per-domain DKIM-pass / fail rates) is the per-tenant DKIM-publication-quality observability infrastructure; the spoke documents the structurally-parallel Workspace per-tenant TLS-RPT-publication- quality observability (per-day per-domain TLS-RPT-record-DNS-resolution-availability, per-period transport-failure-report receipt-rate at the rua=-endpoint) the Workspace operator monitors alongside DKIM in the holistic per-tenant DNS-publication- pipeline-health KPI bundle; (iv) Workspace per-tenant cross-protocol co-regression observability across DKIM + TLS-RPT publication families → common-root-cause DNS-publication- pipeline-failure detection — when the Workspace tenant's DKIM AND TLS-RPT records BOTH regress within the same publication window (typical causes: DNS-provider UI bug, mass-publication automation script that mis-published across multiple RR types at the customer- apex), the operator-side detection signal is a co-regression in BOTH the daily- RUA-monitoring (per-domain DKIM-fail-rate spike) AND the per-period TLS-RPT-report- receipt-rate (per-domain TLS-RPT-report- receipt absence); the spoke documents the TLS-RPT-side regression-detection observability surface as the STRUCTURALLY-PARALLEL co-detection infrastructure to this DKIM-side regression-detection surface in the Workspace tenant operator's holistic DNS-publication-pipeline-health KPI dashboard. Read the TLS-RPT-record- syntax spoke when the Workspace tenant operator's per-domain DKIM-publication discipline at the Admin Console activation boundary is being extended to the per-domain TLS-RPT-publication boundary at the same customer-domain forward-zone — the spoke is the byte- anatomy reference whose STRUCTURALLY-CO-DEPLOYED publication cadence the Workspace operator already has the DKIM-publication-discipline muscle-memory for.
• DKIM for Microsoft 365 — the sibling per-mailbox-provider DKIM guide. Compare the CNAME-delegation dual-selector M365 model with this page's TXT-publication single-selector Workspace model side by side.
• DKIM explained — the protocol primer covering RFC 6376 mechanics, signing pipeline, header canonicalization, and the Authentication-Results stack.
• DKIM-Signature header format — the WORKSPACE-DKIM-SIGNED-EGRESS-PER-MESSAGE- HEADER-BYTE-LAYOUT companion to this Workspace-DKIM-activation procedure. Where THIS page documents the Workspace Admin Console workflow at admin.google.com → Apps → Google Workspace → Gmail → Authenticate email and the per-tenant publisher-side TXT-record activation lifecycle (Generate new record → manual DNS publication at google._domainkey.<domain> → Start authentication → DKIM-signed egress), the DKIM-signatures-explained spoke documents the BYTE-LAYOUT of the actual DKIM-Signature: header that Workspace's signing gateway prepends to every outbound message once the activation flips on — the canonical RFC 6376 §3.5 tag-value grammar covering the eight load-bearing tags every receiver parses to verify Workspace egress: (i) v=1 version (RFC 6376 requires literal "1"; any other value = invalid), (ii) a=rsa-sha256 algorithm (Workspace's default; the legacy rsa-sha1 is deprecated per RFC 8301 and Workspace does NOT emit it), (iii) d=<domain> signing domain (the Workspace tenant's primary domain; the receiver compares this against the From: header's organizational-domain for DMARC alignment — the cross-link to the DMARC-alignment spoke this page already documents), (iv) s=google selector (the Workspace default; rotation produces a second selector for the overlap window per the dkim-key-rotation spoke), (v) c=relaxed/relaxed canonicalization (the Workspace default; the cross-link to the dkim-canonicalization spoke), (vi) h=<header-list> signed-header roster (Workspace signs the canonical From, To, Subject, Date, Message-ID, MIME-Version, Content-Type roster plus a handful of message-specific headers per the signing-policy table the gateway maintains), (vii) bh=<base64> body-hash (the SHA-256 hash of the canonicalised body, computed before the signature is signed), (viii) b=<base64> signature value (the RSA-signed hash of the canonicalised signed-headers list + body-hash). Read the dkim-signatures- explained spoke when DEBUGGING a Workspace DKIM verification failure surfacing in receiver Authentication- Results (the receiver-side spec-cross- reference for "what tag in the DKIM-Signature header is the verifier complaining about") OR when AUTHORING a receiver-side DKIM-verification policy that interacts with Workspace-signed egress (the receiver-side bytes Workspace produces are what the verifier consumes). The dkim-signatures-explained spoke completes the Workspace-DKIM publisher- side STACK: dkim_explained = protocol primer, dkim_dns_syntax = published-key TXT-record byte format, dkim-signatures- explained = per-message DKIM-Signature header byte format, dkim_canonicalization = the c= tag's body-and-header transformation, dkim_selectors_explained = the s= tag's selector-rotation semantics.
• DKIM canonicalization — the deep dive on the c=relaxed/relaxed tag Workspace uses by default and the simple-vs-relaxed tradeoff.
• DKIM selectors explained — the cross-provider selector deep dive with the full per-provider naming catalogue (Workspace google, M365 selector1/selector2, cPanel default, SendGrid s1/s2, etc.).
• DKIM key rotation — the cross-provider rotation cadence reference. Workspace's annual manual rotation sits at the operator-controlled end of the spectrum; an M365 rotation is also started by the administrator but needs no DNS change.
• DNS propagation explained — the WORKSPACE-DKIM-ACTIVATION-GATED-BY- TTL-BOUNDED-RESOLVER-CACHE-AGEING-WINDOW companion to this Workspace DKIM activation reference. Where THIS page documents the Workspace-side Admin console workflow (Apps → Google Workspace → Gmail → Authenticate email → Generate new record → publish google._domainkey.<domain> TXT at the apex DNS provider → wait 24–72 hours → click Activate DKIM), the dns-propagation spoke documents the OPERATIONAL CAUSE of the wait 24–72 hours step: the TTL-bounded resolver-cache ageing window across the recursive-resolver population Workspace's signed egress mail traverses. Four WORKSPACE-DKIM-ACTIVATION-VS-DNS- PROPAGATION axes the spoke catalogues: (i) authoritative-TXT-publication- to-receiver-resolver-cache-observation propagation — operators publishing the google._domainkey TXT at the apex provider's DNS see the record live at the authoritative nameserver within seconds, but receiver-side recursive resolvers (Gmail, Microsoft 365, Yahoo, Mail.ru) cache the previous NXDOMAIN response for the negative-cache SOA-min-TTL window (default 3600s) per RFC 2308, producing the dkim=permerror verdict the 24-72 hour Workspace wait protects against; (ii) per-resolver TTL diversity — Workspace's wait 24–72 hours guidance is Workspace's empirical-floor estimate of the longest-tail receiver-resolver TTL cache window (some receivers honor the authoritative TTL while others clamp to a vendor-internal minimum-or-maximum); (iii) RFC 8767 serve-stale re-emergence — even after the authoritative TTL expires, a receiver configured per RFC 8767 may serve a stale (pre-publication) NXDOMAIN response for hours under upstream-failure conditions, producing rare delayed dkim=permerror spikes after the Workspace Activate button is clicked; (iv) per-receiver Authentication-Results dns-error attribution vocabulary — Gmail's Authentication-Results: ...; dkim=temperror reason="dns timeout" verdict is the per-message symptom the Workspace operator interprets via the propagation spoke's RFC 1035/2181/8767 propagation model. Operators activating Workspace DKIM need the propagation spoke's per-receiver cache-ageing model to understand WHY the wait 24–72 hours step exists and WHEN it is safe to click Activate.
• DKIM replay attacks — the threat-model deep dive on signature-replay risk; manual rotation cadence is the operator-side defense against extended dwell time.
• DKIM best practices — the GOOGLE-WORKSPACE-DKIM-ACTIVATION-AS- PLATFORM-INSTANCE-OF-THE-13-RULE-OPERATOR- DISCIPLINE-CHECKLIST companion documenting the abstract 13-rule DKIM operator-discipline synthesis whose Workspace-specific instantiation this page operationalises. Where THIS page documents the PLATFORM-SPECIFIC Workspace DKIM activation procedure (the Admin Console Generate-new-record + Start-authentication workflow, the google._domainkey single-selector default, the manual annual key rotation cadence, the gappssmtp.com alignment gotcha, the 2048-bit TXT-record split-string publication mechanics), the DKIM-best-practices spoke is the PLATFORM-AGNOSTIC OPERATOR-DISCIPLINE SYNTHESIS layer documenting the 13 rules EVERY DKIM-publishing operator must internalise regardless of mailbox provider: the 2048-bit RSA / Ed25519 algorithm floor, the per-selector key-isolation rule, the 6-to-12-month rotation cadence, the relaxed-relaxed canonicalisation default, the x= expiration discipline for replay-mitigation, the post-DMARC alignment-with-DMARC discipline, the DKIM-failure-monitoring discipline via RUA aggregate reports, and the seven-additional-rules covering selector hygiene, public-key retirement, signing algorithm migration, and the platform-portability discipline that lets an operator move from Workspace to M365 without breaking deployed DKIM trust. Read the DKIM-best-practices spoke when scoping the Workspace DKIM deployment against the platform-agnostic operator-discipline floor — the 13-rule checklist is the rubric against which the Workspace-specific activation procedure THIS page documents is evaluated for operator-discipline compliance.
• DKIM troubleshooting — the symptom-driven debugging companion for the Workspace-specific DKIM failure patterns this page documents. The canonical Workspace DKIM failure modes — the gappssmtp.com DMARC-alignment gotcha (DKIM passes with d=gappssmtp.com but DMARC alignment fails because the d-domain isn't the public sending domain), the 72-hour DNS-propagation wait after Generate-new-record before Start authentication, the 2048-bit TXT-record split-string handling at registrars (Cloudflare auto-splits, GoDaddy requires manual 255-byte chunks, BIND requires (...) (...) concatenation), the SMTP-Relay-Service unsigned-outbound edge case (DKIM signing happens at Gmail egress, not relay egress, so bypassed messages produce dkim=none) — all map to specific symptom paths in the troubleshooting page. Read this when the Workspace DKIM deployment is in place but Authentication-Results headers or aggregate-report payloads show unexpected dkim=fail / dkim=permerror / dkim=temperror / dkim=none results.
• DKIM failures explained — the WORKSPACE-TENANT-DKIM-FAILURE- CLASS-CATALOGUE companion to this Workspace-DKIM-deployment reference. Where THIS page documents the Workspace DKIM ACTIVATION procedure (the admin.google.com → Apps → Google Workspace → Gmail → Authenticate email Admin Console workflow, the google._domainkey.<domain> TXT publication topology, the Workspace-managed 2048-bit RSA key, the "Start authentication" cut-over to DKIM-signed outbound mail), the DKIM-failures-explained spoke is the FAILURE-CLASS-TAXONOMY companion documenting WHY the Workspace-egress mail-stream surfaces specific dkim=fail / dkim=permerror / dkim=temperror / dkim=none verdicts at the receiver-side Authentication- Results header AND in the per-row auth_results.dkim.result field of RUA aggregate-report XML. Concretely, the spoke documents FOUR Workspace-DKIM-failure-class- attribution dimensions: (i) body-hash-mismatch as the canonical post-egress in-flight-tampering Workspace DKIM failure — when Workspace-egress mail crosses a mailing-list footer-appender, a content-transform proxy, or any Subject-prefix rewriter, the receiver-side body-hash recomputation of the canonicalized body diverges from the Workspace-signed bh= tag value and the DKIM-failures-explained spoke documents the byte-level canonicalization mechanism (RFC 6376 §3.4 simple vs relaxed body canonicalization) that produces the receiver-side dkim=fail (body hash did not verify) verdict; (ii) selector-DNS-NXDOMAIN as the Workspace-publication- propagation-incomplete DKIM failure class — when the Workspace Admin Console says DKIM activation is complete but the google._domainkey.<domain> TXT record is not yet propagated (or has been accidentally deleted by a DNS-zone-import overwrite), the receiver-side selector lookup returns NXDOMAIN and surfaces as dkim=permerror (no key for signature) — the spoke documents the selector-NXDOMAIN class as one of the seven canonical DKIM- permerror subclasses receivers distinguish; (iii) signature- cryptographic-mismatch as the Workspace-key-mid-rotation DKIM failure — when a Workspace operator rotates from the default google selector to a second google2 rotation selector but the published TXT under the new selector contains a stale public-key blob (DNS-publication race with key-generation in the Admin Console), the receiver-side cryptographic verification returns dkim=fail (signature did not verify) — the spoke documents the cryptographic-mismatch class distinctly from the body-hash-mismatch class because the operational remediation differs (re-export the public key from Admin Console vs investigate in-flight content modification); and (iv) SMTP-Relay-Service-emitted dkim=none as the Workspace-egress- bypassed unsigned-mail class — Workspace's SMTP relay service does NOT apply Workspace-egress DKIM signing to mail submitted by on-prem MTAs or third-party applications relaying through smtp-relay.gmail.com, and the spoke documents the dkim=none verdict class (unsigned at the egress boundary) the receiver-side Authentication- Results surfaces for SMTP-relay- bypassed mail-streams — DISTINCT from dkim=fail (signed but failed verification) and from dkim=permerror (DNS- publication broken). Read the DKIM-failures-explained spoke alongside this Workspace DKIM deployment guide when the Workspace operator advances past activation into operational monitoring of per-message DKIM verdicts via Authentication-Results and per-row RUA aggregate-report attribution — the spoke provides the receiver-side verdict-class taxonomy the Workspace egress topology this page documents produces in the field.
• DKIM cryptography basics — the cryptographic primer covering RSA-SHA256 (Workspace's default algorithm), 2048-bit key sizes, and the public-key verification chain.
• DMARC alignment — the alignment engine that consumes DKIM d= tags. The gappssmtp.com gotcha is fundamentally an alignment failure.
• DMARC for Microsoft 365 — the sibling per-mailbox-provider DMARC deployment guide for operators with mixed M365 + Workspace estates.
• ARC explained — the Authenticated Received Chain protocol that preserves DKIM verdicts across forwarding hops. Pair with Workspace's outbound DKIM for inbound flow protection on forwarded mail.
• BIMI explained — the PER-WORKSPACE-TENANT-DKIM-ALIGNED- PASS-AS-UPSTREAM-PRECONDITION-FOR-PER- WORKSPACE-TENANT-BIMI-RENDERING-AT-GMAIL companion to this Workspace-tenant DKIM deployment guide. Where THIS page documents the per-Workspace-tenant DKIM activation discipline (the Admin Console Authenticate Email setting that creates the google._domainkey. <Workspace-author-domain> DNS-publication directive, the 2048-bit RSA key-pair generation Google performs on the publisher's behalf, the per-Workspace-tenant outbound DKIM signing at the Gmail SMTP egress boundary), the BIMI-explained pillar documents the per-Workspace-tenant BRAND-TRUST-MONETISATION OUTCOME the per-Workspace-tenant DKIM-aligned-pass verdict STRUCTURALLY UNLOCKS at the per-Gmail-recipient consumer-inbox-view: (i) the per-Workspace-tenant authoritative DNS publishes a default._bimi. <Workspace-author-domain> BIMI TXT RR carrying v=BIMI1; + the per-tenant brand-logo SVG-Tiny-PS URL + the per-tenant VMC URL; (ii) Gmail's BIMI- rendering policy (the CANONICAL receiver- side BIMI rollout target for Workspace- tenant outbound mail) verifies BOTH the per-message DKIM-aligned-pass verdict from THIS page's signing infrastructure AND the per-Workspace-tenant DMARC terminal-enforcement state at p=quarantine or p=reject at the moment of per-message rendering — neither precondition alone suffices; (iii) the per-Workspace-tenant per-day per-author- domain rolling-average of per-message DKIM-pass rate from THIS page's google._domainkey selector directly determines whether Gmail's BIMI rendering cache renders the brand- indicator at the per-Workspace-tenant's outbound message receiver-side inbox; and (iv) the per-Workspace-tenant VMC trademark-bound certificate-chain verification is itself a per-message DOWNSTREAM CONSUMER of the per-message DKIM-d=-tag canonical author-domain identity that THIS page's Workspace-tenant signing infrastructure produces at signing time. Read this WITH the Workspace-tenant DKIM activation guide when the Phase 6 brand-trust- monetisation question moves to the operator's queue: THIS page documents the per-Workspace-tenant DKIM signing infrastructure, the BIMI-explained pillar documents the per-Gmail-recipient brand-indicator rendering OUTCOME that Workspace-tenant signing infrastructure STRUCTURALLY UNLOCKS.
• BIMI Verified Mark Certificates (VMC) — the PER-WORKSPACE-TENANT-BIMI-VMC- PUBLICATION-AS-DISPLAY-LAYER-BRAND- INDICATOR-DOWNSTREAM-CONSUMER-OF-PER- WORKSPACE-TENANT-DKIM-SIGNING-IDENTITY companion to this Workspace-tenant DKIM deployment guide. Where THIS page documents the per-Workspace- tenant DKIM signing-identity deployment via the Workspace Admin Console "Generate new record" workflow + per-tenant google._domainkey.<org-domain> TXT-RR publication + dual-selector rotation discipline + per-tenant Gmail egress IP-pool DKIM-signing infrastructure dependency, the BIMI VMC spoke is the PER-TENANT DISPLAY- LAYER PUBLISHER-CRYPTOGRAPHIC- ATTESTATION companion documenting the per-Workspace-tenant X.509 Verified Mark Certificate publication whose per-tenant CA-issued brand- cryptographic-attestation gates the per-Gmail-recipient BIMI-display eligibility evaluation. The four-axis WORKSPACE-TENANT-DKIM-VS-BIMI-VMC comparison exposes the structurally- distinct per-Workspace-tenant cross-layer cryptographic-attestation couplings: (i) per-Workspace- tenant DKIM signing produces the per-message Authentication-Results DKIM verdict every Gmail recipient receives; per-Workspace-tenant BIMI VMC publication gates the brand- indicator display every Gmail recipient sees IF and ONLY IF the per-tenant DMARC-aligned-pass at p=quarantine or p=reject is achieved — Gmail consumes the per-tenant DKIM-aligned-pass verdict THEN the per-tenant BIMI VMC + SVG asset chain to surface the brand-indicator at display- time; (ii) per-Workspace- tenant BIMI VMC publication requires per-tenant DMARC p=quarantine or p=reject (Gmail enforces this BIMI-display-eligibility threshold); per-tenant DMARC p=quarantine / reject requires per-tenant DKIM- aligned-pass rate above the operational safety threshold — Workspace operators consolidating per-tenant DKIM deployment into a BIMI-display-eligible posture must first reach DKIM-aligned-pass stability THEN ramp DMARC p= to quarantine/reject BEFORE publishing the per-tenant default._bimi.<tenant>.<tld> TXT-RR with the per-tenant a= VMC URI; (iii) per-Workspace-tenant Gmail is the DOMINANT receiver consuming the per-tenant BIMI VMC display eligibility — Gmail's BIMI-display-eligibility evaluator is one of the load-bearing per-receiver BIMI consumers (alongside Apple Mail / Yahoo / Fastmail); per-Workspace-tenant operators expose their tenant to per-Gmail brand-indicator display evaluation that the same operator cannot disable from the publisher side beyond removing the BIMI TXT-RR or letting the VMC lapse; (iv) per-Workspace-tenant BIMI VMC publication has the same TXT-RR-publication operational discipline as per-tenant DKIM TXT-RR publication this page documents (per-tenant DNS-edit via the org-domain DNS host; per-tenant 255-byte-chunk concatenation for long values; per-tenant propagation budget wait) — operators already executing per-tenant DKIM TXT-RR publication via this guide apply the same DNS-edit + propagation-wait discipline to per-tenant BIMI default._bimi TXT-RR publication. Read the BIMI VMC spoke alongside this Workspace DKIM deployment guide when scoping the per-Workspace- tenant cross-layer brand-display publication posture — the spoke documents the per-tenant CA- issued display-layer cryptographic- attestation publication that consumes the per-tenant DKIM- aligned-pass + DMARC p= posture this Workspace DKIM guide establishes upstream.
• DMARC policy rollout — the PER-WORKSPACE-TENANT DKIM-ACTIVATION-AS-LOAD-BEARING-PHASE-1- PUBLICATION-BASELINE-PREREQUISITE companion to this Workspace DKIM- activation guide. Where THIS page documents the per-Workspace-tenant Admin Console → Apps → Gmail → Authenticate email → Generate-new-record → Publish- google._domainkey-TXT → Start- authentication activation workflow that flips the tenant from unsigned to DKIM-signed egress under the google._domainkey.<domain> selector, the DMARC-policy-rollout spoke documents the per-Workspace- tenant five-phase rollout workflow whose every per-pct=-ramp-stage advancement and per-phase cutover gate depends on this Workspace DKIM- activation floor at FOUR per-Workspace- tenant-DKIM-activation-to-DMARC- policy-rollout coupling dimensions: (i) Phase-1 per-Workspace- tenant DKIM-activation publication- baseline as load-bearing receiver-side dkim=pass-verdict-availability prerequisite for the per-Workspace- tenant rollout to launch — the Phase-1 publication-baseline floor REQUIRES the Workspace Admin Console "Start authentication" button to have been clicked AND the per-tenant google._domainkey.<domain> TXT-record to have been published AND DNS-propagated for the receiver-side dkim=pass verdict to be emitted in the FIRST place against Workspace-egress mail; any per-Workspace- tenant DKIM-activation defect (Start- authentication button not yet clicked, google._domainkey TXT publication-failure, post-rotation key- mismatch during the Workspace 30-day new-record-grace-window) collapses Phase-1 to dkim=fail / dkim=none / dkim=permerror and blocks the Workspace tenant from launching the per-tenant policy rollout; (ii) Phase-2 p=none baseline- observability per-Workspace-tenant DKIM-aligned-pass-rate-floor enforcement as Postmaster-Tools-driven Workspace- egress aggregate-XML row/auth_results/dkim/result=pass row-count input — the Phase-2 observability baseline REQUIRES the per- Workspace-tenant google._domainkey publication-discipline floor to be in place across every per-tenant per- primary-domain per-domain-alias deployment before advancing into Phase- 3 — the per-source-IP per-receiver per- day rua aggregate-XML row/policy_evaluated/dkim=pass row-count distribution (alongside the Workspace-tenant Postmaster Tools per- receiver-cohort DKIM-aligned-pass-rate dashboard) is the gate-keeping observability surface that confirms the Workspace-tenant DKIM activation is reliably translating into receiver- side dkim=pass verdicts at the per- Workspace-tenant per-domain-alias floor required for Phase-3 advancement; (iii) Phase-3 per-Workspace- tenant pct=-ramp per-stage advancement gate-keeping DKIM-aligned-pass-rate- floor enforcement as per-ramp-stage- cutover-confidence input — every Phase-3 per-stage advancement (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) REQUIRES the per-Workspace-tenant DKIM-aligned- pass-rate floor to remain stable across the per-tenant per-primary-domain per- domain-alias deployment; any per-stage DKIM-aligned-pass-rate regression caused by a per-Workspace-tenant DKIM- activation discipline drift (key- rotation-cutover-during-pct=-ramp, new-domain-alias-onboarded-without- Start-authentication, Workspace 4096-bit key-length-upgrade-cutover) must be remediated BEFORE advancing the per- stage cutover; (iv) Phase-4- p=quarantine and Phase-5-p=reject per- Workspace-tenant cutover-confidence floor as Workspace-egress per-receiver per-source-IP DKIM-aligned-pass-rate- coverage-completeness prerequisite — the terminal-state Phase-4-p=quarantine and Phase-5-p=reject cutovers REQUIRE the per-Workspace-tenant DKIM-activation floor to be in place across every per- tenant per-primary-domain per-domain- alias per-receiver Workspace-egress deployment with zero outstanding Workspace-DKIM-activation discipline defects — the terminal-state cutover is the point where any remaining Workspace DKIM-activation drift translates directly into Workspace-egress legitimate-mail-bounce-rate uplift, so the per-receiver per-source-IP Workspace- egress DKIM-aligned-pass-rate-coverage- completeness floor must be empirically confirmed via the rua aggregate-XML stream AND the Workspace Postmaster Tools per-receiver dashboard BEFORE the terminal-state cutover. Read the DMARC-policy-rollout spoke alongside THIS page when the Workspace-tenant operator asks "how does the per- Workspace-tenant Admin Console DKIM- activation workflow translate into the per-tenant five-phase DMARC-policy- rollout cadence" — the answer is FOUR- LAYERED: THIS page documents the per- Workspace-tenant Admin Console DKIM- activation workflow, the DMARC-policy- rollout spoke documents the per- Workspace-tenant five-phase deployment workflow whose every per-pct=-ramp- stage advancement and per-phase cutover gate consumes the Workspace-egress DKIM-aligned-pass-rate floor THIS page's google._domainkey activation underpins.
• SPF for Microsoft 365 — the CROSS-CLOUD-PROVIDER-PER-CLOUD- TENANT-AUTHENTICATION-PUBLICATION- TOPOLOGY-PARALLEL companion to this per- Workspace-tenant DKIM deployment reference. Where THIS page documents the per-Workspace-tenant google._domainkey.<domain> DKIM-CNAME-delegation publication topology (the Admin Console "Authenticate email" activation workflow, the per- tenant google-issued public-key bytes Google publishes at the google._domainkey.<Workspace- author-domain> selector, the per-tenant key-rotation cadence, the per-tenant DKIM-signing-egress invariant the Authenticate-email button toggles), the spf_for_microsoft_365 spoke documents the structurally-parallel per- M365-tenant SPF-include-cascade publication topology at FOUR cross- cloud-provider per-cloud-tenant authentication-publication dimensions: (i) per-M365-tenant include:spf.protection.outlook.com SPF-include-cascade publication topology AS STRUCTURAL-PARALLEL TO per- Workspace-tenant google._domainkey.<domain> DKIM-CNAME-delegation publication topology — both are per-cloud- tenant per-DNS-record publication primitives where the cloud-provider operates the canonical egress- authorization infrastructure and the per-tenant operator publishes a delegated DNS-record at a fixed- convention per-tenant DNS-namespace (per-Workspace-tenant google._domainkey selector vs per-M365-tenant include:spf.protection.outlook.com cascade); the spf_for_microsoft_365 spoke documents the M365-side per- tenant SPF-publication topology whose publication-discipline operators familiar with Workspace-side DKIM- publication topology can transfer directly to; (ii) per-M365- tenant include:spf.protection.outlook.com cascade RFC 7208 §4.6.4 ten-DNS-lookup ceiling consumption AS STRUCTURAL- PARALLEL TO per-Workspace-tenant google._domainkey selector per-tenant DNS-publication-byte-budget consumption — M365's per- tenant SPF cascade consumes 5+ of the ten-DNS-lookup ceiling budget structurally paralleling how Workspace's per-tenant google._domainkey selector consumes per-zone TXT-record byte-budget; the spf_for_microsoft_365 spoke documents the per-M365-tenant publication-budget discipline whose preservation parallels the per- Workspace-tenant publication-budget discipline THIS page documents at the cross-cloud-provider per-tenant publication-budget-discipline boundary; (iii) per-M365-tenant SPF- include-cascade ALIGNMENT WITH per- publisher DMARC aspf=relaxed / aspf=strict alignment- mode publication AS APPLICATION-LAYER DMARC-ALIGNMENT-COMMITMENT-PARALLEL TO per-Workspace-tenant DKIM-d-tag alignment with per-publisher DMARC adkim=relaxed / adkim=strict alignment- mode publication THIS page's DKIM- deployment depends on at receiver-side DMARC-alignment evaluation time — both per-cloud-tenant authentication- publication topologies must coordinate with the per-publisher DMARC alignment- mode publication; the spf_for_ microsoft_365 spoke documents the per- M365-tenant SPF-alignment-mode coordination whose structural parallel to the per-Workspace-tenant DKIM- alignment-mode coordination operators master for one cloud-provider transfers directly to the other; (iv) per- M365-tenant SPF-include-cascade per- source-IP authorization-failure- evidence emitted in per-Workspace- tenant DMARC-rua aggregate-reports AS STRUCTURAL-PARALLEL TO per-Workspace- tenant DKIM-aligned-pass-rate evidence emitted in per-M365-tenant DMARC-rua aggregate-reports — when Workspace-tenant-authored mail is delivered to M365-tenant recipient domains, the cross-cloud-provider rua- aggregate-report-emitter records per- source-IP-per-disposition rows attributing both the per-Workspace- tenant DKIM-aligned-pass verdict AND the per-Workspace-tenant SPF-aligned- pass verdict (and vice versa for M365- authored mail delivered to Workspace recipient domains); the spf_for_ microsoft_365 spoke documents the per- M365-tenant SPF-aggregate-evidence emission discipline whose structural parallel to the per-Workspace-tenant DKIM-aggregate-evidence emission discipline THIS page documents is the canonical cross-cloud-provider per- tenant authentication-observability- feedback-loop pattern. Read the spf_ for_microsoft_365 spoke alongside this Workspace DKIM deployment reference whenever the cross-cloud-provider operator scopes a per-cloud-tenant- authentication-publication coordination plan — the per-M365-tenant SPF-include- cascade publication topology the spoke catalogues IS the cross-cloud-provider sibling-pattern to the per-Workspace- tenant DKIM-CNAME-delegation publication topology THIS page operationalises at the cross-cloud-provider per-cloud- tenant authentication-publication- topology boundary.
• Google Workspace Admin Console — the operator entry point for DKIM management.
• Google Workspace Help: Set up DKIM to prevent email spoofing — the canonical primary-source Google documentation for DKIM on Workspace.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, and ARC results.
• Domain Security Checker — live DNS lookups for every email- authentication record on a domain. Surfaces the published google._domainkey TXT and confirms the v=DKIM1 record syntax.
• DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• BIMI SVG Tiny PS logo requirements — the PER-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-BIMI-SVG-COMPLIANCE-COORDINATION companion to this Workspace-tenant DKIM reference. Where THIS page documents the per-Workspace-tenant per-custom- domain DKIM publication workflow (Workspace Admin Console "Authenticate email" panel produces the per-tenant 2048-bit keypair + publishes the google._domainkey.<custom-domain> TXT record + manages the half-yearly rotation), the BIMI SVG requirements spoke documents the STRUCTURALLY-PARALLEL per-Workspace-tenant per-custom-domain BIMI-SVG-asset authoring-discipline whose per-tenant Tiny PS profile compliance is the per-tenant BIMI-logo- display readiness gate at FOUR per- Workspace-tenant per-custom-domain BIMI- SVG-compliance dimensions: (i) per-Workspace-tenant per-custom- domain SVG-asset Tiny PS byte-format compliance as per-tenant logo-display readiness gate parallel to per- Workspace-tenant per-custom-domain google._domainkey DKIM- publication readiness gate - each Workspace-tenant per-custom-domain default._bimi.<custom-domain> TXT-record l= URL must resolve to an SVG conforming byte-for- byte to the Tiny PS profile (root attributes correct + required elements present + forbidden elements absent + ≤32 KiB) the BIMI evaluator's parser accepts at the per-tenant per-custom- domain BIMI-asset-publication readiness moment, paralleling the per-tenant per-custom-domain google._domainkey DKIM- publication readiness gate already in place; (ii) per-Workspace-tenant per-custom-domain SVG-asset 1:1 aspect- ratio + viewBox 0-512 numeric bounds as per-tenant per-custom-domain logo- asset uniformity contract independent of the per-tenant per-custom-domain DKIM publication discipline - the Workspace-tenant operator must re-cut every per-custom-domain brand- mark SVG to the Tiny PS 1:1 + 0-512 viewBox numeric bounds independently of the per-tenant google._domainkey publication workflow; (iii) per- Workspace-tenant per-custom-domain SVG-asset <script> / <foreignObject> / <animate> / <image> / external- ref forbidden-element-class compliance as per-tenant per-custom-domain security-posture parallel to per-Workspace-tenant per-custom-domain DKIM p=base64-pubkey cryptographic-integrity-posture - the BIMI Tiny PS profile forbids every SVG element-class capable of executing client-side code or retrieving external resources, with the per-Workspace-tenant per-custom-domain operator validating per-asset compliance independently of the per-tenant per-custom-domain DKIM p=-tag-base64-pubkey publication discipline; and (iv) per-Workspace-tenant per- custom-domain SVG-asset BIMI Group svg_validator CI- integration as per-tenant per-custom- domain pre-publication compliance gate parallel to per-Workspace-tenant per- custom-domain opendkim-testkey or Admin-Console-DKIM-self-test pre- rotation gate - the BIMI Group's reference svg_validator integrates into the per-Workspace-tenant per- custom-domain CI pipeline to gate pre-publication SVG-asset acceptance, structurally paralleling the per- Workspace-tenant per-custom-domain opendkim-testkey or Admin-Console DKIM self-test pre- rotation gate the Workspace DKIM publication discipline THIS page documents already employs. Pair THIS Workspace-tenant DKIM reference with the BIMI SVG requirements spoke when the per-Workspace-tenant per-custom- domain operator engages the BIMI- logo-display-publication phase as the per-tenant per-custom-domain cryptographic-anti-spoofing-and-end- user-visible-trust-signal reinforcement layer on top of the google._domainkey DKIM publication foundation.
• DMARC for Microsoft 365 hybrid Exchange — the cross-major-mailbox-provider Workspace ↔ M365-hybrid per-tenant per-custom-domain DKIM-deployment-peer companion to this Workspace-tenant DKIM-signing reference. Where THIS page documents the Workspace-tenant single- selector operator-published TXT-record google._domainkey.<d> DKIM-signing deployment workflow (Admin Console > Apps > Workspace > Gmail > Authenticate email; per-tenant per-custom-domain 2048-bit RSA modulus; per-tenant Authenticate-email-Start activation), the hybrid-Exchange spoke documents the STRUCTURAL-PEER per-M365- tenant dual-outbound-boundary DKIM- signing deployment for the cross-major- provider hybrid Exchange Online + on- prem Edge Transport coexistence topology. The WORKSPACE-VS-HYBRID-M365 cross- reference establishes FOUR coupling dimensions: (i) per-tenant per- custom-domain DKIM-signing publication-substrate parallel — Workspace single-selector google._domainkey TXT-RR vs M365-hybrid dual-selector selector1._domainkey + selector2._domainkey CNAME delegation; both per-provider per-portfolio publications are required before the cross-provider DMARC ramp proceeds; (ii) per-portfolio DMARC ramp blocked when per-provider- per-portfolio DKIM-signing absent — Workspace tenants must publish google._domainkey BEFORE the Workspace-portion DMARC pct=100 ramp, hybrid M365 portfolios must complete the per-tenant CNAME delegation on BOTH cloud-EXO and on- prem Edge boundaries; the hybrid spoke documents the per-boundary per-tenant publication-precondition contract Workspace operators porting a portfolio to or from M365 hybrid rely on; (iii) per-provider per-portfolio per-tenant rotation operational discipline transfer — Workspace per-tenant rotation cadence and M365-hybrid dual-selector rotation cadence share the per-portfolio per- provider DNS-propagation-aware overlap-window operational discipline; the hybrid spoke documents the per-M365-hybrid-boundary rotation discipline that transfers directly from this Workspace per- tenant Rotate-DKIM-Keys cadence; (iv) per-major-provider per- tenant DKIM-activation-toggle publication as load-bearing application-layer cryptographic-pass primitive — Workspace Authenticate-email-Start activation and M365-hybrid Exchange-Admin-Center DKIM-Enable activation on BOTH cloud EXO and on-prem Edge Transport are the per-portfolio per-provider per- tenant cryptographic-publication primitives; the hybrid spoke documents the per-M365-hybrid-boundary DKIM-Enable contract whose per-tenant per-custom-domain activation parallels this Workspace Authenticate-email-Start activation. Read the M365-hybrid spoke alongside this Workspace DKIM reference when operating a publisher portfolio with Workspace ↔ M365-hybrid cross- major-mailbox-provider per-tenant per-custom-domain DKIM-signing- deployment-peer publication discipline.
• RFC 6376 — DKIM Signatures
• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — the key-size requirements: at least 1024 bits, 2048 recommended.
• TLS-RPT explained — the canonical protocol-layer TLS-RPT reference whose per- receiver per-publisher per-day aggregate JSON evidence stream is the load-bearing per-message DKIM-Signature header in-transit integrity-observability prerequisite the per-Workspace- tenant google._domainkey DKIM activation discipline THIS page documents depends on at four Workspace-tenant-to-TLS-RPT- observability resolution dimensions: (i) the per-Workspace- tenant outbound-egress per- receiver TLS-handshake-success- rate aggregate is the canonical load-bearing per-tenant per- egress-path transport- confidentiality input into the per-message DKIM-Signature header in-transit-integrity evaluation — per-Workspace- tenant outbound mail egresses through the canonical _spf.google.com include-cascade authorised source-IP pool whose per- source-IP TLS-handshake outcomes flow into the per- receiver per-Workspace-tenant per-day RFC 8460 JSON- aggregate stream THIS TLS-RPT reference IS the canonical publisher-side observability feed for; (ii) the per- Workspace-tenant _smtp._tls.tenant.example.com TLS-RPT TXT record publication discipline is the canonical load-bearing per-Workspace- tenant publisher-side publication-prerequisite for the per-Workspace-tenant per- receiver per-day RFC 8460 JSON- aggregate evidence stream — the per-Workspace-tenant admin publishes the TLS-RPT TXT record at the per-tenant accepted-domain _smtp._tls subdomain via the Admin Console DNS workflow, and the per- receiver per-Workspace-tenant per-day RFC 8460 JSON-aggregate TLS-handshake-evidence stream is delivered to the per- Workspace-tenant rua-mailbox the TLS-RPT reference IS the canonical configuration framework for; (iii) the per- Workspace-tenant Postmaster Tools TLS-observability coverage discipline is the canonical load-bearing per- Workspace-tenant per-receiver Gmail-side TLS-handshake-rate regression-monitoring infrastructure — Postmaster Tools surfaces per-Gmail- receiver per-Workspace-tenant TLS-handshake-success-rate per-day aggregates the Workspace operator triages against the per-Workspace- tenant per-receiver TLS-RPT JSON-aggregate emission the TLS-RPT reference IS the canonical multi-receiver cross-validation framework for; and (iv) the per- Workspace-tenant DKIM-key- rotation cutover discipline is the canonical load-bearing per-tenant rotation-cadence coordination input — per- Workspace-tenant per- DKIM-key rotation events coincide with per-receiver per-source-IP TLS-handshake- rate baseline-shift windows the TLS-RPT aggregate stream IS the canonical per- Workspace-tenant per- receiver transport-confidentiality- baseline observability feed for, ensuring the rotated DKIM-Signature header survives per-receiver transport without per- source-IP TLS-handshake baseline disruption. Read the TLS-RPT spoke ALONGSIDE this per- Workspace-tenant DKIM- activation reference whenever the per-Workspace- tenant admin scopes a per- Workspace-tenant per- egress-shard TLS-transit- observability coordination plan — the per-Workspace- tenant google._domainkey DKIM-activation discipline THIS page documents IS the load-bearing per-Workspace- tenant per-message DKIM- Signature-header-in-transit integrity gate the per- receiver per-Workspace- tenant per-day RFC 8460 JSON-aggregate transport- layer-observability stream the TLS-RPT spoke documents IS the canonical publisher- side per-receiver per- Workspace-tenant per- source-IP TLS-handshake- coverage observability feed for.
• DKIM alignment with DMARC — the PER-WORKSPACE-TENANT-DKIM-d-TAG-VS- RFC5322-FROM-DOMAIN-ALIGNMENT-VERDICT-AS- LOAD-BEARING-DMARC-PASS-PATH-FOR-GOOGLE- WORKSPACE-EGRESS-MAIL companion to this Workspace DKIM activation walkthrough. Activating DKIM at admin.google.com → Apps → Google Workspace → Gmail → Authenticate email only produces a DKIM-Signature header whose cryptographic verification passes — that is a NECESSARY-BUT-NOT-SUFFICIENT precondition for DMARC pass. The DMARC engine at the receiver additionally evaluates whether the DKIM d=-tag's organizational domain (per the Public Suffix List boundary) aligns with the RFC 5322 From header's organizational domain — that alignment verdict is the load-bearing gate the DKIM-alignment-with-DMARC spoke documents. The four-axis WORKSPACE-DKIM- ACTIVATION-VS-DKIM-DMARC-ALIGNMENT comparison exposes the structurally- distinct PER-WORKSPACE-TENANT-DKIM- ALIGNMENT-FAILURE-MODE roles: (i) the Workspace-emitted DKIM d=-tag defaults to the customer's primary domain — when Workspace egress mail is sent via a sub-domain From-address (e.g. mkt.example.com) without the relaxed-alignment-mode adkim=r DMARC tag, the strict-alignment-mode verdict at the receiver produces dkim=fail for the alignment check even though the cryptographic signature verifies — the DKIM- alignment-with-DMARC spoke documents the relaxed-vs-strict alignment modes (adkim=r vs adkim=s) the publisher must coordinate with the Workspace-emitted d=-tag; (ii) Workspace egress mail routed through SaaS senders (third-party-from- domain senders re-signing the message with their own DKIM key at their own d=-tag) loses Workspace's original DKIM alignment unless the SaaS sender is configured to sign with the publisher's DKIM key — the DKIM- alignment-with-DMARC spoke documents the third-party-sender DKIM re-signing pattern preserving alignment through SaaS-sender hops; (iii) the per- message DKIM-alignment verdict is the load-bearing input to the receiver's DMARC engine OR-conjunction (RFC 7489 §6.6.2: SPF-alignment-pass OR DKIM- alignment-pass → DMARC pass) — the DKIM-alignment-with-DMARC spoke documents how the alignment verdict determines whether DKIM contributes a DMARC-pass path or falls to SPF alignment as the sole load-bearing leg; (iv) the Workspace tenant's per-message DKIM-alignment verdict is the load-bearing input to the publisher's RUA-aggregate-XML policy_evaluated.dkim field at every receiver per RFC 7489 §7.2 — the DKIM-alignment- with-DMARC spoke documents how the per-message DKIM-alignment verdict flows into the aggregate-report evidence stream the Workspace publisher consumes for per-tenant per-receiver DKIM-alignment-coverage triage. Read the DKIM-alignment-with- DMARC spoke immediately after completing this page's Workspace DKIM activation procedure to confirm the publisher's per-tenant DKIM-aligned- vs-DMARC-passed coverage assumption holds at the receiver-DMARC-engine alignment-check boundary.
• DMARC multi-domain strategy — the PER-WORKSPACE-TENANT-PER-VERIFIED- DOMAIN-DKIM-PUBLICATION-COORDINATION companion to this per-tenant single-domain DKIM activation procedure. Where THIS page documents the single-domain per-tenant Workspace Admin Console workflow (the admin.google.com → Apps → Google Workspace → Gmail → Authenticate email flow, the single google._domainkey selector activation per primary domain, the per-tenant 1024-bit / 2048-bit RSA key generation + per-customer DNS publication), the multi-domain-strategy spoke documents the FOUR PER-WORKSPACE-TENANT-PER-VERIFIED- DOMAIN COORDINATION DIMENSIONS the operator MUST close when the per-tenant Workspace instance hosts MULTIPLE verified custom domains (the parent corporate domain + per-product brand domains + per-subsidiary domains added via Admin Console "Add a domain" workflow): (i) per-verified- domain INDEPENDENT DKIM activation — every verified domain under a single Workspace tenant requires its OWN "Generate new record" Admin Console invocation under Apps → Google Workspace → Gmail → Authenticate email → Select domain dropdown, producing a per-domain google._domainkey.<domain> public-key TXT record that the operator publishes at THAT domain's customer-managed DNS zone; a single Admin Console DKIM activation does NOT cover sibling verified domains under the same tenant; (ii) per-verified-domain INDEPENDENT DMARC p=reject enforcement cadence — every verified Workspace domain MUST publish its OWN _dmarc.<domain> aggregate record on an INDEPENDENT per-domain p=none → p=quarantine → p=reject rollout cadence so a per-domain Workspace- side DKIM activation regression does NOT collapse the per-tenant portfolio-wide per-receiver per-day enforcement verdict distribution; (iii) per-verified- domain INDEPENDENT rua= mailbox ingestion under a single per-tenant operator dashboard — every per- domain rua= publication MUST funnel its receiver-side aggregate-report stream into a SINGLE per-tenant Workspace- operator dashboard so the per-tenant per-portfolio-domain DKIM-aligned-pass verdict surface is available to the per- tenant authentication-operator at one ingestion point — letting the operator attribute a per-receiver per-day per-domain DKIM-aligned-pass-rate regression to the SPECIFIC verified domain whose Admin Console DKIM activation regressed; (iv) per-acquired-subsidiary-domain Admin-Console verification + DKIM activation ONBOARDING SEQUENCE — newly-acquired subsidiary domains added via per-tenant M&A activity require the standard Admin Console "Add a domain" verification ceremony FOLLOWED BY a per-domain DKIM activation invocation FOLLOWED BY a per-domain DMARC p=quarantine → p=reject rollout cadence — the multi-domain- strategy spoke documents the canonical onboarding sequence that prevents the per-acquired-subsidiary-domain becoming a per-tenant Workspace-portfolio authentication-coverage gap exploitable by a per-attacker subsidiary-domain BEC spoofing variant. Read the multi-domain- strategy spoke ALONGSIDE this per-tenant single-domain Workspace DKIM activation procedure when operating a per-Workspace- tenant MULTI-VERIFIED-DOMAIN portfolio — the per-portfolio-per-verified-domain coordination catalogue is the canonical operator-facing companion every multi- domain Workspace tenant MUST execute to preserve the per-tenant per-portfolio DKIM-aligned-pass coverage assumption at the receiver-DMARC-engine alignment-check boundary.
• Phishing protection — the PER-WORKSPACE-TENANT-DKIM- PUBLICATION-AS-LOAD-BEARING-ANTI- PHISHING-PRIMITIVE companion reference. Where THIS page documents the per- Workspace-tenant DKIM activation discipline (Admin Console Generate-new-record → 2048-bit RSA key-pair generation → per-customer- domain google._domainkey.<customer> TXT publication → Start-authentication flip → manual rotation cadence), the phishing-protection spoke is the PER- PUBLISHER-PER-DOMAIN-PHISHING-ATTACK- THREAT-MODEL companion whose per- Workspace-tenant per-custom-domain anti- phishing posture the DKIM-publication discipline directly supports. Four Workspace-tenant anti-phishing coupling dimensions the spoke addresses: (1) per-publisher per-domain display-name spoofing deterrence — attackers forge the RFC 5322 From: display-name to read "Workspace Admin <attacker@evil.tld>" impersonating the per-Workspace-tenant operator — the per-Workspace-tenant per-custom- domain DKIM-aligned-pass evidence at the receiver-side cryptographically distinguishes legitimate Workspace- tenant per-custom-domain mail from attacker-controlled lookalike-domain mail in the receiver-side per-message Authentication-Results header; (2) per- publisher per-domain lookalike-domain registration deterrence — attackers register g00gle.com (zero in place of "o"), workspace.support (vanity TLD), or registrar-typosquats imitating the per-Workspace-tenant custom domain — the google._domainkey.<customer> DKIM-aligned-pass publication discipline produces the per-publisher per-domain cryptographic-authentication primitive the per-receiver per-domain lookalike- domain-attack-campaign empirical- detection pipeline consumes to flag per-receiver per-day lookalike-domain per-message anomalies; (3) per- publisher per-domain IDN-homograph deterrence via UTS #39 confusables — attackers register google.com-confusable domains using mixed-script Unicode confusables (Cyrillic "о" U+043E replacing Latin "o" U+006F) — the per- Workspace-tenant DKIM-aligned-pass evidence allows per-receiver per- domain confusable-mapping empirical- detection pipelines to cryptographically distinguish legitimate per-custom- domain mail from confusable-spoofed attacker mail; (4) per-publisher per- domain per-source-IP per-day DMARC- aligned-fail-rate spike as empirical- detection signal — the per-Workspace- tenant DMARC RUA aggregate-report stream surfaces per-receiver per-day per-source-IP per-publisher per-day DMARC-aligned-fail-rate spikes as the literal empirical-detection signal for active per-publisher per-custom-domain spoofing-attack-campaigns; the per- message RUF ARF diagnostic-block stream from per-domain ruf= publication enables per-attack-campaign forensic-evidence-collection for SOC incident-response. Read the phishing- protection spoke when MOTIVATING the per-Workspace-tenant per-custom-domain DKIM publication discipline as the load-bearing per-publisher per-domain cryptographic anti-phishing primitive whose receiver-side enforcement closes the per-publisher per-domain phishing- attack-campaign attack surface.
• TLS-RPT report format — the per-Workspace-tenant RFC 8460 TLS-RPT JSON-aggregate report as peer transport- layer cross-tenancy observability primitive companion to this per-tenant DKIM-publication- discipline reference. Where THIS page documents the per-tenant single-selector google._domainkey TXT-publication operator-managed-key activation procedure + per-tenant DKIM-management Admin-Console rotation workflow as the application-layer authentication-publication-discipline, the TLS-RPT-report-format spoke documents the RFC 8460 JSON-aggregate report schema that is the LOAD-BEARING transport-layer observability primitive the operator MUST co-ingest alongside the application-layer DKIM-aligned-pass RUA evidence. Four PER- WORKSPACE-TENANT-VS-TLS-RPT-JSON-AGGREGATE- REPORT cross-correlation axes the TLS-RPT- report-format spoke documents: (i) the per-Workspace-tenant outbound DKIM-signed mail traversing per-receiver- side STARTTLS upgrade is captured in the receiver-side RFC 8460 JSON-aggregate as per-publisher per-receiver per-day summary.total-successful-session-count + per-failure failure-details rows — the per-tenant DKIM-aligned-pass RUA evidence is INCOMPLETE without the per-publisher per-day TLS-RPT JSON-aggregate confirming the transport-layer envelope- encryption preconditions that protect the DKIM-signed message body from in-flight body mutation; (ii) the per-Workspace-tenant inbound MTA-STS policy publication (the _mta-sts.<tenant>.com + 5x ASPMX.L.GOOGLE.COM canonical MX hostname glob) emits per- sender per-day TLS-RPT JSON-aggregate rows the receiving Workspace-tenant operator reads for cross-tenancy transport-layer- failure attribution between Workspace-side / sender-side / in-flight TLS-stripping root causes; (iii) the per-Workspace-tenant per-quarter manual DKIM-rotation cadence interacts with the per-day TLS-RPT JSON-aggregate — DKIM-signed messages emitted during the per-quarter rotation overlap window MUST traverse STARTTLS-encrypted sessions to preserve the DKIM signature body-hash integrity, and per-day TLS-RPT JSON-aggregate failure-details.result-type=starttls-not-supported rows during the rotation-overlap window signal transport-layer downgrade risk to the rotation cadence; (iv) the per-Workspace-tenant cross-protocol-pillar authentication-and-encryption-posture investigation discipline requires the per- publisher per-day TLS-RPT JSON-aggregate co-ingested with the per-publisher per-day DMARC RUA aggregate — the JSON-aggregate's per-failure failure-details rows attribute transport-layer failures per-source-MTA-IP + per-receiving-MX-hostname while the RUA aggregate's policy_evaluated rows attribute application-layer authentication verdicts per-source-IP — together they form the complete per-tenant cross-protocol-pillar observability stream. Read THIS page when CONFIGURING the per-tenant DKIM publication discipline; read the TLS-RPT- report-format spoke when DECODING the per- day RFC 8460 JSON-aggregate that completes the per-tenant cross-protocol-pillar authentication-and-encryption-posture observability stream alongside the per- tenant DKIM-aligned-pass RUA evidence stream.
• Email deliverability fundamentals — the per-publisher per-domain inbox- placement-rate-as-business-outcome primitive whose four per-Workspace-tenant per-custom-domain DKIM-publication- discipline-as-deliverability-input coupling dimensions THIS Workspace DKIM publication- discipline reference materially feeds: (i) per-Workspace-tenant per- custom-domain DKIM-aligned-pass-rate-floor via the Authenticate-email-wizard-engaged google._domainkey.<customer> TXT-record publication as load- bearing upstream input to per-receiver per-mailbox-provider per-sender-reputation- scoring inbox-vs-Spam-folder placement decision each receiver's spam-filter applies to per-Workspace-tenant per-custom- domain outbound mail (Gmail itself + cross- receiver Outlook.com / Yahoo Mail / Apple iCloud / ProtonMail consumers) — per-Workspace-tenant DKIM-signing posture floor IS the deliverability-floor input; (ii) per-Workspace-tenant DKIM publication-completeness STRUCTURALLY GATES the per-Workspace-tenant Postmaster-Tools- dashboard per-day sender-reputation-rating positive-acquisition floor the Gmail receiver-side per-sender-reputation scoring-algorithm REPORTS BACK to the per-Workspace-tenant operator — per-tenant publication-completeness IS the per-receiver reputation-warmup-acceleration primitive AND the per-Workspace-tenant operator's authoritative deliverability- feedback channel for the per-tenant Gmail- as-receiver leg; (iii) per-Workspace- tenant DKIM-aligned-pass-rate regression (Authenticate-email wizard not-engaged → dkim=pass + aligned=false to gappssmtp.com default-domain signing, per-tenant CNAME-chain breakage on external-DNS provider parent zone, per- tenant DKIM TXT-record TTL-window-bounded propagation-tail) SURFACES as per-receiver per-mailbox-provider per-sender-reputation regression THIS Workspace DKIM publication- discipline reference's per-tenant operational-discipline runbook MUST detect before per-receiver inbox-placement-rate falls below the per-publisher per-domain business-outcome floor — per- tenant DKIM regression IS deliverability regression at the per-receiver consumption boundary; (iv) per-Workspace-tenant per-custom-domain DKIM-aligned-pass evidence as the per-receiver per-mailbox- provider per-sender Postmaster-Tools- feedback / SNDS-dashboard / Sender-Score positive-reputation-attribution input the per-publisher per-domain analytics team's per-receiver per-mailbox-provider per-day reputation-monitoring runbook materially consumes — the per-Workspace- tenant per-custom-domain DKIM publication- evidence loop closes through per-receiver per-mailbox-provider reputation-feedback channels back into the per-publisher per- domain operator's discipline floor validation. Read the email-deliverability fundamentals spoke alongside this Workspace DKIM publication-discipline reference when positioning per-Workspace-tenant per- custom-domain DKIM publication-discipline within the broader per-tenant per-custom- domain deliverability operator-discipline floor, when authoring per-tenant per- custom-domain DKIM-publication-regression incident-response runbooks whose deliverability-impact-quantification protocol consumes per-receiver per- mailbox-provider per-day inbox-placement- rate evidence, or when coordinating per- Workspace-tenant per-custom-domain DKIM publication-discipline against per- receiver per-mailbox-provider per-sender- reputation-scoring-feedback channels the per-publisher per-domain operator's deliverability operator-discipline floor materially consumes.
• DMARC myths and misconceptions — the PER-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-DKIM-CNAME-DELEGATION-OPERATOR-SIDE- MISTAKE-PATTERN-AS-PER-PUBLISHER-PER-DOMAIN- MYTH-CATALOGUE-LOOKUP-REFERENCE companion to THIS Workspace-tenant DKIM deployment reference. Where THIS page documents the per-Workspace-tenant per-custom-domain DKIM CNAME-delegation publication discipline (the per-tenant google._domainkey. <custom-domain> CNAME pointing to <selector-id>.<tenant>. dkim.gappssmtp.com, the per-tenant Workspace admin-console DKIM-generate + DKIM-publish + DKIM-rotate operator- workflow, the per-tenant per-custom-domain 2048-bit RSA key-pair generation cadence, and the per-tenant per-custom-domain DKIM-aligned mail-flow validation pipeline), the DMARC-myths-and-misconceptions spoke documents the per-publisher per-domain operator-side DKIM-specific misconception bucket the per-Workspace-tenant operator MUST consult at FOUR per-Workspace-tenant- DKIM-vs-DMARC-myth-catalogue coupling dimensions: (i) per-Workspace- tenant per-custom-domain DKIM-CNAME- delegation publication-discipline-vs- ownership-misconception lookup as per- publisher per-domain DKIM-CNAME-mythbusting catalogue consultation — per- Workspace-tenant operators commonly adopt the "Workspace DKIM is automatically published with the tenant" / "the Workspace DKIM-CNAME inherits from onmicrosoft.com" / "the Workspace DKIM is opt-out not opt-in" Workspace-DKIM misconceptions during per- tenant per-custom-domain DKIM-CNAME- delegation publication-discipline setup, and the DMARC-myths-and-misconceptions spoke's Workspace-DKIM mythbusting entries IS the per-publisher per-domain canonical pre-flight per-Workspace-tenant per- custom-domain DKIM-CNAME publication audit reference the per-Workspace-tenant operator MUST consult BEFORE per-tenant DKIM-CNAME publication commit; (ii) per-Workspace-tenant per-custom- domain DKIM-selector rotation-discipline- vs-no-rotation-misconception lookup as per-publisher per-domain DKIM-key-rotation- mythbusting catalogue consultation — per-Workspace-tenant operators commonly adopt the "DKIM-CNAME-delegated selectors don't need rotation" / "Workspace handles DKIM rotation automatically without operator action" / "rotating DKIM invalidates already-sent mail" DKIM- rotation misconceptions during per-tenant per-custom-domain DKIM-rotation-cadence planning, and the DMARC-myths-and- misconceptions spoke's DKIM-rotation- cadence mythbusting entries provide the per-publisher per-domain canonical pre- flight per-Workspace-tenant per-custom- domain DKIM-rotation audit reference; (iii) per-Workspace-tenant per- custom-domain DKIM-signature scope-vs- body-only-misconception lookup as per- publisher per-domain DKIM-signature-scope mythbusting catalogue consultation — per-Workspace-tenant operators commonly adopt the "DKIM signs message body alone" / "DKIM signs only the From: header" / "DKIM-Signature header can be forged without breaking signature" DKIM-scope misconceptions during per-tenant per- custom-domain DKIM-signature-coverage operator-discipline-floor setup, and the DMARC-myths-and-misconceptions spoke's DKIM-signature-scope mythbusting entries provide the per-publisher per-domain canonical pre-flight per-Workspace-tenant per-custom-domain DKIM-signature-scope audit reference; (iv) per- Workspace-tenant per-custom-domain DKIM- alignment-vs-DMARC-alignment-misconception lookup as per-publisher per-domain DMARC- alignment mythbusting catalogue consultation — per-Workspace- tenant operators commonly adopt the "DKIM- pass means DMARC-aligned-DKIM-pass" / "DKIM d= tag must match the Workspace tenant onmicrosoft hostname" / "DKIM relaxed-vs-strict alignment is synonymous with DKIM canonicalization relaxed-vs-simple" DMARC-alignment misconceptions during per-tenant per- custom-domain DKIM-aligned-pass-rate-floor operator-discipline-floor setup, and the DMARC-myths-and-misconceptions spoke's DMARC-alignment mythbusting entries provide the per-publisher per-domain canonical pre-flight per-Workspace-tenant per-custom-domain DKIM-aligned-pass-rate- floor audit reference. Read THIS Workspace- tenant DKIM deployment reference when PUBLISHING the per-tenant per-custom- domain DKIM-CNAME-delegation discipline AND when COORDINATING the per-tenant per- custom-domain DKIM-aligned-pass-rate-floor against the per-publisher per-domain operator-side mistake-pattern catalogue; read the DMARC-myths-and-misconceptions spoke when AUDITING the per-tenant per- custom-domain operator-side DKIM-CNAME publication-discipline-floor mistake- pattern catalogue lookup BEFORE per- tenant per-custom-domain DKIM-CNAME publication commit THIS page documents.
• DMARC for cPanel-hosted domains
• MTA-STS explained — the canonical RFC 8461 MTA-STS protocol primer every Workspace tenant operator should read alongside this DKIM deployment walkthrough to understand how the per-tenant transport-layer https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt HTTPS-served policy file (declaring mx: aspmx.l.google.com + mx: *.googlemail.com for the Workspace inbound MX hosts) pairs with the per- Workspace-tenant per-custom-domain google._domainkey.<custom-domain> DKIM TXT-record publication this page documents to form the per-Workspace-tenant composite per- custom-domain application-layer-authentication + transport-layer-encryption publication- discipline portfolio. Where THIS page locks the per-message DKIM-Signature cryptographic- binding at the application-layer, the MTA-STS- explained primer locks the per-receiving-MTA STARTTLS-enforcement boundary at the transport- layer — together they close the per-Workspace- tenant per-custom-domain authentication-and- encryption publication floor.
• SPF DNS record syntax explained
• Business email compromise (BEC) playbook — the PER-WORKSPACE-TENANT-PER- CUSTOM-DOMAIN-DKIM-APPLICATION-LAYER- AUTHENTICATION-LEG-AS-LOAD-BEARING-PER- MESSAGE-FORENSIC-EVIDENCE-INPUT-TO-THE- BEC-INCIDENT-RESPONSE-WORKFLOW companion to this Workspace DKIM publication- discipline reference. Where THIS page documents the per-Workspace-tenant per- custom-domain DKIM-key generation + google._domainkey.<workspace-tenant-custom-domain> TXT-RR publication-discipline + per- tenant Admin Console Apps > Google Workspace > Gmail > Authenticate email per-custom-domain DKIM-signing activation, the BEC playbook is the per- Workspace-tenant FINANCE-TREASURY-FRAUD- TEAM operational-workflow reference whose per-message DKIM-Signature header attribution the per-Workspace-tenant per- custom-domain DKIM publication-discipline THIS page documents the publication- discipline of IS THE PRIMARY per-message cryptographic-binding forensic data point the BEC investigator parses at FOUR per- Workspace-tenant per-custom-domain DKIM- vs-BEC coupling dimensions: (i) per-message DKIM-Signature d=<workspace-tenant-custom-domain> signing-domain attribution as Stage 3 BEC-evidence-collection input — a CEO-fraud message that produces dkim=pass with d=attacker-controlled.example rather than the impersonated victim's Workspace-tenant per-custom-domain is the SINGLE MOST IMPORTANT BEC-forensic data point per the FBI Financial Fraud Kill Chain playbook Stage 3 evidence- collection workflow — immediate cryptographic evidence that the message did NOT originate from the victim's per- Workspace-tenant per-custom-domain signing infrastructure THIS page documents the publication-discipline of, even though the From: header was rewritten to appear so; (ii) per- Workspace-tenant per-custom-domain DKIM s=google selector publication-discipline as cryptographic chain-of-custody anchor — the per-message DKIM-Signature s=google selector value identifies that the BEC investigator queries google._domainkey.<workspace-tenant-custom-domain> for the per-tenant per-custom-domain public-key TXT-RR THIS page documents the publication-discipline of, providing the cryptographic chain-of-custody back to the per-Workspace-tenant per-custom- domain DNS-publication-discipline that the FBI Financial Fraud Kill Chain playbook references as Stage 3 evidence collection; (iii) per-Workspace- tenant per-custom-domain DKIM-key rotation cadence vs BEC IR-window coordination — per- Workspace-tenant per-custom-domain DKIM-key rotation events (selector1 google._domainkey to selector2 google2._domainkey rotation cadence) require per-tenant operator-side coordination with BEC IR- window evidence-collection so per- message DKIM-Signature s= tag-value resolution stays unambiguous across the dual-selector overlap-window the BEC investigator parses for per- message authentication-leg verification; (iv) per-Workspace-tenant per- custom-domain DKIM-aligned-pass evidence stream feeding per-tenant DMARC RUF forensic-report pipeline per RFC 7489 §7.3 — per-Workspace- tenant per-custom-domain DKIM- verifier-side dkim=fail verdict triggers per-message AFRF forensic-report emission under fo=1 publication-decision per RFC 7489 §6.3, which is the per- message forensic-evidence stream the per-Workspace-tenant BEC IR investigation consumes alongside per-day DMARC RUA aggregate-XML report attribution per RFC 7489 §7.2 the per-Workspace-tenant operator parses for per-message authentication-leg attribution evidence. Read the BEC playbook WITH this per- Workspace-tenant per-custom-domain DKIM publication-discipline reference when the per-Workspace-tenant finance / treasury / fraud team escalates a suspected per-tenant per-custom-domain BEC incident to the per-tenant security operations team for per-message DKIM- Signature forensic-evidence reconstruction at the per-Workspace-tenant per-custom- domain DKIM-application-layer-and-BEC- incident-response coordination boundary.
• MX records explained — the inbound-routing DNS companion to this Google Workspace DKIM guide. A Workspace tenant cannot receive mail at its custom domain until the per-domain MX records are cut over to Google's smtp.google.com mail exchangers, and that same DNS-zone edit pass is where the per-selector <selector>._domainkey DKIM TXT-RR is published — so the MX cutover and the DKIM-signing deployment THIS page documents are coordinated zone-publication steps that share the per-record TTL and propagation window. Read the MX-records spoke when sequencing the Workspace custom-domain mail-routing cutover alongside the per-selector DKIM key publication.
• Forwarding issues with SPF — the SRS / ARC / mailing-list / .forward catalogue of forwarder-induced SPF failures. When a forwarder rewrites the envelope and the original SPF record stops matching the relaying host, the google-selector DKIM signature this page documents is what keeps the message DMARC-aligned through the hop — DKIM survives forwarding where SPF breaks.
• Email security glossary — the plain-language reference for every acronym this Google Workspace DKIM guide leans on: DKIM, selector, canonicalization, d= alignment, SPF, DMARC, and the aggregate-report vocabulary. Read the glossary when a term in the Workspace signing-key setup is unfamiliar and you need the one-line definition before acting on it.
• Microsoft SNDS + JMRP monitoring — the Microsoft-side counterpart of Google Postmaster Tools: when the same streams also reach Outlook.com/Hotmail recipients, SNDS is where Microsoft exposes per-IP GREEN/YELLOW/RED filter verdicts and JMRP is its complaint feedback loop.

Verify DKIM on your Google Workspace tenant now

DMARC Analyzer parses the daily aggregate reports Google and other receivers send to your rua= mailbox and surfaces the per-sender DKIM verdict breakdown via includes/DmarcParser.php — catching the gappssmtp.com signing-identity failure mode within hours of the first misaligned message. Live DNS verification for every DKIM selector on your domain runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual message failures by parsing the full Authentication-Results stack via includes/EmailHeaderParser.php.

Sign up — Free plan Check my Google Workspace DKIM setup