DKIM is the piece of the authentication stack most people set up correctly once and then never think about again — which is mostly fine, except for the handful of situations (key rotation, migrating sending platforms, running multiple tools on one domain) where getting it wrong quietly breaks deliverability without an obvious error message. This is the complete setup and troubleshooting reference.
DomainKeys Identified Mail attaches a cryptographic signature to each outgoing message, generated using a private key your sending platform holds. The corresponding public key is published in your domain's DNS as a TXT record. When a message arrives, the receiving server looks up that public key and uses it to verify the signature — confirming two things: that the message's signed headers and body weren't altered in transit, and that whoever signed it actually holds the matching private key for your domain.
This matters differently than SPF. SPF checks whether the sending IP is authorized; DKIM checks whether the message content itself is intact and properly signed, independent of which server relayed it. A message can pass through multiple servers and still carry a valid DKIM signature, which is part of why DKIM tends to survive forwarding scenarios where SPF often breaks.
A DKIM record is published at a specific subdomain pattern: [selector]._domainkey.yourdomain.com. The selector is an arbitrary string your sending platform assigns (often something like sl1 or google) that lets a domain run multiple DKIM keys simultaneously without conflict — useful for key rotation and for running more than one sending tool on the same domain.
Breaking down the record value: v=DKIM1 declares the version. k=rsa specifies the key algorithm (RSA is standard; some providers now support Ed25519, though RSA remains the safe default for compatibility). p= is the actual public key, base64-encoded — this is the long string that receiving servers use to verify signatures.
Almost no one hand-generates DKIM keys for cold email anymore — sending platforms generate the key pair and give you the exact DNS record to publish. The process is nearly identical across Smartlead, Instantly, and most competitors:
Copy the selector exactly. A surprisingly common failure mode is publishing the public key correctly but under the wrong selector subdomain — the record technically exists in DNS but the receiving server looks for it at a different subdomain than where you published it, so the DKIM check fails as if the record didn't exist at all.
DKIM keys come in different lengths, most commonly 1024-bit and 2048-bit. Gmail's bulk sender requirements, which took effect in 2024, require 2048-bit DKIM keys for senders hitting the volume thresholds those requirements cover — and treating 2048-bit as the baseline going forward is the safer default even below those thresholds, since 1024-bit RSA keys are increasingly considered cryptographically weak.
| Key length | Status | Recommendation |
|---|---|---|
| 1024-bit | Weak by current standards | Avoid for new setups; migrate off if inherited from an old configuration |
| 2048-bit | Current standard | Use this as the default for all new domains |
| 4096-bit | Stronger, but rarely necessary | Some DNS providers cap TXT record length in ways that complicate publishing keys this long — 2048-bit is the practical sweet spot |
Most modern cold email platforms default to 2048-bit keys automatically, but it's worth confirming in your platform's DNS setup screen rather than assuming — especially if a domain was set up years ago and never revisited.
DKIM keys don't expire on their own, but rotating them periodically is good practice, and rotating immediately is necessary if a private key is ever suspected of being exposed (a platform breach, an accidentally committed credential, an employee departure with prior key access). A reasonable default is rotating every 6-12 months for an actively used domain.
The rotation process itself is designed to avoid downtime: generate a new key pair under a new selector (e.g., moving from sl1 to sl2), publish the new public key alongside the old one (both records coexist in DNS during the transition), switch your sending platform to sign with the new key, confirm mail is signing correctly with the new selector, and only then remove the old DNS record. Removing the old key before confirming the new one works risks a window where signing fails entirely.
Each sending platform generates and holds its own private key, and expects to publish its own selector. This is why you can't reuse one platform's DKIM setup for a different platform sending from the same domain — Instantly's private key can't sign mail sent through Smartlead, because Smartlead never had access to it. If you're running two tools from the same domain (not generally recommended for a dedicated cold email domain, but common when a domain also handles other business email), each tool needs its own selector and its own published public key, coexisting as separate DNS records.
DKIM's signature check is independent of SPF's IP check, but DMARC — which most inbox providers increasingly expect configured — requires that at least one of the two not only pass but also align with the domain shown in the visible From address. A domain can technically pass DMARC through DKIM alignment alone even if SPF has a problem, but that shouldn't be treated as a safety net; both should be correctly configured on their own. See our SPF setup guide and DMARC configuration guide for the rest of the stack.
Related guides