Is DKIM signature case-sensitive and what causes DKIM tester errors?
Updated on 6 Oct 2026: We clarified DKIM case sensitivity and added checks for canonicalization, DNS caching, and key errors.
DKIM domain names are case-insensitive, but the signature's base64 data and signed content are case-sensitive. If a tester fails only because d= uses one case and the domain part of i= uses another, check for a tester comparison bug. The signing domain and selector form a DNS query, and DNS labels are case-insensitive. Changing those values after signing is a separate cause of failure.
The caveat is that DKIM verification is byte-sensitive after canonicalization. The DKIM-Signature header, including its tag values except the contents of b=, contributes to the signed input. Changing the case of a tag value after signing can therefore break the signature, even when the original domain value would have worked in DNS. A changed subject line, rewritten body, altered MIME boundary, or mismatched public key can also break the cryptographic check.
- Direct answer: DKIM domain case should not cause failure by itself.
- Likely bug: A tester that compares the d= and i= domains as raw, case-sensitive text can report a false failure.
- Send a fresh message to a real mailbox, then inspect its trusted Authentication-Results and compare the same DKIM signature before changing DNS.
- Real fixes: Focus on content changes, selector mistakes, DNS syntax, signing configuration, and key rotation.
What DKIM treats as case-sensitive
DKIM has several kinds of comparison, so the answer depends on which part of the check failed. RFC 6376 says tag names are case-sensitive and values are case-sensitive unless a tag's semantics say otherwise. DNS names use case-insensitive matching, and header field names listed in h= are also matched without case sensitivity. The canonicalized header and body content remains strict cryptographic input.
|
|
|
|---|---|---|
d= | Domain comparisons ignore case | Signing domain and DNS query |
s= | DNS lookup ignores case | Selector label and signed value |
i= | Domain comparison ignores case | Domain relationship and local part |
bh= | Base64 letters are case-sensitive | Canonicalized body hash |
b= | Base64 letters are case-sensitive | Signature data |
h= | Header names ignore case | Selected header instances |
Tag names | Case-sensitive | Use d=, s=, and v=, not D=, S=, or V= |
DKIM case handling by component
The confusing part is i=, the Agent or User Identifier. Its domain must be the same as, or a subdomain of, d=. If the public key record has t=s, the domains must match exactly apart from case, so an i= subdomain is not allowed. DKIM leaves the meaning of the optional local part to the signer, so a tester should not impose mailbox-specific case rules on it.
Do not fix DNS before proving the failure
A red DKIM line from one tester is evidence, not proof. Look for the same failure in real recipient headers before rotating keys, changing selectors, or publishing a new TXT record.
- Read the final receiver's trusted authentication result; delivery alone does not establish a DKIM pass.
- Check DNS: Confirm the selector name resolves to one valid DKIM key record.
- Check timing: DNS caching during key rotation can leave a tester and receiver with different answers.
- Changes to the canonicalized body or signed headers after signing cause a real cryptographic failure.
How canonicalization affects case and whitespace
The c= tag selects header/body canonicalization. relaxed/relaxed tolerates some formatting changes; omitted c= defaults to simple/simple. Neither lowercases header values or body text. These rules are defined in RFC 6376.
|
|
|
|---|---|---|
Header name case | Breaks verification | Tolerated |
Signed Subject value case | Breaks verification | Breaks verification |
Body text case | Breaks verification | Breaks verification |
Repeated spaces or tabs within a body line | Breaks verification | Reduced to one space |
Empty lines at the body end | Ignored | Ignored |
Changes after signing, assuming the affected content is signed
Relaxed header processing unfolds lines and normalizes whitespace. Relaxed body processing removes trailing spaces or tabs, but preserves line breaks. A footer or MIME re-encoding can still change signed bytes. Test the original raw .eml file; copying rendered text or saving with different line endings can create a body hash mismatch.
Why a tester can fail when mail passes
A DKIM tester sits outside the normal receiving path. The tester must parse raw MIME, find each signature, fetch DNS, apply canonicalization, compare domains, and decide whether a warning deserves a failed status. A parsing or policy difference can produce a result that real mailbox providers do not reproduce.
Tester-only problem
- Case bug: The tester compares domain strings without normalizing case.
- Sample issue: The uploaded message differs from the delivered raw message.
- The tester still sees an old key after key rotation, or a cached missing-record response for a new selector.
- Severity choice: The tester labels a warning or policy result as a hard failure.
Receiver failure
- Body change: A footer, tracker, or gateway changes signed body content.
- Header change: A signed header changes after DKIM signing.
- Bad key: The public key is malformed, revoked, missing, or different from the active private key.
- Wrong selector: The message points to a selector that does not exist in DNS.
Forwarding by itself does not break DKIM. The signature can survive when the forwarded message stays unchanged. Mailing lists, gateways, and forwarding systems break it when they add footers, rewrite MIME content, or modify a signed header after the original signer applies DKIM.
Gmail message details showing DKIM pass despite different case in DKIM domain fields.
If Gmail, Outlook, Yahoo, or another major recipient shows DKIM pass for the same signature, do not rewrite DNS just to satisfy one tester. Match the signing domain and selector, and compare the delivered raw message with the tester's input. A receiver result records verification at receipt; a tester run later can encounter a changed DNS key or message export.
Common causes of DKIM tester errors
Most DKIM tester errors fit a short list. Classify the result before changing anything. A domain-only case warning suggests a tester comparison bug. A body hash mismatch, key lookup failure, or bad signature needs investigation of the raw message and DNS response.
|
|
|
|---|---|---|
Domain-only case mismatch | Suspected tester comparison bug | Compare receiver headers |
No key for signature | Wrong selector or missing record | Query <selector>._domainkey.<signing-domain> |
Key syntax error | Malformed or duplicate key record | Republish one valid record |
Body hash did not verify | Body changed after signing | Stop rewriting or sign later |
Bad signature | Signed header changed or key mismatch | Compare signer and delivery hops |
Signature expired | x= time passed or clock error | Check timestamp and system clock |
Temporary key lookup error | DNS timeout or SERVFAIL | Retry and compare resolver responses |
Unsupported or weak algorithm/key | Obsolete signing settings or verifier policy | Check a=, k=, and RSA key size |
DKIM tester error causes and practical checks
Public key errors deserve special attention because an invalid tag, missing semicolon, truncated TXT record, or duplicate key record can affect every message using that selector. DKIM public keys do not contain an expiry time. They stop working when the record is removed, revoked with an empty p=, malformed, or no longer matches the private key. Use this invalid RSA public key checklist before rotating the selector.
For RSA signatures, RFC 8301 prohibits rsa-sha1 and keys shorter than 1024 bits, and recommends at least 2048 bits. Use rsa-sha256 with a matching public/private key pair. A receiver's stricter key policy is separate from a domain-case comparison bug.
Illustrative signature with different domain casetext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eml.example.com; s=selector1; i=@EML.example.com; h=from:to:subject:date:mime-version; bh=base64-body-hash-value; b=base64-signature-value
In that example, the domain in d= and the domain part of i= differ only by case as the signer wrote them. That relationship should not invalidate DKIM. The bh= and b= values here are placeholders, so this snippet is not a verifiable signature. If an intermediary changes either domain value in the signed header, the body, or one of the signed message headers afterward, the message can fail for a real cryptographic reason.
DKIM verification and DMARC alignment are separate
A DKIM pass proves that a receiver verified a signature for the domain in d=. DMARC asks a separate question: does that signing domain have the required relationship with the visible From domain? A third-party domain can pass DKIM but fail to provide DKIM alignment for DMARC. An SPF pass with alignment can still let DMARC pass when DKIM fails.
Relaxed DKIM alignment requires the same organizational domain; strict alignment requires the same domain. For example, a signature with d=example.com and a visible From address at news.example.com passes relaxed alignment but fails strict alignment. Domain case is ignored in both modes. DMARC passes when at least one supported authentication path passes with the required domain relationship.
|
|
|
|---|---|---|
dkim=pass | An acceptable signature verified | Check DMARC alignment separately |
dkim=fail | The signature did not verify | Inspect the reason and message path |
dkim=none | No DKIM signature was present | Confirm signing and whether a gateway removed it |
dkim=temperror | A temporary problem blocked verification | Retry and check DNS availability |
dkim=permerror | An unrecoverable syntax or input error occurred | Correct the signature or key record |
How to interpret common DKIM results
One message can carry multiple DKIM signatures, and receivers evaluate them independently. A failed signature beside a passing signature with DMARC alignment does not mean the message has no valid DKIM result. Read every DKIM entry in Authentication-Results, then identify which header.d value has the required relationship with the visible From domain.
How to validate a suspicious DKIM error
Use a fixed order of operations. It keeps the investigation anchored in the actual recipient result and stops cosmetic changes from creating a new outage.
- Send real mail: Send a fresh message through the same production route that produced the warning.
- Inspect the Authentication-Results field added by the final mailbox's trusted authentication service. A sender or untrusted intermediary can insert a misleading result.
- Use s= and d= from the actual message to query <selector>._domainkey.<signing-domain>. Follow any CNAME to the final TXT key; a CNAME alone does not validate the signature.
- Ignore domain case for comparison, but preserve the raw signed values. Check the i=/d= relationship separately from DMARC alignment with the From domain.
- Export the complete raw message, including its MIME body. Look for footer injection, subject edits, MIME re-encoding, line-ending conversion, and gateway rewriting.
- Watch reports: Use Suped's DMARC reporting to see whether the source repeats the failure across receivers.
When the only symptom is a one-off tester warning and the same signature passes at the recipient, document it and monitor for repeats. When the same source fails at several receivers, use the full troubleshooting workflow that checks DNS, signing order, MIME processing, and sender configuration.
Query the selector used by the messagebash
dig TXT selector1._domainkey.example.com dig CNAME selector1._domainkey.example.com
Replace the example domain and selector with the message's actual values. Compare authoritative DNS answers with recursive resolver answers and their TTLs. DNS caching, including negative caching, controls how long old answers persist; there is no universal 48-hour wait. During rotation, publish the new selector before using it and keep the previous key available while already-signed mail is still in transit.
For intermittent dkim=temperror, compare deliveries to different receivers and check DNS availability. For a body hash mismatch, compare direct delivery with the route through a gateway. These checks are described in Amazon's DKIM troubleshooting article.
DKIM troubleshooting flowchart: send real mail, read recipient headers, check DNS, and inspect signed content.
For a quick selector and public key check, Suped's DKIM checker confirms the DNS record before a deeper review of raw message content.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A DNS-only check cannot prove that the message body was preserved, but it quickly removes malformed selectors, missing TXT records, and broken public keys from the list of suspects.
Use Suped to monitor repeated DKIM failures
A one-off DKIM tester answers a narrow question. Suped's DMARC reporting product adds source-level results over time, helping teams compare repeated DKIM failures across reporting receivers.
Suped turns aggregate reports into source-level evidence and suggested fixes. Teams can identify which sending source is failing, whether its DKIM domain has DMARC alignment, and whether the issue persists across receivers before changing production DNS.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
- Review the sending source and signing domain to locate recurring DKIM failures.
- Compare reporting receivers and report periods to distinguish an isolated warning from a repeated problem.
- Use Suped's authentication alerts to investigate new failures after sender changes or key rotation.
- Keep raw message samples alongside report data when investigating the exact failure reason.
Aggregate reports arrive after receivers generate them; they do not validate each message in real time. They show authentication outcomes, but usually do not identify the byte change behind a body hash mismatch. Use raw message samples for that diagnosis.
For one domain, Suped's domain health check gives a current configuration check. Suped's DMARC monitoring adds source-level evidence over time.
What not to change for a case-only warning
A case-only warning looks easy to fix. Confirm the raw message and the same signature's receiver result before changing production authentication. A wrong selector, stale key, or DNS typo can break legitimate mail.
Illustrative DKIM TXT record with an abbreviated keytext
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
The p= value above is abbreviated, so publish the sender's complete public key. Long keys can use adjacent quoted strings within one TXT record, joined without extra characters. This is different from publishing multiple TXT records at the same selector, which gives undefined DKIM results.
Do not publish a duplicate selector just to make a tester pass. Do not rotate keys because d= is lowercase and i= contains uppercase domain labels. Changing the visible From domain's letter case is not a fix for DKIM. The deciding question is whether the receiving system validated the signature.
Safe response to a false DKIM warning
- Preserve evidence: Save the raw tester output and the passing recipient header.
- Monitor repeats: Watch for the same source failing across more than one receiver.
- Fix only facts: Change DNS only when the selector, key, or policy is actually wrong.
- Retest the source: Send a fresh message after any sender or gateway setting change.
Views from the trenches
Best practices
Confirm real recipient headers before editing DKIM DNS for a case-only warning in production.
Compare signing and identity domains after normalizing domain case in your notes.
Keep one raw message sample for each sender path before testing a production DNS change.
Common pitfalls
Treating one tester warning as proof can trigger unnecessary selector rotation risks.
Changing DNS case does not fix body hash or signed-header failures in real mail.
Forwarded or copied messages can hide the original receiver's authentication result.
Expert tips
Use aggregate DMARC data to learn whether one source fails across receivers in practice.
Check whether gateways add footers after signing before changing the DNS record.
Separate DNS validation from message validation so the fix targets the right layer.
Marketer view
Marketer from Email Geeks says DNS case should not make DKIM fail, but a tester can still have a parsing bug.
2024-04-12 - Email Geeks
Marketer view
Marketer from Email Geeks says the Authentication-Results header from a real delivered message is the best proof.
2024-04-12 - Email Geeks
Frequently asked questions
Yes, some parts are case-sensitive. Tag names and base64 data are case-sensitive, while DNS domain comparisons and header-name matching ignore case. Relaxed canonicalization lowercases header names, but preserves header value and body text case. Changing a signed tag value after signing can invalidate the signature.
Yes. If the domains match except for case, that difference should not break DKIM. The optional local part of i= has signer-defined identity semantics, which is separate from DNS domain case.
Check that both results refer to the same signature and raw message. The tester can encounter different DNS cache data, a changed message export, or a parsing bug. The final recipient's trusted Authentication-Results header records the receiver's result for that delivery.
Yes. DKIM can verify for the domain in d= while that domain lacks the required relationship with the visible From domain. DMARC fails if there is neither a passing DKIM signature with that relationship nor a passing SPF result with the required relationship.
No. Changing DNS label case is cosmetic. Fix the selector, public key, signing order, or message rewriting only when a real receiver result proves a failure.
Suped's DMARC reporting product groups receiver-reported authentication results by sending source and helps teams investigate recurring failures. Reports support monitoring over time; raw message samples are still needed to diagnose a specific body hash or signed-header mismatch.
