DKIM gives a receiving server a cryptographic way to verify that a message was signed by a domain and that signed portions of the message were not altered after signing. For a small business, the important operational detail is that DKIM has two sides: a private key used by the sending system and a public key published in DNS. Publishing a TXT record alone does nothing if the provider is not actually signing outgoing mail.
Understand the selector before you paste the record
A DKIM signature names a signing domain (`d=`) and a selector (`s=`). The receiver combines them to look up a DNS record such as:
`selector1._domainkey.example.com`
The TXT value usually begins with `v=DKIM1;` and contains a public key after `p=`. Your provider generates or supplies the exact selector and key. Do not invent them from examples.
Selectors let a domain use more than one DKIM key at the same time. Google Workspace might sign with one selector while a marketing platform signs with another. That separation is useful because you can rotate or remove one provider’s key without disrupting the others.
Google Workspace example: generate, publish, then turn signing on
In Google Admin, an administrator generates a DKIM record for the domain. Google provides a TXT host name and value. Publish those at the authoritative DNS provider, allow DNS to become visible, then return to Admin and start authentication for outgoing mail.
That final step matters. Teams sometimes publish the record and assume DKIM is active, but the mail service is still not signing. The test is a real received message, not the DNS editor.
Gmail requires a DKIM key of at least 1024 bits for mail sent to personal Gmail accounts and recommends 2048 bits when the domain provider supports it. Other mail platforms have their own key-generation workflow, so use the provider’s current documentation instead of trying to share one private key across unrelated services.
Verify the signature on the message that actually left your system
Send from the employee mailbox, CRM, support desk, and marketing platform separately. In the received headers, locate `DKIM-Signature` and `Authentication-Results`.
Record: - the `d=` signing domain; - the `s=` selector; - whether DKIM passed; - the visible From domain; - which platform generated the message.
A message can have multiple DKIM signatures. That is not automatically wrong; intermediaries and sending platforms can add their own signatures. For DMARC, what matters is whether at least one passing DKIM signature uses a domain aligned with the visible From domain.
Diagnose the common failure modes by evidence
“DKIM=none” means no usable signature was present. Check whether signing was enabled and whether you tested the correct sending path.
“DKIM=fail” can indicate a DNS/key mismatch or a message that changed in a way that invalidated the signature. Compare the selector in the message with the selector you published. If they differ, you may be looking at an old key, the wrong domain, or a provider that has switched selectors.
A DNS lookup that returns no public key points to a host-name or propagation problem. Copying the full domain into a DNS interface that automatically appends the zone name can accidentally create a record at `selector._domainkey.example.com.example.com`. Verify the final fully qualified DNS name from outside the DNS console.
Plan key rotation before the key is old
DKIM keys should not be treated as permanent furniture. A practical rotation process is to create a new selector, publish the new public key, switch the sender to sign with it, verify passing production messages, and only then remove the old key after an appropriate overlap.
The two-selector approach avoids a risky “replace in place and hope” change. Keep a simple key register with provider, selector, key size, activation date, and last verified date. The private key should stay inside the sending service; your documentation needs the selector and operational ownership, not the secret material.
DKIM is strongest when it participates in DMARC alignment
A message can pass DKIM with a vendor’s domain and still fail DMARC if that domain does not align with the visible From address. For each third-party platform, prefer a supported setup that signs with your domain or an aligned subdomain.
Once you verify a DKIM path, save one representative header. When delivery breaks six months later, comparing a failing message with the known-good header is far faster than rebuilding your understanding from the provider dashboard.
Diagnose message modification after signing
When DKIM passes in DNS but fails on the received message, inspect what was actually signed. The `DKIM-Signature` header contains a body hash (`bh=`), a list of signed headers (`h=`), and a canonicalization mode (`c=`). You do not need to calculate those values by hand, but they help separate a key-lookup problem from a message-modification problem.
Security gateways, mailing-list software, or outbound systems that append footers can change signed content after the original sender created the signature. Depending on what changed and the canonicalization mode, the receiving system can report DKIM failure even though the public key is correct.
Test the same sending path before and after any gateway that rewrites messages. Compare selector, signing domain, body-hash result, and final `Authentication-Results`. If only one path fails, fix the component modifying the signed message rather than rotating a perfectly valid key.