[dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF Dependency Removal)

[Matthäus Wander <[e-mail]>]

Barry Leiba wrote on 2023-06-10 01:50:
> That's interesting and disturbing if it remains consistent.
> Theoretically, DKIM should *never* fail when SPF succeeds, so if
> that's happening it means there is:
> 1. bad signing software,
> 2. bad verifying software,
> 3. misconfiguration somewhere,
> ...or a combination of those three.
> 
> I would *really* like to see a current study of this, because I think
> it's critical for the future viability of DMARC, whether or not we
> accept the proposal to remove SPF.
Not a study, but some data points I've observed:

a) Signing with 3072-bit RSA leads to DKIM verification failures, 
because a popular mail gateway product (Cisco ESA) does not support RSA 
key lengths larger than 2048 bit.

b) Messages are generated by an automated system without a Date header 
and signed by a central MTA. An outgoing mail gateway then adds the 
missing Date header (Postfix option 'always_add_missing_headers'), thus 
invalidating the DKIM signature.

Such misconfigurations go unnoticed for years until someone checks the 
DMARC reports. While aggregate reports are incredibly helpful, it is 
still difficult to identify the cause of subtle DKIM failures. I'd wish 
that the <human_result> field would be filled by reporting software with 
the DKIM verification error message ('body hash did not verify', etc.) 
to aid with troubleshooting.

Contacting the report <email> or postmaster address has never worked for 
me: if they don't bounce, nobody replies.

c) There is a pattern of similar looking reports, which omit the <dkim> 
element in the <auth_results> altogether and always report 
<dkim>fail</dkim> in the policy result. I suspect a product, which makes 
it a bit too easy to enable DMARC validation without also enabling DKIM 
verification, but I wasn't able to identify the product yet.

Regards,
Matt