How to Set Up DKIM: Step-by-Step Guide for 2026

Setting up DKIM is the second of the three authentication steps every B2B cold email sender needs in 2026. Unlike SPF (which authorizes IPs), DKIM cryptographically signs the email itself — so receiving servers can verify the message wasn’t modified in transit and that it genuinely came from your domain. The setup is moderately technical but predictable when followed correctly. This article walks through the full DKIM setup process: key generation, DNS configuration, selector strategy, and verification. It pairs with the SPF setup guide, the DMARC policy guide, and the SPF/DKIM/DMARC overview.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email. The sending server signs the message with a private key; the receiving server fetches the matching public key from your DNS and verifies the signature. DKIM-passing email is treated as more trustworthy by every major receiving system — and DKIM-failing email is treated as a strong spam signal.

How DKIM works

When your mail server sends an email, it adds a DKIM-Signature header to the message. The signature is computed using a private key the sending server holds, applied across specific header fields and the message body. The header includes the domain name and the “selector” (a label identifying which key was used — useful when rotating keys).

When the email arrives at the receiving server, the server:

1. Reads the DKIM-Signature header
2. Extracts the domain and selector
3. Looks up the public key at <selector>._domainkey.<domain> in DNS
4. Uses the public key to verify the signature

If the signature verifies, DKIM passes. If the signature can’t be verified — wrong key, modified message in transit, missing DNS record — DKIM fails.

Step-by-step DKIM setup

The exact steps depend on which sending service you’re using, but the pattern is consistent.

Step 1: Generate or obtain the public/private key pair. Most modern sending services (Google Workspace, Microsoft 365, Smartlead, Lemlist, Apollo, SendGrid) generate the key pair for you and give you a public key to publish in DNS. They hold the private key. For self-hosted mail servers (Postfix + OpenDKIM), you generate the keys yourself using opendkim-genkey.

Step 2: Get the public key value from your sending service. Log into the service’s admin panel and look for “DKIM” or “Email authentication” settings. The service provides:

• A selector name (e.g., google, s1, smartlead, default)
• The public key value (a long base64-encoded string)
• The DNS record name to use (the format is <selector>._domainkey.<domain>)

For Google Workspace specifically: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record.

Step 3: Add the DKIM record to DNS. The DKIM record is a TXT record. The host/name is <selector>._domainkey (e.g., google._domainkey or s1._domainkey). The value is what the sending service provided, typically formatted like:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK...

Long DKIM keys may exceed 255 characters (the limit per TXT-record string). Most DNS providers handle this automatically by splitting the value into multiple quoted strings within the same record. If your provider doesn’t, you may need to split manually with quoted segments.

Step 4: Wait for DNS propagation. Usually 5–60 minutes. Some providers (Cloudflare, AWS Route53) propagate within seconds; others (older registrars) take longer.

Step 5: Verify the DKIM record is in place. Run dig +short TXT <selector>._domainkey.<domain> — you should see the DKIM value. Online tools like MXToolbox’s DKIM Lookup or DKIM Core’s testing tool also verify the public key is syntactically valid.

Step 6: Verify signing is working. The DNS record being correct doesn’t mean signing is working. Send a test email from the sending service to a test address (Gmail or Outlook with full headers visible). Inspect the headers — you should see a DKIM-Signature header on outgoing mail, and dkim=pass in the Authentication-Results header on the receiving side.

Selector strategy

The selector is a label that lets you have multiple DKIM keys for the same domain. Production teams use selectors strategically:

• Per-service selectors: When using multiple sending services (e.g., Google Workspace for day-to-day mail and Smartlead for cold outreach), each service gets its own selector. Example: google._domainkey.yourdomain.com and smartlead._domainkey.yourdomain.com. This isolates the keys per service.

• Rotation: Production teams rotate DKIM keys periodically (every 6–12 months) for security. The rotation pattern: deploy a new key with a new selector, switch sending to the new selector, leave the old selector in DNS for a few weeks until in-flight mail completes, then remove the old selector.

• Subdomain separation: When using subdomains for different purposes (transactional vs marketing vs cold outreach), each subdomain has its own DKIM record. The selector can be the same name across subdomains, but the underlying records are different.

Most teams set up DKIM once per service and don’t rotate for the first year. Mature teams rotate annually as a security hygiene practice.

Key length considerations

DKIM supports 1024-bit and 2048-bit RSA keys. As of 2026, the consensus is:

• 2048-bit: The standard recommendation. Stronger cryptographically, future-proof. The downside: the key is longer and may require DNS handling for multi-string TXT records (covered above).
• 1024-bit: Still works, still passes verification on every major receiving system. Marginally weaker but operationally simpler.

Production teams use 2048-bit when the DNS provider handles long records cleanly (Cloudflare, AWS Route53, most modern providers). They use 1024-bit when stuck with older DNS infrastructure that doesn’t handle long records well.

Common DKIM setup mistakes

Adding the record at the wrong DNS host. The DKIM record needs to be at <selector>._domainkey.<domain>, not at <domain> itself. Some DNS UIs make this confusing. If verification fails immediately after setup, this is the first thing to check.

Truncating long keys. 2048-bit keys exceed the 255-char TXT-string limit and need to be split. DNS providers usually handle this, but copy-paste errors can truncate the key. Always verify the full key is in place using dig +short TXT <selector>._domainkey.<domain>.

Mixing private and public key. The DNS record contains the public key. The sending service holds the private key. Never put the private key in DNS. Most teams don’t make this mistake explicitly, but rare bad documentation can lead to it.

Setting up DKIM but not actually signing. Adding the DNS record without configuring the sending service to sign outgoing mail produces a published public key that’s never used. Always verify outgoing mail actually contains DKIM-Signature headers.

Multiple DKIM records at the same selector. Some DNS UIs let you add two TXT records at the same host. DKIM expects one record per selector; multiple records cause verification failure.

Not aligning DKIM with the From-domain. DKIM can sign with one domain while the email’s From-address uses a different domain (when relay services are involved). DMARC alignment requires the DKIM-signing domain to match the From-domain (or the organizational domain). If you’re using a sending service that signs with their domain instead of yours, you may need to use a custom DKIM setup that aligns properly.

Skipping the signing-verification step. Many setup failures only surface when you actually inspect outgoing mail headers. The DNS record being correct doesn’t guarantee signing is happening. Always test with a real outgoing email.

What to do after DKIM is set up

DKIM is the second of the three authentication pieces. The third is DMARC, which ties SPF and DKIM together and adds a policy statement. Covered in detail in DMARC policy: quarantine vs reject.

Operationally, once DKIM is set up:

1. Verify both SPF and DKIM pass for outgoing mail from each sending service
2. Set up DMARC in monitoring mode (p=none) to gather data on authentication
3. Review DMARC reports weekly for the first month to catch authentication issues before tightening to quarantine or reject

DKIM setup is a 30–45 minute task done once per sending service. Done correctly, it produces consistent authentication that supports inbox placement; done incorrectly, it silently fails and downstream campaign performance drops.