DKIM Errors and Fixes: Selector Not Found, Hash Mismatch, Alignment

June 20, 2026 • InboxGreenEmail Team

DKIM failures often look identical from the outside: your email arrives, but headers show dkim=neutral or dkim=fail. The cause could be a missing DNS record, a misconfigured ESP, a forwarding issue, or a key that is too short. Each has a different fix.

Start here: run the DKIM Checker to see what is in your DNS, then open a failing message in Gmail (More → Show original) to find the s= selector and the actual result.

1. No DKIM signature found in the message headers

If the headers show no DKIM-Signature field at all, the sending server never signed the message. SPF can still pass, but DMARC alignment via DKIM is impossible. This is a setup problem, not a DNS problem.

Common causes:

• You added the DKIM DNS record but never clicked "Enable" or "Activate" in your ESP's settings
• You are sending from a domain that has no DKIM configuration at your ESP
• The sending account is using the ESP's default shared domain instead of your authenticated custom domain

Fix: Go to your ESP's domain authentication settings and confirm that:

• Your domain is added as a sending domain
• DKIM is enabled (not just configured)
• You are sending from that domain, not from an alias or subdomain that is not authenticated

See the provider-specific guides for step-by-step instructions at Google Workspace, SendGrid, Mailgun, Brevo, and others.

2. DKIM selector does not exist in DNS

Every DKIM signature includes a s= tag that names the selector. The verifying server constructs a DNS lookup from that: {selector}._domainkey.{domain}. If that TXT record is not in your DNS, verification fails.

The error in headers looks like: dkim=neutral (no key) or dkim=fail (no key for selector).

How to diagnose it:

1. Open the raw headers of a failing message and find the DKIM-Signature field
2. Note the s= value (the selector name)
3. Look it up: use the DKIM Checker with your domain and that selector

Common causes of a missing selector:

• Published the DNS record under the wrong hostname (e.g., double-pasted the domain: google._domainkey.yourdomain.com._domainkey.yourdomain.com)
• The CNAME or TXT record was deleted during a DNS migration
• The ESP rotated its DKIM keys and the new selector was not published
• The record has not propagated yet (wait 30 to 60 minutes after adding it)

3. DKIM body hash mismatch

DKIM signs the message body and selected headers. If anything modifies the message in transit, the signature will not verify. The header shows dkim=fail (bad signature).

The most common cause is email forwarding. When a mailbox at [email protected] forwards to a personal Gmail address, the forwarding server sometimes modifies the message (adds a footer, re-encodes characters, or rewrites headers). DKIM fails because the body hash no longer matches.

This is expected behavior and not a configuration error on your part. DMARC receivers handle this with ARC (Authenticated Received Chain), which some forwarders implement to preserve the original authentication result.

What to do:

• If this is affecting forwarded copies of your email, there is nothing to fix on your end. DKIM is working correctly for direct delivery.
• If this is happening on direct delivery (not forwarded), check that your ESP is not modifying message content after signing. Some tracking or click-wrapping features alter the body before delivery.
• Ensure DKIM alignment passes for direct delivery. DMARC passes as long as direct recipients see a valid DKIM signature.

4. DKIM key too short (1024-bit)

Older DKIM configurations used 1024-bit RSA keys. Gmail and other major receivers now flag 1024-bit keys as insufficient and may downgrade their trust evaluation. The header result is still dkim=pass, but reputation scoring treats it differently.

Some receivers require 2048-bit minimum. RFC 8301 (2018) formally deprecated 1024-bit keys.

How to check your key length:

Use the DKIM Checker. The result shows the key length. If it says 1024, regenerate.

How to fix it:

• In your ESP, generate a new 2048-bit DKIM key (most modern ESPs default to 2048 now)
• Publish the new TXT or CNAME record in your DNS
• Wait for propagation, then enable the new key in your ESP
• Delete the old 1024-bit DNS record after confirming the new one is working

For Google Workspace: go to Admin Console → Gmail → Authenticate email, generate a new key, and republish. Google defaults to 2048-bit for newly generated keys.

5. DKIM passes but DMARC still fails (alignment)

DMARC checks whether the domain in the DKIM d= tag matches the domain in the From: header. If your ESP signs messages with their own domain (d=sendgrid.net) instead of yours (d=yourdomain.com), DKIM passes but DMARC alignment fails.

This is the most common DMARC alignment problem for senders using ESPs with shared infrastructure.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=sendgrid.net; s=s1; ...
Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net;
  dmarc=fail (p=REJECT) header.from=yourdomain.com

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=s1; ...
Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=REJECT) header.from=yourdomain.com

Fix: Use your ESP's custom domain authentication feature:

• SendGrid: Sender Authentication under Settings
• Mailgun: Domain settings, add your domain
• Brevo: Senders & IPs → Domains
• Mailchimp: Domains section, verify your sending domain

Once configured correctly, the ESP signs with d=yourdomain.com and DMARC alignment passes. See the Email Authentication Guides for provider-specific steps.

6. DKIM worked, then stopped working

If DKIM was passing and then started failing without any changes on your end, check:

• DNS migration: the DKIM TXT or CNAME record was not transferred when moving registrars or nameservers
• ESP key rotation: some ESPs automatically rotate DKIM keys and require you to update the DNS record. Check your ESP's notification settings.
• CNAME chain broken: for CNAME-based DKIM (SendGrid, Mailchimp), the CNAME must resolve correctly. If the ESP changed their infrastructure, the CNAME target may have changed.
• TTL caching: if you recently made changes, old resolvers may still have the previous record cached. Check from multiple locations using the DKIM Checker.

Run the full deliverability scan to get a current read on all three protocols at once.

DKIM Tools

Related Guides

Common Questions About DKIM