What is DKIM?

Not the whole message. DKIM signs a chosen list of headers plus a hash of the body, and the header list is itself named in the signature so a receiver knows what to verify. Here is a real signature with the parts that matter:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com;
    s=google; h=from:to:subject:date:message-id; bh=X0hLp…; b=fRkT9…
                 │                                  │        └ signature over the headers in h=
                 └ exactly which headers are signed  └ hash of the body

The h= list is the security-relevant one and almost nobody looks at it. A header not named there can be added or altered in transit and the signature still verifies. Signing from is non-negotiable; a signature that omits it proves essentially nothing useful.

This is the practical reason DKIM carries more weight at the large mailbox providers, and it follows directly from what each one checks.

A mailing list that appends a footer breaks the body hash and therefore the signature. That is not a bug; it is DKIM correctly reporting that the message was modified. It is also why ARC exists — to let a trusted intermediary vouch that authentication passed before it made its changes.

1024-bit RSA keys still verify everywhere. They are also below what Gmail and Outlook consider adequate, and both have signalled they will stop treating them as a full pass. There is no upside to staying on one.

The reason people do is mechanical rather than principled: a 2048-bit public key does not fit in a single 255-byte DNS character-string, so it has to be published as multiple quoted strings inside one TXT record.

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…first part…"
"…second part…IDAQAB"

Two strings, one record — resolvers concatenate them with no separator. Most DNS providers handle the split automatically; a few require you to do it, and a few silently truncate, which produces a key that looks published and never verifies.

4096-bit is possible and rarely worth it: the record grows further, some resolvers struggle with the response size, and the security gain over 2048 is not the thing limiting your deliverability.

• Do not use the l= tag. It limits signing to the first N bytes of the body, so anything appended afterwards is unsigned and the signature still verifies. That is an open invitation to append content to your signed mail. It exists for historical mailing-list compatibility and should be left in history.
• Do not retire an old selector the moment you publish a new one. Mail signed with the old key is still in flight and still in inboxes. Leave the old record published until everything signed with it has aged out — a couple of weeks is generous, and the cost of leaving it is nil.

On its own, less than people expect. A DKIM failure is not a rejection — receivers weigh it. What makes it expensive is DMARC: if DKIM is your only aligned authentication method and it fails, DMARC fails, and then your published policy decides what happens.

Which is the argument for having both SPF and DKIM aligned rather than one. Direct mail typically has SPF alignment; forwarded mail typically has only DKIM. Cover both and alignment holds in both cases.