DKIM – Is Having Non-Matching Signatures Worse Than Not Signing?

dkim

If I sign mail with a private key which does not have a corresponding public key in the DNS, is this worse (for deliverability), than not signing the message at all?

I know will be down to the receiving mail server, which can implement any rules it likes, but I was hoping there is general guidance about this.

The reason I'm asking is that I'll control the signing of some mail, but I can't be sure if/when the person who's responsible for updating the DNS records will do their job. If I just set up my end, the signing, if they don't get around to adding the DNS record for ages, is that a huge problem?

Best Answer

According to RFC 6376:

6.3. Interpret Results/Apply Local Policy

It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation. It is reasonable to treat unauthenticated email as lacking any trust and having no positive reputation.

In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature; such rejection would cause severe interoperability problems. If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code.

Where the Verifier is integrated within the MTA and it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as:

451 4.7.5 Unable to verify signature - key server unavailable

Temporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code. In particular, cryptographic signature verification failures MUST NOT provoke 4xx SMTP replies.

Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader.

While the symptoms of a failed verification are obvious -- the signature doesn't verify -- establishing the exact cause can be more difficult. If a selector cannot be found, is that because the selector has been removed, or was the value changed somehow in transit? If the signature line is missing, is that because it was never there, or was it removed by an overzealous filter? For diagnostic purposes, the exact reason why the verification fails SHOULD be made available and possibly recorded in the system logs.

So it may vary based on receiving server configuration, but probably most will not mark as spam, especially if there is otherwise valid SPF and DMARC records and other indicators of a valid sender (IP address reputation, domain reputation, etc.).

Related Topic