DKIM Key Rotation, Multiple Selectors, and Debugging Silent Failures

DKIM breaks silently — and the symptoms look exactly like spam problems

DKIM (DomainKeys Identified Mail) signs outgoing emails with a cryptographic signature. Receiving mail servers verify the signature against a public key published in DNS. When DKIM fails — wrong selector, expired key, mismatched domain, signature stripped in transit — the failure often goes unnoticed until deliverability drops, DMARC reports show failures, or emails start landing in spam.

Understanding DKIM beyond the basics — key rotation, multiple selectors, alignment requirements, and the most common failure modes — gives you the diagnostic tools to catch and fix problems before they compound.

How DKIM signatures work (briefly)

When your mail server sends a message, it:

1. Computes a hash of specified message headers and the body
2. Signs the hash with your private key
3. Adds the signature as a DKIM-Signature header

The receiving server:

1. Reads the d= (domain) and s= (selector) values from the DKIM-Signature header
2. Queries DNS for the public key at <selector>._domainkey.<domain>
3. Uses the public key to verify the signature matches the headers and body

A valid DKIM signature proves:

• The message was sent by a server with access to the private key
• The specified headers and body were not altered in transit

It does not prove:

• The message isn't spam
• The From address is accurate (DMARC handles alignment with From domain)
• Content beyond what was signed was unaltered

Selectors: why they exist and how to use them strategically

A DKIM selector is the name of the key pair you're using. The public key is published in DNS at <selector>._domainkey.<domain>. The selector name is arbitrary — it's just a label for the key.

Most default DKIM implementations use a generic selector like default or mail or an identifier like google (for Google Workspace) or s1/s2 (for rotation).

Why multiple selectors matter:

Multiple sending sources: each service sending email on behalf of your domain should have its own DKIM key (and its own selector). Google Workspace, your transactional email provider (Postmark, Mailgun, SendGrid), your marketing platform (Mailchimp, HubSpot), and any other sender should each have distinct DKIM keys published under distinct selectors.

This matters for DMARC and troubleshooting: when DMARC reports show failures, you can identify which sending source is the problem because each has a distinct selector.

Example multi-source setup:

google._domainkey.example.com     → Google Workspace key
pm._domainkey.example.com         → Postmark key  
s1._domainkey.example.com         → Primary key for your own mail server
s2._domainkey.example.com         → Rotation key (current or upcoming)

Key rotation: why and how

DKIM keys should be rotated periodically — every 6–12 months is a common recommendation, though practice varies. Rotation limits exposure if a key is compromised.

The rotation process without service interruption:

1. Generate a new key pair (new private key + new public key)
2. Publish the new public key in DNS under a new selector (e.g. s2._domainkey.example.com)
3. Wait for DNS propagation (TTL of the existing record, typically 1–24 hours)
4. Update your mail server configuration to sign with the new private key and new selector
5. Verify the new selector works — send a test email and check the DKIM-Signature header shows the new selector; verify with a DKIM checker tool
6. Keep the old selector active for 48–72 hours — messages sent before the switch may still be in transit and will be verified against the old key
7. Remove the old selector from DNS after the transition period

Skipping step 6 causes verification failures for in-flight messages — a subtle bug that's hard to diagnose because the emails look fine when sent but fail verification when delivered.

DKIM alignment: the DMARC connection

DMARC requires DKIM alignment to pass — meaning the domain in the DKIM signature (d= tag) must match or be a parent domain of the From: address.

Example of aligned DKIM:

• From: sender@example.com
• DKIM d= tag: example.com
• Aligned ✓

Example of misaligned DKIM:

• From: sender@example.com
• DKIM d= tag: mymailprovider.com (the ESP's own domain)
• Misaligned ✗ — DMARC will fail DKIM alignment check

This is a common misconfiguration when using email service providers. Many ESPs sign with their own domain by default. For DMARC DKIM alignment to pass, you need the ESP to sign with your domain (using a key you've published in your DNS).

Most major ESPs support this — the process involves adding a DKIM record to your DNS for their signing infrastructure. Check your ESP's documentation for "custom DKIM" or "authenticated domain" setup.

Debugging DKIM failures

Step 1: Check the raw message headers

Most email clients allow "View original" or "Show headers." Look for:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
Authentication-Results: dkim=pass

If dkim=fail or there's no DKIM-Signature at all, you have a problem.

Step 2: Verify the selector in DNS

Check the DNS record for the selector used: google._domainkey.example.com

Using the DKIM Checker on sadiqbd.com:

1. Enter your domain
2. Enter the selector from the DKIM-Signature header (s= tag)
3. The tool queries DNS and shows whether the public key record exists and is valid

Step 3: Common failure causes

Selector not in DNS: the key was never published, was published under the wrong name, or was accidentally deleted.

Wrong key format: DKIM public keys in DNS use a specific format (p=<base64-encoded-key>). Missing the v=DKIM1; k=rsa; p= prefix causes lookup failure.

Key length too short: 512-bit keys are no longer accepted by many mail systems. Minimum 1024-bit; 2048-bit is recommended for new keys.

Mailing list modification: some mailing lists add content (footers, headers) that breaks the DKIM signature because the signed body hash no longer matches. This is a known incompatibility between DKIM and mailing lists.

Body canonicalisation mismatch: DKIM signs using either "relaxed" or "strict" canonicalisation for headers and body. Some gateways or spam filters modify whitespace in ways that break strict canonicalisation. Using relaxed/relaxed canonicalisation is more resilient.

How to use the DKIM Checker on sadiqbd.com

1. Enter your domain — the domain in the d= tag of the DKIM-Signature
2. Enter the selector — the value in the s= tag of the DKIM-Signature header, or the selector you've configured
3. Check — the tool queries <selector>._domainkey.<domain> and shows:
   • Whether the record exists
   • The key type and length
   • Whether the record is syntactically valid
4. Verify for every sending source — run a check for each selector you've published

Frequently Asked Questions

How many DKIM selectors can I have? As many as you need. Each is a separate DNS TXT record. There's no limit. Having multiple selectors — one per sending service — is good practice.

DKIM is passing but DMARC is still failing on DKIM. Why? Alignment. The DKIM d= domain doesn't match the From: header domain. You need the DKIM signature to use your domain, not your ESP's domain.

Do I need both SPF and DKIM? DMARC only needs one of them to pass and align. But having both is better — if SPF fails (forwarded email, third-party sender), DKIM can still pass DMARC. SPF alone fails on email forwarding; DKIM survives forwarding as long as headers aren't modified.

Is the DKIM Checker free? Yes — completely free, no sign-up required.

DKIM failures are quiet until they're not — DMARC reports are often the first signal of a selector problem, and deliverability drops are the eventual consequence. The checker makes diagnosis a 10-second task instead of an hour of header archaeology.

Try the DKIM Checker free at sadiqbd.com — verify any domain's DKIM selector in DNS instantly.