The DKIM l tag limits how much of the canonicalized body contributes to the body hash. It can let a signature survive appended content, but that survival comes from leaving content outside the signature's coverage. Treat it as a security decision, not a routine fix for footer failures.
Know what the length measures
RFC 6376 section 3.5 defines l as a count of octets in the canonicalized body. It is not a character count, a line count or the size of an attachment. Canonicalization happens before the length limit is applied. Without l, the entire canonicalized body is covered. A value of zero permits no body content to contribute to the hash; it does not mean unlimited coverage.
If l exceeds the available canonicalized body length, the signature is invalid under the specification's verification rules. The upper bound is the explicit requirement in RFC 6376 section 3.5. An ordinary file-size comparison cannot reliably establish coverage because transfer encoding and canonicalization affect the relevant representation.
Understand why a pass may be misleading
The feature was designed to tolerate additions such as mailing-list trailers. However, RFC 6376 section 8.2 warns that appended content can exploit MIME structure or client rendering so that the recipient sees misleading material while the covered prefix remains intact. A passing signature therefore does not establish the integrity of the entire displayed body when l leaves a suffix uncovered.
Illustrative scenario: a signer covers an initial body prefix. A later processor appends text outside that prefix. The signature can remain valid if the covered prefix and signed headers remain unchanged and other verification checks pass. This is a conceptual coverage example, not a demonstration that every MIME append produces the same result or that a specific client will render it safely.
Inspect before changing policy
For each affected signature, retain the raw message, l, c, h, d and selector. Use a conforming verifier or byte-aware analysis to determine the canonicalized body length and covered prefix. Note whether Content-Type and other interpretation-relevant headers were selected. A header coverage review can expose additional risks, but it does not make unsigned body content signed.
Check whether the recipient system applies special policy to limited-body signatures. RFC 6376 section 8.2 warns signers to be extremely wary of l and notes that assessors might ignore such signatures. Do not promise that a mathematically valid prefix signature will be accepted everywhere.
Prefer complete content at the signing boundary
If the goal is to survive an outbound disclaimer, first evaluate moving the disclaimer before signing or signing the final message with an authorized domain. For mailing lists, examine the list's modification and signing design. These approaches address the processing order rather than hiding the changed suffix from coverage.
If a legacy workflow still uses l, document why, which routes depend on it and what recipient interpretation risks remain. Test removal or replacement in a controlled path with a rollback plan. Do not silently change the signing profile for all mail without checking legitimate delayed and indirect routes.
Make the review outcome specific
The outcome should state whether full or partial body coverage is intended, which messages use it and who accepted the residual risk. Preserve evidence of the exact signature and covered representation. A generic DKIM-pass count is insufficient to close this review because it says nothing about how much body content the signature protects.
Work a canonicalized-length example
Assume a conforming tool measures a canonicalized body of 140 octets and the signature has l=100. The body hash covers the first 100 octets; the remaining 40 are outside body-hash coverage. If the covered prefix and signed headers remain unchanged, further appended content may leave verification successful. If instead the canonicalized body is only 80 octets with l=100, the value violates RFC 6376 section 3.5 and the signature is invalid. These are constructed counts after canonicalization, not raw file sizes or an executed cryptographic test.
Keep a compact investigation record
Use this suggested worksheet for the route under review. It is a planning aid, not evidence of an executed test.
- Signature: d, selector, c, h and l, or record that l is absent.
- Coverage: canonicalized body length, covered prefix and unsigned suffix, measured by a conforming tool.
- Interpretation: Content-Type coverage and effects of MIME/client rendering.
- Decision: remove partial coverage, redesign signing order or document a narrowly scoped exception.