Re: Seemingly eligible mails not getting DKIM signed

On Mon, 8 Jun 2026 10:59:05 +0100 Jeremy Harris via Exim-users wrote:

> On 2026/06/08 5:20 AM, Christian Balzer via Exim-users wrote:
> > 2. Mails that don't get signed despite having a valid dkim_domain set.
> >     Looking at the mail data there seems to be nothing amiss and rspamd
> >     also reports that envelope and header From are identical and has
> >     nothing bad to say about header fields.
> >     I have "dkim_strict = 0"  
> 
> > Any ideas what could cause this, i.e. some header encoding (this is Japan
> > after all) that Exim is silently failing on and decides not to sign?  
> 
> The primary controls on a message getting signed are the expansion results
> for the dkim_domain, dkim_selector and dkim_private_key options on the
> transport being used.
> 
Indeed, and they are all set in case 2.
As said based on observations (local mails from our MSAs to our MXs,
bounces, remote samples) nearly all are supposed to get signed will indeed
get signed.

> You say that a valid dkim_domain is set; how do you know this (and does
> it possibly vary by mesaage)?
> 
I placed a warn to capture this:
---
acl_check_data:

  # What is it that we are supposed to sign?
  warn  log_message = DKIM is set to: DKIM_DOMAIN
---
Which correctly returns the header From: mail domain in all cases that get
correctly signed (and the handful that do not).

It is empty with case 1 where the header From: is malformed
(mis-configured client) which as said is fine (other peoples problem).

I went through the last few days of cases (all conditions to sign present
but not signed) and my suspicion that a malformed header is to blame seems
to be confirmed.

All mails in question were created by "X-Mailer: Microsoft Outlook 16.0".

All of them had long (1000+ characters) and broken (split in the
middle of an id) References: like this:
---
<unbroken> <delugeofids> <[email protected]
	om> 
---

Which is a known issue with this (EOL) mail client.

Since there was not a single other commonality I'm assuming that this
stops the DKIM signing from happening.

It would be nice to throw errors/warnings instead of silently failing
here, but at least now I have an idea on how to engage debug in more
selective ways.

Since signing References: is recommended (SHOULD, but not MUST) by the RFC
in question, I wonder which fallout would NOT signing References: at all
would cause, opposed to tell these people to change mail clients...

Thanks a LOT for these tips below, I will definitely look into these going
forward of the above turned out to be not covering all cases.

> > Any means of getting more info without running production servers in debug
> > mode?  
> 
> Debug *is* the "more info'. To sidestep the volume problem of running it
> unfettered in a production environment,
> 
> a) enable fewer debug channels than "all"
> b) use speculatative debug recording (cf. the "kill" option on an
>     ACL control=debug)
> c) use triggered debug recording (just an ACl control=debug, once an
>     "interesting" situation has been detected)
> 
> Note that custom ACLs can be called from within a string-expansion,
> and that all three of those options above are expanded (as are many
> others). Treat your expansions and ACLs as programming languages.
> 
> > the handful of user/accounts/addresses where this happens  
> 
> Just restricting debug to those accounts would be a good start
> on the debug output volume problem, I'd think.  A suitably coded
> detection of them in the mail-from ACL, and trigger debug there?
> 

Thanks again,

Christian
> -- 
> Cheers,
>    Jeremy
> 
> PS: If anyone wants an example of expansion-calls-ACL to use as
> a starter for their own customisation, just ask.
> 
> PPS: If anyone feels this is a common-enough issue to warrant specific
> facilities, please open an Issue on code.exim.org requesting such.
> Mention the Exim "events" mechanism.
> 
> -- 
> ## subscription configuration (requires account):
> ##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
> ## unsubscribe (doesn't require an account):
> ##   [email protected]
> ## Exim details at https://www.exim.org/
> ## Please use the Wiki with this list - https://code.exim.org/exim/wiki/wiki
> 


-- 
Christian Balzer        Network/Systems Engineer & Architect               
[email protected]   	Rakuten Mobile Inc.

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   [email protected]
## Exim details at https://www.exim.org/
## Please use the Wiki with this list - https://code.exim.org/exim/wiki/wiki