DKIM for cold email

DKIM is the signature on your mail. SPF says which servers may send for your domain; DKIM proves the message itself came from you and was not altered in transit. Of the three authentication records, DKIM is the one most often left half-configured on cold email domains, because the provider generates the key but someone still has to publish it in DNS. Here is how it works and how to finish the setup.

What DKIM is

DKIM (DomainKeys Identified Mail) uses a key pair. Your mail provider holds the private key and signs every outgoing message with it. The matching public key is published in your DNS. A receiving server reads the signature header, fetches the public key, and verifies the message.

The public key lives at a predictable DNS location:

<selector>._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The selector is the label before ._domainkey. It lets one domain hold multiple keys at once. Google uses the selector google by default. Microsoft 365 uses selector1 and selector2. Sending platforms generate their own, like s1 or smtp.

A signed message carries a header that names both the domain and the selector:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google; ...

The receiver combines s= and d= to find the key: google._domainkey.yourdomain.com.

Why it matters for a cold email launch

• DKIM survives forwarding. SPF does not. When mail is forwarded, the connecting server changes and SPF breaks. The DKIM signature travels with the message.
• DMARC alignment usually rides on DKIM. For cold email through a sending platform, DKIM signed with your own domain is typically what makes DMARC pass.
• Google and Yahoo require it for bulk senders. Unauthenticated mail to Gmail and Yahoo gets rejected or filtered under the 2024 sender requirements.
• A missing key fails silently. The provider signs the mail, the receiver looks up a key that was never published, and verification fails on every message. Nothing errors on your side.

How to set it up

Google Workspace

1. Open Admin console, then Apps, Google Workspace, Gmail, Authenticate email.
2. Select the domain and click Generate new record. Choose 2048-bit unless your DNS host cannot store the longer value.
3. Publish the record it gives you:

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF..."

4. Back in the Admin console, click Start authentication. Google will not sign with the new key until you do this, and it can take up to 48 hours to take effect.

Microsoft 365

1. Open the Defender portal, then Email and collaboration, Policies and rules, Threat policies, Email authentication settings, DKIM.
2. Select the domain. Microsoft shows two CNAME records to publish:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

3. Publish both, then toggle signing on for the domain. Two selectors exist so Microsoft can rotate keys for you without downtime.

Verify

Look up the selector and confirm the public key resolves. The DKIM checker takes a domain and selector and confirms the key exists and parses. Then send a test message to a Gmail address, open Show original, and check for DKIM: PASS with your domain.

Key rotation

DKIM keys should not live forever. If a private key leaks, an attacker can sign mail as you until the public key changes. Rotation practice:

• Rotate roughly every 6 to 12 months. Generate a new key under a new selector, publish it, switch signing, then remove the old record after a few days.
• Microsoft 365 rotates automatically across its two selectors. Google requires a manual regenerate.
• Use 2048-bit keys. 1024-bit keys still verify but are weak, and some receivers score them down.

For a small fleet of cold email domains, put rotation on a calendar. It is a 10-minute task per provider and it only hurts when skipped for years.

Common mistakes

1. Key generated but never published. The most common failure. The provider dashboard shows a record; someone forgot the DNS step.
2. Published but never activated. Google requires clicking Start authentication. Until then, mail goes out unsigned.
3. Wrong selector checked. Verifying default._domainkey when your provider signs with google tells you nothing. Get the selector from a real message header.
4. DNS host mangles the long value. Some hosts split 2048-bit keys across quoted strings incorrectly, or truncate them. If the key will not verify, compare the published value character for character.
5. Signing with the platform’s domain instead of yours. If the signature says d=sendingplatform.com, it does not align with your From domain and does nothing for your DMARC. Configure the custom DKIM domain in the sending tool.
6. Copying the record between domains. Each domain gets its own key pair. A pasted key from another domain will never verify.

FAQ

Do I need DKIM on every sending domain? Yes. Every cold email domain needs its own key, published and activated, per provider.

Can a domain have multiple DKIM keys? Yes. Selectors exist for exactly this. Google Workspace and a sending platform can each sign with their own selector on the same domain.

Does DKIM encrypt my mail? No. It signs the message so tampering is detectable. Content is not encrypted by DKIM.

How do I find which selector my mail uses? Send yourself a message and read the DKIM-Signature header. The s= value is the selector.

DKIM is one of 16 checks OutboundQA runs before a launch, alongside SPF and DMARC. Check a single selector with the DKIM checker, or run all three records at once with the auth checker.