No, the DKIM domain name is not case-sensitive. If a tester fails only because d= uses one case and the domain part of i= uses another case, I treat that as a tester bug unless real mailbox providers also show DKIM failure. DNS names are case-insensitive, and DKIM selectors and signing domains are DNS names.
The caveat is that DKIM signing itself is byte-sensitive. The signature is calculated over selected headers and the message body after DKIM canonicalization. Domain case should not break the lookup or the domain comparison, but a changed subject line, rewritten body, altered MIME boundary, or broken public key can break the cryptographic check.
- Direct answer: DKIM domain case should not cause failure by itself.
- Likely bug: A tester that compares d= and i= domains as raw text can report a false failure.
- First proof: Send the same message to a real mailbox, then inspect Authentication-Results before changing DNS.
- Real fixes: Focus on body changes, header rewriting, selector mistakes, DNS syntax, and key rotation.
What DKIM treats as case-sensitive
DKIM has more than one kind of comparison, so the answer depends on which part of the check failed. RFC 6376 defines the DKIM signature header, DNS key lookup, header hash, and body hash. DNS domain labels use case-insensitive matching. Hash input is much stricter because DKIM verifies the exact canonicalized content.
|
|
|
|---|---|---|
d= | Ignore case | Signing domain |
s= | Ignore case | Selector lookup |
i= | Mixed | Domain part |
bh= | Exact | Body hash |
b= | Exact | Header hash |
h= | Name rules | Signed fields |
DKIM case handling by component
The confusing part is i=. It is the signing identity. It can include a local part before the at sign, and that local part has its own rules. The domain part after the at sign is still a domain name, so case should not make it fail against d=. A tester that says otherwise is checking the wrong thing.
Do not fix DNS before proving the failure
A red DKIM line from one tester is evidence, not proof. I look for the same failure in real recipient headers before rotating keys, changing selectors, or publishing a new TXT record.
- Check headers: Real delivery headers show what the receiver actually accepted or rejected.
- Check DNS: Confirm the selector record resolves and contains one valid public key.
- Check timing: DNS cache and key rotation can make one tester stale while receivers pass.
- Check content: Body or header changes after signing cause real cryptographic failure.
Why a tester can fail when mail passes
A DKIM tester sits outside the normal receiving path. That makes it useful, but it also means the tester has to reconstruct what a receiver does: parse raw MIME, find the right signature, fetch DNS, apply canonicalization, compare domains, and decide whether warnings deserve a failed status. A small parsing mistake can produce a scary result that real mailbox providers ignore.
Tester-only problem
- Case bug: The tester compares domain strings without normalizing case.
- Sample issue: The uploaded message differs from the delivered raw message.
- DNS cache: The tester still sees an old key after a selector change.
- Severity choice: The tester labels a warning 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, missing, split badly, or expired.
- Wrong selector: The message points to a selector that does not exist in DNS.
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 message, I do not rewrite DNS just to satisfy a single tester. I save the raw headers, compare the tester result, and look for the smallest difference that explains the mismatch.
Common causes of DKIM tester errors
Most DKIM tester errors fit a short list. The fastest path is to classify the error before changing anything. A domain-case warning belongs in the "tester behavior" bucket. A body hash mismatch or missing key belongs in the real fix bucket.
|
|
|
|---|---|---|
Domain case | Tester bug | Verify headers |
No key | Wrong selector | Fix DNS name |
Bad RSA | Malformed key | Republish key |
bh fail | Body changed | Sign later |
b fail | Header changed | Protect headers |
Expired | Old signature | Check clock |
DKIM tester error causes and practical checks
Public key errors deserve special attention because one stray quote, missing semicolon, or broken TXT split can break every message using that selector. If the tester says the key itself is invalid, compare the DNS value against the expected vendor record and use this invalid RSA public key checklist before rotating the selector.
Case mismatch that should not fail by itselftext
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. That should not invalidate DKIM. If the body or one of the signed headers changes after the signature is created, the same message can fail for a real reason.
How I validate a suspicious DKIM error
I use a simple 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.
- Read headers: Inspect Authentication-Results at the final mailbox, not a forwarded copy.
- Check selector: Build the DNS name from s= plus d= and confirm the TXT record.
- Compare domains: Treat case differences as harmless when the domain text otherwise matches.
- Inspect changes: Look for footer injection, subject edits, MIME changes, and security gateway rewriting.
- Watch reports: Use aggregate DMARC data to see whether the failure repeats across receivers.
When the only symptom is a one-off tester warning and recipient headers pass, I document it and move on. When the same source starts failing at multiple receivers, I switch to a full troubleshooting workflow that checks DNS, signing order, MIME processing, and sender configuration.
A flowchart for checking a DKIM tester error against real recipient headers and DNS.
For a quick selector and public key check, the DKIM checker is useful when I need to confirm the DNS record before digging into raw message content.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A DNS-only check cannot prove the message body was preserved, but it quickly removes malformed selectors, missing TXT records, and broken public keys from the list of suspects.
Where Suped fits after the local check
A one-off DKIM tester is good for a narrow question. Ongoing authentication work needs trend data, source attribution, and alerts when the same failure starts affecting real mail. That is where Suped's product fits: it brings DMARC, SPF, DKIM, blocklist (blacklist) checks, and deliverability signals into one workflow.
For most teams, Suped is the best overall practical DMARC platform because it turns reports into concrete fixes. The useful part is not another red or green label. It is knowing which sending source is failing, whether the failure affects domain matching for DMARC, and what to change next.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
- Issue detection: Suped groups authentication failures by source and gives steps to fix them.
- Real-time alerts: Teams get notified when DKIM, SPF, or DMARC pass rates drop.
- Hosted records: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce DNS churn.
- Multi-domain work: MSPs and agencies can manage many domains without separate spreadsheets.
- Reputation checks: Blocklist and blacklist monitoring helps connect authentication and delivery signals.
If I am checking a single domain's overall state, I use a domain health check first, then move into DMARC monitoring when I need source-level evidence over time.
What not to change for a case-only warning
A case-only warning is tempting because it looks easy to fix. I still avoid changing production authentication until the failure appears in real recipient headers or aggregate reports. DKIM changes are small, but a wrong selector, stale key, or DNS typo can break legitimate mail.
Typical DKIM TXT record shapetext
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
Do not publish a duplicate selector just to make a tester happy. Do not rotate keys because d= is lowercase and i= contains uppercase domain labels. Do not change the visible From domain case for delivery reasons. Those edits distract from the real question: did the receiving system validate 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 source: Send a fresh message after any vendor or gateway setting change.
Views from the trenches
Best practices
Confirm real recipient headers before editing DKIM DNS for a case-only warning first.
Compare the signing domain and identity domain after lowering case in your notes.
Keep one raw message sample for each sender path before testing any DNS change later.
Common pitfalls
Treating one tester warning as proof can cause unnecessary selector rotation and risk.
Changing DNS case does not fix body hash or header hash failures in real mail paths.
Forwarded or copied messages can hide the original receiver authentication result.
Expert tips
Use aggregate DMARC data to see if a DKIM issue affects one test or many receivers.
Check whether gateways add footers after signing before blaming the DNS record first.
Separate DNS validation from message validation so fixes target the right layer.
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 from Email Geeks says the Authentication-Results header from a real delivered message is the best proof.
2024-04-12 - Email Geeks
The practical answer
DKIM signing is strict, but DKIM domain case is not the strict part. A tester that fails only because the d= domain and the i= domain use different case is giving you a false lead. Confirm with a real delivered message, then fix only the layer that fails: DNS key, selector, signer, body preservation, header preservation, or DMARC domain matching.
For ongoing protection, use tester output as one signal and DMARC reporting as the operating system. That combination catches real DKIM failures without letting a single buggy case comparison drive production DNS changes.
