DKIM Signing: How It Works and Why It Matters
DKIM (DomainKeys Identified Mail) is the email authentication protocol that proves your email has not been tampered with during transit. While SPF tells the receiving server which servers can send on your behalf, DKIM proves that the email content is exactly what was sent and has not been modified by anyone along the way.
For cold email senders, DKIM is essential. Without it, mailbox providers cannot verify the integrity of your messages, which means they cannot fully trust that the email they received is the email you sent. That lack of trust translates directly to worse inbox placement.
How DKIM Works: The Simplified Version
DKIM uses public-key cryptography to sign your emails. Here is the process in plain language.
When you send an email, your mail server takes specific parts of the email (headers, body, or both) and creates a unique digital signature using a private key that only your server has. This signature is added to the email as a DKIM-Signature header.
The corresponding public key is published in your domain's DNS records. When the receiving server gets your email, it looks up your public key in DNS and uses it to verify the signature. If the signature checks out, it means the email was sent by someone who has the private key (which should only be your authorized sending servers) and the content has not been changed since signing.
Think of it like a wax seal on a letter. The sender presses their unique seal into wax. The recipient knows what the sender's seal looks like (the public key). If the seal is intact and matches, the letter is authentic and unopened. If the seal is broken or does not match, something is wrong.
What Gets Signed
DKIM does not sign the entire email. It signs specific headers and the message body, defined by the sender's DKIM configuration.
Typically signed headers include: From, To, Subject, Date, and Message-ID. The body is also signed, either in full or partially (depending on the canonicalization method used).
The signature is stored in the DKIM-Signature header, which includes: the signing domain (d=), the selector (s=) used to find the public key in DNS, the algorithm used (typically rsa-sha256), a hash of the signed headers and body, and the actual signature value.
DKIM Key Setup
Setting up DKIM involves three steps: generating a key pair, publishing the public key in DNS, and configuring your mail server to sign outgoing emails with the private key.
Key generation. Your email hosting provider or sending service typically handles this. Google Workspace, Microsoft 365, SendGrid, and other services provide DKIM key generation in their admin console. You do not need to generate keys manually in most cases.
Key length. DKIM keys come in two common lengths: 1024-bit and 2048-bit. Use 2048-bit keys whenever possible. They are more secure and increasingly expected by mailbox providers. Some DNS providers have character limits on TXT records that can make 2048-bit keys tricky to implement (the key string is very long), but most modern DNS providers handle them fine.
DNS record. The public key is published as a TXT record at a specific subdomain: selector._domainkey.yourdomain.com. The selector is a name chosen by your email service (like "google" or "s1") that allows you to have multiple DKIM keys for different services.
For Google Workspace, the default DKIM selector is "google." The DNS record is a TXT record at google._domainkey.yourdomain.com with the public key value provided by Google.
For Microsoft 365, the DKIM records are typically CNAME records pointing to Microsoft's key hosting. Microsoft handles the key rotation and publishing through these CNAMEs.
Configuring DKIM for Multiple Sending Services
If you send email through multiple services (email hosting plus cold email platform plus marketing tool), each service needs its own DKIM configuration. This means multiple DKIM selectors, each with its own key pair.
For example, you might have: google._domainkey (for Google Workspace), s1._domainkey (for your cold email platform), and k1._domainkey (for your marketing automation tool). Each selector has its own TXT or CNAME record in DNS, and each service signs emails with its own private key.
This is different from SPF, where all services share a single record. DKIM allows parallel signing without conflict because each service uses its own selector.
Verifying DKIM Is Working
After setup, verify that DKIM signing is active and passing. Send a test email from each service and inspect the authentication results.
In Gmail, open the email and click the three-dot menu, then Show original. Look for the Authentication-Results header. You should see dkim=pass. If you see dkim=fail or dkim=none, the configuration needs fixing.
Common failure causes: the DNS record has not propagated yet (wait up to 48 hours after making changes), the selector name in DNS does not match what the service is using, the public key value was copied incorrectly (missing characters, extra spaces), or DKIM signing was not enabled in the service's admin console.
Use MXToolbox's DKIM lookup tool to check your DNS records. Enter your domain and selector, and the tool will show whether the public key is published correctly.
DKIM Key Rotation
Security best practices recommend rotating DKIM keys periodically. Key rotation means generating a new key pair, publishing the new public key in DNS, switching to signing with the new private key, and eventually removing the old public key.
How often should you rotate? For most senders, annually is sufficient. High-security environments might rotate quarterly. The important thing is that you rotate at all, as a compromised private key would allow someone else to send authenticated emails as your domain.
Google Workspace handles key rotation automatically if you use their default DKIM configuration. Other services may require manual rotation. Check your provider's documentation for their recommended rotation process.
DKIM and DMARC Alignment
DKIM does not just work on its own. It feeds into DMARC, which checks whether the DKIM signing domain aligns with the From domain visible to the recipient.
For DMARC alignment, the domain in the DKIM signature's d= tag must match (or be a subdomain of) the From domain. If your From address is you@yourdomain.com but DKIM signs with d=sendingservice.com, DMARC alignment fails even though DKIM itself passes.
Most email services support custom DKIM signing that uses your domain in the d= tag. This is sometimes called "domain alignment" or "custom DKIM" in the service's settings. Enable this for every sending service to ensure DMARC alignment.
DKIM and Email Forwarding
One of DKIM's advantages over SPF is that it survives email forwarding. When an email is forwarded, SPF often breaks because the forwarding server's IP is not in the original sender's SPF record. DKIM, however, remains valid because the signature is attached to the email content, not the sending IP.
This makes DKIM particularly important for cold email. If a recipient forwards your cold email to a colleague (which is a positive signal and exactly what you want), DKIM ensures the forwarded copy retains authentication. Without DKIM, the forwarded email loses authentication and may be treated with more suspicion by the colleague's email server.
DKIM for Cold Email Domains
Every cold email domain must have DKIM configured for every service that sends from it. This is a mandatory part of your domain setup checklist.
When setting up a new cold email domain, configure DKIM immediately after setting up the email hosting account. Do not start warmup until DKIM is verified as passing. Sending warmup emails without DKIM means your warmup engagement signals are being generated on an improperly authenticated domain, which undermines the trust-building that warmup is supposed to accomplish.
If your cold email platform sends through its own servers (rather than through your email hosting account), it needs its own DKIM selector configured in your DNS. Check your platform's setup documentation for the specific DKIM requirements. Most platforms provide step-by-step instructions that take 10-15 minutes per domain.
DKIM is not optional. It is a core component of email authentication that directly affects your deliverability. Set it up correctly, verify it is passing, rotate keys periodically, and ensure DMARC alignment across all your sending services. The investment is small, the impact is significant, and the downside of skipping it is real.
