Troubleshooting “Invalid DKIM Signature” after Migration

When migrating an organization between mail platforms—such as moving from Microsoft 365 to Google Workspace, or switching DNS hosting providers—outbound messages often fail authentication with errors like dkim=neutral (bad sig) or dkim=fail (test mode). This happens because the receiving server cannot cryptographically validate the message signature against the public key published in your DNS. The issue typically traces back to mismatched selectors, post-signing message modification, or syntax errors in the new DNS records.

Quick Answer

An invalid DKIM signature after migration usually means the new mail server is signing with a key that does not match the active DNS selector, or an intermediary security filter modified the message after it was signed. Verify that the active selector in DNS matches the sender, update the public key, and disable footer injection.

---

What “Invalid DKIM Signature” Means

DomainKeys Identified Mail (DKIM) adds an encrypted digital signature to the headers of outbound emails. This signature is generated using a private key kept secure on your sending server. The receiving mail server retrieves your matching public key from a specific TXT record in your DNS (identified by a “selector”) and decrypts the signature.

When a receiver reports dkim=fail or bad sig, it means the cryptographic handshake failed in one of two ways:

1. The Public Key Failed to Decrypt the Signature: The public key in DNS does not match the private key used by the new mail server.
2. The Message Hash Did Not Match: The signature decrypted successfully, but the message content (body or protected headers) changed between the moment the server signed it and the moment the recipient received it.

[Sending Server]
Signs email with Private Key ────► [Outbound Gateway / Relays]
                                    If gateway alters body/footer:
                                    HASH BREAKS (Invalid Signature)
                                              │
                                              ▼
[Recipient Server] ◄─────────────── [Delivered Message]
Queries DNS for Public Key
Evaluates Signature vs Body Hash

---

Common Causes After a Platform Migration

A migration introduces several configuration handoffs where DKIM easily breaks:

• Active Signing on an Old Selector: The new tenant was configured to sign outbound email using a default selector (for example, google or selector1), but the DNS record was never published, or the domain is still pointing to the legacy platform’s selector.
• Security Gateway Tampering (Body Modifications): If outbound mail routes through a security gateway (like Mimecast, Proofpoint, or an on-premises hygiene appliance) after leaving the new mailbox provider, that gateway may append a legal disclaimer, rewrite links, or inject tracking pixels. Altering even a single character invalidates the body hash (bh=).
• Truncated 2048-bit Keys in DNS: Modern DKIM keys are 2048 bits long, resulting in text strings exceeding 255 characters. Some DNS management interfaces silently truncate strings past 255 characters unless split into multiple quoted strings, corrupting the public key. For key creation guidelines, review How to Generate 2048-bit DKIM Key in Admin Console.
• Stale DNS Resolver Caching: If a selector record was altered or replaced during the cutover, receiving mail systems may still read cached, outdated public keys. If you suspect propagation delays, consult How to Fix DNS Propagation Lag for New Domains.

---

Diagnostic Steps: Isolating the Cryptographic Failure

To pinpoint why the signature fails, inspect the raw headers of a delivered or bounced email. For instructions on opening headers, see How to Read Gmail “Original Message” Headers.

1. Analyze the Authentication Header

Locate the Authentication-Results header. A failing entry typically reads:

Authentication-Results: mx.google.com;
       dkim=fail header.i=@example.com header.s=2024 migration header.b=Ab3x9Z...

Take note of two specific tags:

• header.s=: The selector being used to query DNS.
• The exact failure description (bad sig, key syntax error, or no key).

2. Check the DKIM-Signature Header

Next, look at the DKIM-Signature header added by your sending platform:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
s=google; t=1711900000;
h=to:subject:message-id:date:from:mime-version;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=hYd7f8...

• bh= (Body Hash): A cryptographic hash of the message body.
• b= (Header Signature): The cryptographic hash of the listed headers and the body hash.

3. Determine if the Failure is b= or bh=

• If the receiver explicitly reports “body hash did not verify” (bh mismatch): The public key in DNS is correct, but something altered the body or inline formatting after signing.
• If the receiver reports “bad signature” or “verification failed” across the board: The public key in DNS does not match the private key on the sending server, or the selector TXT record is missing or corrupted.

4. Query the Authoritative DNS Record

Using a terminal or command prompt, verify what the world sees for that selector:

dig selector._domainkey.example.com TXT +short

Ensure the string begins with v=DKIM1; k=rsa; p= and that the public key string (p=) has no internal whitespace or missing characters. If your query returns an empty response, refer to DKIM “Public Key Not Found” Error.

---

Technical Fixes

Fix 1: Align the Active Selector and Enable Signing

If you moved to a new provider, you must generate a new key inside that provider’s administrative portal, publish it to DNS, and explicitly turn on signing:

1. In your mail administration console (e.g., Google Workspace Admin Console or M365 Defender), locate the DKIM settings.
2. Generate a new key. Note the selector prefix (e.g., google).
3. Add the TXT record to your DNS host:
   • Name/Host: selector._domainkey.yourdomain.com
   • Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA...
4. Return to the mail administration console and click Start Authentication. Ensure status indicators show active signing.

Fix 2: Adjust Signing Order for Outbound Gateways

If your organization routes mail through a hygiene service or outbound scanner:

• Option A: Configure the mail flow so the hygiene service signs the message last, right before final egress to the internet.
• Option B: Disable dynamic footer injection, disclaimer appending, and URL rewriting on outbound messages in the intermediate filter.

Fix 3: Handle 2048-Bit DNS String Splitting

If your DNS host returns an invalid key syntax error, the 2048-bit string may have exceeded single-string limits. In BIND or zone file editors, format the TXT entry inside parentheses as two quoted strings:

google._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA12345..."
"67890abcdefghijklmnopqrstuvwxyz..." )

Most modern cloud DNS providers (such as Cloudflare or AWS Route 53) automatically concatenate multiple strings within a single record, but legacy registrar consoles require manual splitting.

When swapping or updating keys during migrations, follow established key retirement methods to avoid dropping in-flight mail; see How to Rotate DKIM Keys Without Breaking Delivery.