DKIM: the email signature cold senders get wrong

1. What makes DKIM different from SPF

SPF checks whether the server sending your email is authorized. That check happens at the network level, based on IP address. It has nothing to do with the email content itself.

DKIM is different. It signs the actual email with a cryptographic key. The signature is embedded in the message headers and travels with the email wherever it goes. The receiving server uses your public key (stored in DNS) to verify the signature is valid and the message wasn't altered in transit.

Two practical consequences of this difference:

• DKIM survives email forwarding. SPF fails forwarding almost every time.
• DKIM proves the message wasn't tampered with after sending. SPF proves nothing about the content.

For Gmail specifically, DKIM carries more weight than SPF in spam filtering decisions. A DKIM pass from a domain with reputation history is a strong positive signal. SPF alone is table stakes.

2. How DKIM actually works

When you send an email, your mail server signs it using a private key. That private key lives on the sending server and never leaves it. The signature is added to the email headers as a DKIM-Signature field.

The receiving server looks up the corresponding public key in your DNS. It's published as a TXT record at a specific subdomain based on your selector name:

selector._domainkey.yourco.com

The receiver uses that public key to verify the signature. If it checks out, the message was signed by whoever controls the private key and hasn't been modified since. If it doesn't, DKIM fails.

The DKIM-Signature header in your outgoing email looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=yourco.com; s=google;
  h=from:to:subject:date; bh=...; b=...

d= is the signing domain. s= is the selector. Both matter for alignment.

3. Why DKIM matters more for cold email

Cold email targets people who haven't heard of you. Your domain has no relationship history with the recipient's mail provider. Every authentication signal you can provide gets weighted harder.

Gmail's spam filter uses DKIM signing history as a reputation input. A domain that has been consistently sending DKIM-signed mail for weeks or months is treated differently from one that just appeared. This is part of why warm-up works: you're building a verified signing history alongside reputation.

Without DKIM, you're sending cold to strangers with no proof of identity and no signing history. That's the worst starting position in deliverability.

There's also the DMARC dependency. DMARC requires either SPF or DKIM to pass with alignment. SPF fails on forwarded email. If someone forwards a cold email you sent, SPF breaks. DKIM is the fallback that keeps DMARC passing in those cases.

4. 1024-bit vs 2048-bit: why key size matters

DKIM keys come in different sizes. The most common are 1024-bit and 2048-bit.

1024-bit keys are deprecated. NIST stopped recommending them in 2013. Gmail and several other providers now treat 1024-bit DKIM signatures as a weak signal and weight them lower than 2048-bit signatures.

Most Google Workspace setups generated in the last few years use 2048-bit by default. Older setups, secondary domains configured years ago, or domains migrated from older providers may still be running 1024-bit keys.

How to check: look at the DKIM TXT record in DNS. The p= value is the base64-encoded public key. A 2048-bit key is roughly twice as long as a 1024-bit key. If you're unsure, use MXToolbox or a DKIM checker that surfaces the key size explicitly.

If you're on 1024-bit: regenerate a new key pair, publish the new public key in DNS, and switch the signing configuration on your mail provider. This is also a good time to rotate to a new selector.

5. Setting up DKIM for Google Workspace and Microsoft 365

Google Workspace: DKIM is not enabled by default. You have to generate the key and publish it manually.

1. Go to Google Admin, then Apps, then Google Workspace, then Gmail, then Authenticate email.
2. Select your domain and click Generate new record.
3. Copy the TXT record value and publish it in DNS at google._domainkey.yourdomain.com.
4. Wait for DNS to propagate, then return to Admin and click Start authentication.

The selector Google uses is google by default. You can customize it.

Microsoft 365: DKIM is auto-enabled for the default onmicrosoft.com domain. For custom domains you need to enable it manually in the Microsoft 365 Defender portal under Email authentication settings.

Microsoft uses two selectors: selector1 and selector2. They rotate between them automatically during key rotation. You publish both CNAME records pointing to Microsoft's infrastructure, not the key itself.

Common failure on secondary domains: DNS records are published but DKIM signing is never enabled in the admin panel. Mail goes out unsigned with no error.

6. Selectors: how to run DKIM across multiple sending services

A selector is just a label that identifies which key to use. It's part of the DNS record name:

google._domainkey.yourco.com      (Google Workspace)
selector1._domainkey.yourco.com   (Microsoft 365)
pm._domainkey.yourco.com          (Postmark)
s1._domainkey.yourco.com          (SendGrid)

Each service gets its own selector and its own key. You can have as many selectors as you want on a single domain. Unlike SPF, there's no lookup limit for DKIM.

This means you don't have to choose between services. Each one signs with its own key, and receivers verify against the matching selector in DNS. Clean separation, no conflicts.

When you stop using a service, remove its selector from DNS. Orphaned selectors aren't dangerous but they're noise that makes auditing harder.

7. DKIM survives forwarding. SPF doesn't.

When someone forwards an email, the sending server changes. The original sender's SPF record doesn't authorize the forwarding server. SPF fails. This is expected behavior, not a bug.

DKIM is unaffected by forwarding as long as the email content isn't modified. The signature is tied to the headers and body, not the sending IP. The forwarded message still carries the original DKIM signature, and it still validates against the original sender's DNS record.

Why this matters for cold email: if your DMARC policy is p=reject and you rely only on SPF for alignment, forwarded replies can fail DMARC and get rejected before reaching your prospect's inbox. If DKIM is properly set up and aligned, DMARC passes on the forwarded copy regardless of SPF.

This is also why DKIM alignment for DMARC is more reliable than SPF alignment alone. Build your DMARC setup around DKIM passing, and SPF is a secondary signal rather than a dependency.

8. How DKIM breaks silently

DKIM failures don't generate bounce messages or errors in your sending tool. The mail goes out, the signature fails verification, and the receiving server treats it as unauthenticated. Your dashboard shows sent. Your prospect's inbox shows spam.

The common failure modes:

• DNS record deleted or expired. Someone cleans up DNS entries, or the registrar loses the record during a migration. The key is gone, signatures fail instantly across all mail from that domain.
• Key generated but signing never enabled. Google Workspace requires you to explicitly enable DKIM after publishing the DNS record. Skipping that step means mail goes out unsigned with no indication anything is wrong.
• Provider switch without re-setup. You move a secondary from Workspace to Office 365. The Workspace DKIM record is still in DNS but the new provider is signing with a different key (or not signing at all). Signatures fail or are absent.
• Content modification breaking the signature. Some mailing list software and spam filters rewrite email headers or add footers. That modifies the content after signing and invalidates the DKIM signature. Less relevant for cold email tools but worth knowing.
• Selector mismatch. The selector in the outgoing DKIM-Signature header doesn't match any TXT record in DNS. Receivers can't find the public key to verify against. Hard fail, no warning.

9. Key rotation: the maintenance task nobody does

DKIM private keys should be rotated periodically. The reasoning: a key that's been in use for years is a key that's had more exposure. If the private key is ever compromised, an attacker can forge signed emails that pass DKIM verification. Rotation limits that window.

The practical standard for cold senders is once per year, or whenever you change providers.

How to rotate without downtime:

1. Generate a new key pair with a new selector name (e.g., google2024 instead of google).
2. Publish the new public key in DNS.
3. Wait for DNS propagation (a few minutes to an hour).
4. Switch your mail provider to sign with the new selector.
5. Keep the old selector in DNS for 48 hours to cover any in-flight messages still being delivered.
6. Remove the old selector after 48 hours.

Microsoft 365 handles rotation automatically between selector1 and selector2. Google Workspace requires manual rotation. Most operators on Workspace have never rotated.

10. Operator FAQ