12-11-2025 05:38 AM
Hi all,
got a problem with DKIM-Signature-Validation in our ESA (Cisco C695 with AsyncOS 15.5.3 build 024).
Signature validation fails, if domain in DKIM-Header's d-tag is uppercase. For example, an email with these Headers
From: XXXXXX@GMX.DE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GMX.DE;
s=s31663417; t=1765447896; x=1766052696; i=XXXXXX@gmx.de;
bh=3WkY40n5W/suCgsM+RiHzyMZm85PRGarESNZU1ADwm4=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:From:Subject:To:
Content-Type:Content-Transfer-Encoding:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=hZhfnBcOm....
leads to
Authentication-Results: esa.example.net; dkim=permerror (domain mismatch) header.i=none; spf=Pass smtp.mailfrom=XXXXX@gmx.de; dmarc=pass (p=quarantine dis=none) d=gmx.de
The same mail sent with lowercase domain in From and d-tag was successfully dkim validated:
From: XXXXX@gmx.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
s=s31663417; t=1765447864; x=1766052664; i=XXXXX@gmx.de;
bh=3WkY40n5W/suCgsM+RiHzyMZm85PRGarESNZU1ADwm4=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:From:Subject:To:
Content-Type:Content-Transfer-Encoding:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=l6Ir7eQEZ...
-> Authentication-Results: esa.example.net; spf=Pass smtp.mailfrom=XXXXX@gmx.de; dkim=pass (signature verified) header.i=XXXXX@gmx.de; dmarc=pass (p=quarantine dis=none) d=gmx.de
Rspamd and Thunderbird DKIM-Plugin are validating the dkim signature in both cases as correct.
I guess the problem maybe comes from different cases of the domain in the i-tag and in the d-tag ("d=GMX.DE" vs. "i=XXXXXX@gmx.de").
Kind regards,
Harald
Solved! Go to Solution.
12-12-2025 02:37 AM - edited 12-12-2025 05:36 AM
Hi,
Unfortunately, you're spot on with the root cause, and there's currently no way to fix it. When Cisco implemented DKIM, it took the RFC as a bible, and implemented the feature accordingly to the RFC which states that "Tags must be interpreted in a case-sensitive manner", see https://datatracker.ietf.org/doc/html/rfc6376; outcome, is that, in scenarios as the one you're presented, even though DKIM is a pass, because there's a case mismatch between "i" and "d" tags, the final resolution is permerror / permfail. My perspective, Cisco has done a great job, as MUST in the RFC is a MUST, no interpretations and/or deviations should take place; however, as you see, it sometimes brings challenges to real life situations.
There's an enhancement request for this specific use-case, see https://bst.cisco.com/quickview/bug/CSCwr87318 ; don't confuse the relaxed / strict naming convention from this request to the other relaxed / strict functionality within DKIM that has a different scope, see here (https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/213946-dmarc-architecture-identifier-alignmen.html), and you have it configured as relaxed.
One WA would be to configure a DKIM exception for such domains, until, at some point, the enhancement request will make it to production.
Thanks,
Cristian.
12-12-2025 02:37 AM - edited 12-12-2025 05:36 AM
Hi,
Unfortunately, you're spot on with the root cause, and there's currently no way to fix it. When Cisco implemented DKIM, it took the RFC as a bible, and implemented the feature accordingly to the RFC which states that "Tags must be interpreted in a case-sensitive manner", see https://datatracker.ietf.org/doc/html/rfc6376; outcome, is that, in scenarios as the one you're presented, even though DKIM is a pass, because there's a case mismatch between "i" and "d" tags, the final resolution is permerror / permfail. My perspective, Cisco has done a great job, as MUST in the RFC is a MUST, no interpretations and/or deviations should take place; however, as you see, it sometimes brings challenges to real life situations.
There's an enhancement request for this specific use-case, see https://bst.cisco.com/quickview/bug/CSCwr87318 ; don't confuse the relaxed / strict naming convention from this request to the other relaxed / strict functionality within DKIM that has a different scope, see here (https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/213946-dmarc-architecture-identifier-alignmen.html), and you have it configured as relaxed.
One WA would be to configure a DKIM exception for such domains, until, at some point, the enhancement request will make it to production.
Thanks,
Cristian.
12-12-2025 04:49 AM
Hi Cristian,
thanks for the information. So Cisco does it right and GMX wrong..
Kind regards,
Harald
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide