Say a 12-person distributor calls because their invoices are landing in spam at two of their largest customers. Everything else arrives fine. They run Google Workspace, SPF is published, and the Admin console shows DKIM as authenticating. We ask for one message with full headers. The Authentication-Results line says dkim=pass, and then names a signing domain that belongs to their invoicing platform rather than to them. DMARC fails anyway. Nothing in the Admin console was ever going to show that.
DKIM on a Workspace domain fails in a small number of ways, and they are not interchangeable. A key that was generated but never published. A key published under a host name the DNS editor quietly rewrote. A gateway that edits messages after Google has signed them. Or the mail that matters most leaving through a third party Google never touches. This is the order we work through it on a client domain, and what each symptom means.
Where DKIM is turned on, and the step that gets skipped
In the Admin console, DKIM lives under Menu, then Apps, Google Workspace, Gmail, then Authenticate email. You select the domain, choose a key length and a prefix selector, and click Generate new record. Google's documentation is explicit that this is a two-part job: add the key at your domain provider first, then return to the console, turn on DKIM signing and click Start authentication.
The last step is the one that gets skipped. The TXT record is live, public DNS checkers show it, everyone assumes the work is finished, and Google is still not signing with that key because authentication was never started for the domain. Confirm the domain reads as authenticating before you go looking for anything more interesting.
Two waiting periods matter before you decide something is broken. On a newly created organization, Google documents that you must wait 24 to 72 hours after turning on Gmail before the DKIM key can be generated, and that asking earlier can return an error saying the record was not created. Once the key is published, Google states that DKIM authentication can take up to 48 hours to start working, and that the Authenticate email page may keep showing "You must update the DNS records for this domain" during that window. If the record itself is correct, that message is not a fault. It is a clock.
The google._domainkey host name, and the two ways it breaks
The default prefix selector is google, which puts the public key at google._domainkey.yourdomain.com. Google's guidance is to pick a different prefix if the domain already uses a key with that selector, which happens more often than you would think on domains that passed through a previous mail provider.
Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
(the remainder of the key exactly as the Admin console gives it)Two mistakes account for most of the records we end up repairing. The first is typing the full name into the host field. Most DNS editors append the domain for you, so google._domainkey.yourdomain.com becomes google._domainkey.yourdomain.com.yourdomain.com, and the name a verifier queries holds nothing. The second is a key that lost characters in transit, usually pasted into a field that wrapped it or carrying a space that crept in at one end.
Check the published record from outside the control panel, because the panel shows you what you typed rather than what the internet answers:
dig +short TXT google._domainkey.yourdomain.comEmpty output means the record is not where the verifier will look, whatever the DNS interface displays. Run the same query against your own nameservers if the domain moved recently, since an old zone at a previous host can still be answering.
Read the header before you change anything
Guessing is expensive here. Every change buys another propagation wait, and by the third edit nobody remembers what the original state was. Gmail hands you the answer directly: open the message, click More next to Reply, and choose Show original. Google's help page points at the same line we do, Authentication-Results, and whether it carries dkim=pass.
Read two things in that header rather than one. Whether DKIM verified, and which domain signed. A signature can verify perfectly and still fail DMARC, because the domain inside the signature is not the domain your recipients see in the From address. Google's sender guidelines put the requirement plainly: the organizational domain in the From header has to align with the SPF organizational domain or the DKIM organizational domain, and only one of the two needs to align.
In signature terms from RFC 6376, the d= tag is the signing domain, s= is the selector that locates the public key in DNS, and bh= is the hash of the message body. Those three tags answer almost every question you will have.
What each failure actually means
No signature at all for your domain
Mail leaving Gmail with no DKIM signature carrying your domain points back at the console, not at DNS. Either authentication was never started, or the domain in question is a secondary domain or a domain alias that was configured separately and never got its own key. Each domain you sign for needs its own key and its own record.
The key is published but the verifier cannot use it
This is the mangled host name or the truncated key from the previous section, and the dig output settles it in seconds. If the query returns a value that looks complete, compare it character for character against the console rather than by eye at the ends. Keys fail on one missing character as thoroughly as on fifty.
body hash did not verify
This one is specific and worth memorizing. Google documents that it means the message was modified in transit, and names the usual cause: an outbound gateway that changes messages before they leave, for example one that appends a footer to the bottom of every outgoing message. The signature was computed over one body and checked against a different one.
On client domains this is nearly always an appliance or a service in the send path, a compliance disclaimer tool, a security gateway, or an archiving relay. Mailing lists and forwarding rules break body hashes the same way further downstream, which is why a message that fails on arrival at one recipient can pass everywhere else. The fix is to stop the modification, or to sign after it rather than before.
The signature verifies but nothing aligns
This is the opening story. The mail is genuinely signed, by the vendor sending it, and DMARC still fails because that vendor's domain is not yours. It is not a Workspace problem and no amount of work in the Admin console will move it.
The senders Google never signs
Google signs mail that leaves Google. Invoicing platforms, CRMs, marketing tools, help desks, e-commerce checkouts and accounting systems send from their own infrastructure, and unless you publish the DKIM records each of them gives you, they sign with their own domain or do not sign for you at all.
The inventory step takes an afternoon and saves weeks. List every system that sends mail showing your domain in the From address, then work through each vendor's authentication page, publish what it asks for, and verify inside that vendor's console. We wrote the per-vendor detail for the big three in why Mailchimp, HubSpot and Klaviyo fail DMARC alignment, and the pattern repeats almost everywhere: a CNAME or two, a dedicated sending domain, and a verification button nobody pressed.
Volume is not the escape hatch people hope it is. Google's sender guidelines have required SPF and DKIM, plus DMARC on the sending domain, for senders above 5,000 messages a day to Gmail since 1 February 2024. A 12-person distributor is nowhere near that. It is also not exempt from filtering, and a low-volume domain has less reputation history to lean on, not more.
1024 or 2048, and the record that will not fit
Google offers both key lengths when you generate, and recommends 2048-bit where your domain provider supports it. The catch appears on Google's own troubleshooting page: a 2048-bit key cannot be entered as a single text string in a DNS record subject to the 255-character limit. Google gives two ways out. Generate a 1024-bit key instead, or ask your domain host whether TXT records longer than 255 characters are supported and use 2048 if they are.
In practice most current DNS providers handle the long value by splitting it into quoted strings for you, which is the same answer applied automatically. If your provider silently truncates instead, you will see a published record that looks right and verifies nowhere, so check with dig before blaming anything else.
Rotation is the reason selectors exist. RFC 6376 locates a public key by signing domain plus selector, so more than one key can be valid for a domain at the same time. That gives you a clean sequence: generate the replacement under a new prefix, publish it, start authentication so signing moves to the new selector, and leave the old TXT record in place until no message signed with the old key is still in flight or sitting in an archive that anyone will re-verify. Then remove it. Deleting the old record the same hour you rotate is how a rotation turns into an outage.
What we watch after the fix
A green row in the console proves Google is signing. It says nothing about the other systems sending as you. DMARC aggregate reports do, and they are the only view that covers every source at once, with a DKIM result and a signing domain for each. We read a few weeks of them before touching a DMARC policy, which is the subject of how to read a DMARC aggregate report. While you are in the zone, it is worth confirming the SPF side has not drifted past its lookup budget either, covered in SPF too many DNS lookups.
How Guanacos Tech helps
We do this end to end for small and mid-sized companies across North America and Latin America: read the headers, repair the record, find the senders nobody remembered, sort out the gateway that rewrites bodies, then watch DMARC reports until the picture is clean. If mail from your Workspace domain is failing DKIM and you would rather not spend a week on propagation waits, paste a message into the analyzer above, or book a call and we will look at it with you. More on the full engagement in email deliverability.