Common DKIM Errors: Troubleshooting Cryptographic Verification Failures

Anatomy of a DKIM Verification Failed Error: What Really Happens

You've configured DKIM, published your DNS records, and your mail server is signing emails. Yet when you check your DMARC reports or look at email headers, you see the dreaded phrase: dkim=fail. What went wrong?

To understand DKIM failures, you need to understand exactly how DKIM verification works. When a receiving server verifies a DKIM signature, it performs these steps:

1. Parse the DKIM-Signature header: Extract tags including s= (selector), d= (domain), bh= (body hash), b= (signature), h= (signed headers), and c= (canonicalization).
2. Look up the public key: Perform a DNS TXT lookup for [selector]._domainkey.[domain]. If this lookup fails (NXDOMAIN, timeout, or returns no record), verification fails immediately.
3. Hash the email body: Apply the body canonicalization algorithm (simple or relaxed) to the email body, then hash it using the specified algorithm (usually sha256). Compare this hash to the bh= tag value. If they don't match, verification fails.
4. Hash the selected headers: Apply header canonicalization to the headers listed in the h= tag (typically From, Subject, Date, plus others). Hash the result.
5. Verify the signature: Use the public key from DNS to decrypt the signature in the b= tag. The decrypted result should match the hash from step 4. If not, verification fails.

A failure can happen at any step. Understanding which step failed is the key to troubleshooting. Most DKIM failures fall into one of three categories: DNS issues (can't find or retrieve the key), body hash mismatches (content changed in transit), or signature mismatches (headers changed or key mismatch).

Let's explore the most common causes of each failure type.

How Mail Forwarders and Antivirus Software Tamper with the Body

Body hash mismatches are among the most frustrating DKIM failures because they're often caused by systems you don't control—email forwarders, security gateways, and mailing list managers.

Common Body Modification Scenarios

• Email forwarding services: When a recipient uses forwarding (e.g., Gmail forwards to Outlook), the forwarding server may add a footer ("Forwarded message from...") or alter the message structure. This changes the body content, breaking DKIM.
• Antivirus and spam filtering gateways: Security appliances often modify emails by adding warning banners, rewriting URLs, or stripping attachments for quarantine. Each modification changes the body hash.
• Mailing lists (Listserv, Google Groups, etc.): Mailing list software typically adds footer text ("You received this message because..."), subject tags ("[List Name]"), and alters headers. These changes break original DKIM signatures.
• Corporate email security policies: Some organizations insert disclaimers, confidentiality notices, or DLP (Data Loss Prevention) warnings into incoming emails. While well-intentioned, these modifications invalidate DKIM.
• Line ending conversions: SMTP servers sometimes convert line endings from CRLF to LF or vice versa. Depending on canonicalization settings, this can break signatures.

The ARC Solution (Authenticated Received Chain)

ARC is a newer standard designed specifically to solve the forwarding problem. When an intermediary modifies an email, it adds an ARC seal that "chains" the original authentication through the modification. Receiving servers can verify the original DKIM signature and trust the intermediary's modifications if they're properly sealed.

Major email providers including Google, Microsoft, and Yahoo support ARC. When configuring your mail server, enable ARC signing if available. For forwarded emails, you're at the mercy of the forwarding service—Gmail, Outlook, and Fastmail support ARC; many smaller providers do not.

Preventing Body Modification Failures

• Use Relaxed Canonicalization: Setting c=relaxed/relaxed makes body hashing tolerant of minor whitespace changes (like line ending differences).
• Sign Complete Headers: Include all headers that might be modified legitimately (like Received and Authentication-Results) in your signature. This provides more flexibility.
• Monitor Forwarding Volumes: If your mailing lists have high volume, consider having the mailing list re-sign emails with its own DKIM key instead of passing through the original signature.
• Educate Recipients: Encourage customers to add your From address to their address book or whitelist, reducing reliance on forwarding.

Use our DKIM Checker's header analysis feature to see whether failures are due to body hash mismatches or other causes. The tool highlights the specific verification step that failed.

DNS Character Limits: Handling 2048-Bit Keys in TXT Records

DNS TXT records have a maximum length of 255 characters per string chunk. However, you can split a single logical record across multiple quoted strings. A 2048-bit RSA key's base64 representation is approximately 390 characters, requiring careful splitting.

The Problem: Corrupted Multi-String Records

Many DNS management panels automatically split long TXT record values at 255 characters. However, they may split incorrectly:

Incorrect splitting (breaks DKIM):
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..." "t4h5..."

The problem occurs when the split happens inside the base64 key instead of at a natural boundary, or when the DNS provider adds extra spaces, quotes, or line breaks.

Correct Multi-String Format

A valid DKIM TXT record with multiple strings should look like this in your DNS panel:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..." "..." "..."

Most modern DNS providers handle this automatically. However, if you're experiencing verification failures:

1. Check your actual DNS record using dig TXT [selector]._domainkey.yourdomain.com
2. Look at the output. If you see extra spaces, backslashes, or line breaks inside the record, your DNS provider has corrupted it.
3. The fix varies by provider. Common solutions:
   • Cloudflare: Uses TXT records with automatic splitting that works correctly. No action needed.
   • GoDaddy: Known to add extra quotes. Manually remove quotes or use their "TXT (multiple)" record type.
   • AWS Route53: Handles splitting correctly when you paste the entire value as a single string.
   • Namecheap: May require manually splitting at 255 characters and wrapping each chunk in quotes.

Testing Your DNS Record Format

Use our DKIM Checker to validate your DNS record format. The tool performs a raw DNS lookup, reconstructs multi-string records, and verifies that the resulting public key is valid base64 and can parse correctly.

Pro tip: If you continue having issues, switch to a DNS provider with a reputation for correct DKIM handling (Cloudflare, AWS Route53, Google Cloud DNS). Avoid providers known for formatting bugs.

Selector Configuration Mistakes: The Subdomain Name Trap

Selector errors are incredibly common, especially for administrators new to DKIM. The mistake usually involves misunderstanding the DNS record name format.

The Correct Format

A DKIM public key record must be published at exactly:

[selector]._domainkey.yourdomain.com

For example, if your selector is "google" and your domain is "example.com":

google._domainkey.example.com

Common Mistakes

• Duplicate domain: google._domainkey.example.com.example.com (DNS panel auto-appends your domain, and you also typed it)
• Missing underscore: google.domainkey.example.com (underscore before "domainkey" is required)
• Wrong order: _domainkey.google.example.com (selector goes before _domainkey, not after)
• Trailing dot issues: google._domainkey.example.com. (trailing dot is technically correct but may confuse some panels)
• Capitalization: Google._domainkey.example.com (selectors are case-sensitive; use exactly what your mail server uses)

How to Verify Your Record Name

Use the dig command to check if your record exists:

dig TXT google._domainkey.example.com

If you get NXDOMAIN (non-existent domain), you have a selector or domain name error. If you get a response but the record is incorrect, check the actual record content.

Our DKIM Checker automatically validates your record name format and shows you exactly what DNS query it's performing, making selector typos immediately obvious.

Escaping Semicolons and Quotes in DNS Panels

DKIM TXT records use semicolons as delimiters between tags. For example: v=DKIM1; k=rsa; p=MIGf.... However, some DNS management panels treat semicolons as special characters requiring escaping, while others do not.

The Escaping Problem

If your DNS panel requires escaping but you don't escape, the semicolons may be interpreted as record separators, truncating your public key. Conversely, if your panel does NOT require escaping but you add backslashes, the backslashes become part of the record, corrupting it.

How to Determine the Correct Format

1. Check your DNS provider's documentation for DKIM specifically. Many have published guides.
2. Test with a temporary selector. Publish a test record and immediately query it with dig to see what actually got stored.
3. Look for examples from your provider's support forums or knowledge base.

Provider-Specific Guidance

• Cloudflare: No escaping needed. Paste the raw DKIM value as-is.
• AWS Route53: No escaping needed. Use the standard TXT record format.
• GoDaddy: Known to require double-quoting around the entire value. Use: "v=DKIM1; k=rsa; p=MIGf..."
• Namecheap: Use their "TXT Record" type without manual escaping. The panel handles it.
• cPanel/WHM: Use the "DKIM" record type specifically, not a generic TXT record.

Detecting Escaping Issues

Use dig to examine the raw record:

dig TXT selector._domainkey.example.com +short

If you see backslashes before semicolons (v=DKIM1\; k=rsa\;), your panel added escaping. If you see no semicolons at all (record truncation), your panel removed them incorrectly.

Our DKIM Checker parses your DNS record and warns if escaping appears incorrect, showing you exactly what string the receiving server will see.

Canonicalization Issues: Simple vs. Relaxed Headers/Body

Canonicalization is the process of standardizing email formatting before hashing to tolerate minor, insignificant differences. DKIM defines two canonicalization algorithms for both headers and body:

Simple Canonicalization (c=simple/simple)

• Headers: No changes allowed. Header names and values must be exactly as originally signed, including whitespace and line wrapping.
• Body: The entire body is used exactly as sent, including all line endings and trailing whitespace.
• Result: Extremely fragile. Any modification by intermediate servers breaks the signature.

Relaxed Canonicalization (c=relaxed/relaxed) [Recommended]

• Headers: Header names are converted to lowercase, extra whitespace is collapsed, and line wrapping is normalized.
• Body: Trailing whitespace is stripped from each line, and the final line ending is normalized.
• Result: Tolerant of minor modifications while still detecting significant changes.

The Problem: Mismatched Canonicalization

If your signing server uses simple canonicalization but the receiving server's verification expects relaxed (based on the c= tag), verification may still pass because the c= tag tells the receiver which algorithm to use. The real problem occurs when intermediate servers modify the email in ways that simple can't tolerate but relaxed could.

Example: An antivirus gateway adds a warning banner to the bottom of your email. With c=relaxed/relaxed, the body hash changes and verification fails (this is correct—content changed). With c=simple/simple, even minor whitespace changes that relaxed would ignore will cause failure.

Recommendation

Always use c=relaxed/relaxed for both signing and verification. This is the modern standard and is supported by all major email providers. Only use simple if you have legacy systems that require it or if you're in a highly controlled environment where no email modification occurs.

To check your current canonicalization setting, examine your DKIM-Signature header:

DKIM-Signature: ... c=relaxed/relaxed; ...

If you see c=simple/simple and experience frequent verification failures, reconfigure your mail server to use relaxed canonicalization.

The Expired Signature Trap: t= and x= Tags

DKIM signatures can include timestamps that limit their validity period. These tags add security but can cause unexpected failures if misconfigured.

Understanding t= and x= Tags

• t= (timestamp): The time the signature was created, expressed as seconds since Unix epoch (January 1, 1970).
• x= (expiration): The time after which the signature should be considered invalid, also in Unix epoch seconds.

If an x= tag is present and the current time exceeds x=, verification fails with signature expired.

Common Expiration Problems

• Too-short expiration windows: If you set x= to t= + 1 hour, any email delayed in a queue for more than an hour will fail verification. Email can easily be delayed for several hours due to greylisting or server outages.
• Server clock skew: If your mail server's clock is off by even a few minutes relative to the receiving server, signatures created with t= in the future (or past) may cause failures.
• Time zone confusion: Unix epoch is UTC, but if your mail server's time zone is misconfigured, t= values may be incorrect.

Best Practices for DKIM Expiration

• Omit x= entirely for most emails: DKIM signatures don't require expiration. The added security of expiration rarely outweighs the risk of delivery failures.
• If you must use expiration, set x= to at least 7 days: This accounts for email queuing, forwarding delays, and time zone differences.
• Synchronize your mail server's clock with NTP: Ensure your server uses accurate, synchronized time. NTP (Network Time Protocol) is standard.
• Test with both current and future times: Send test emails and check the Authentication-Results header for expiration failures.

To see if expiration is causing your failures, look for body hash mismatch vs signature expired in DMARC reports. Our DKIM Checker parses the t= and x= tags and warns if expiration is set too aggressively.

A Step-by-Step Diagnostic Checklist for System Admins

When DKIM verification fails, work through this systematic checklist to identify and fix the issue:

Phase 1: DNS and Record Validation

1. Verify the record exists: Run dig TXT [selector]._domainkey.yourdomain.com. If you get NXDOMAIN, your DNS record is missing or misnamed.
2. Check record format: Ensure the record contains v=DKIM1 and a valid p= tag with a base64 key.
3. Validate key length: Use our DKIM Checker to confirm the key length (2048 bits recommended) and format.
4. Check for splitting/escaping issues: Look for extra quotes, backslashes, or line breaks in the dig output.
5. Test from multiple resolvers: Check dig @8.8.8.8 (Google) and dig @1.1.1.1 (Cloudflare) to rule out resolver-specific caching issues.

Phase 2: Header and Signature Analysis

1. Examine raw email headers: Find the DKIM-Signature header and note the s= (selector), d= (domain), bh= (body hash), and b= (signature) values.
2. Confirm selector matches: Ensure the s= value exactly matches the DNS record name you created (case-sensitive).
3. Check canonicalization: Verify c= is set to relaxed/relaxed (recommended) or understand the implications of other settings.
4. Look for expiration: If x= tag exists, calculate if the current time exceeds it.
5. Read Authentication-Results header: This header (added by receiving servers) often contains detailed failure reasons like body hash mismatch or signature verification failed.

Phase 3: Infrastructure and Environment

1. Check for email forwarding: If the failing email was forwarded, the original DKIM signature likely broke. Look for ARC headers that might preserve authentication.
2. Identify body modifications: Compare the original sent email with what the recipient received. Look for added footers, banners, or altered content.
3. Review mail server logs: Your outbound mail server logs show whether signing is being applied to all emails and whether any signing errors occurred.
4. Test with multiple recipients: Send to Gmail, Outlook, Yahoo, and a private server. If failures are isolated to one receiver, the problem may be with that receiver's configuration.

Phase 4: Provider-Specific Checks

1. For ESPs like Google Workspace or Microsoft 365: Check their admin dashboards for DKIM status and any reported errors.
2. For third-party senders (Mailchimp, SendGrid, etc.): Verify that custom domain signing is enabled and the CNAME records are still valid.
3. For self-managed servers (Postfix, Exchange): Check that the private key file is readable by the mail server process and that the selector in the config matches DNS.

Automated Testing with Our DKIM Checker

Instead of manually running through this checklist, use our DKIM Checker to automate most of the diagnostic process. The tool:

• Performs complete DNS validation, checking for correct record format, key length, and split/escaping issues
• Accepts an email file or raw headers to parse and validate the signature
• Provides specific, actionable error messages (e.g., "Body hash mismatch: email was modified after signing")
• Shows the exact DNS query it performs, making selector typos obvious
• Generates a pass/fail report with step-by-step recommendations for fixing failures

Final troubleshooting tip: When all else fails, temporarily set your DMARC policy to p=none (monitor mode) to avoid rejecting legitimate email while you debug. Review DMARC aggregate reports to see which emails are failing DKIM and identify patterns. Once failures are resolved, restore your enforcement policy (p=quarantine or p=reject).