Summary

  • RFC 6376 allows the optional l= tag to limit a DKIM body hash to an initial prefix after canonicalization. Every byte beyond that limit is outside DKIM validation, even if the signature verifies successfully.
  • Body coverage is only half the question. h= identifies the ordered header fields covered by the selected signature; unsigned or differently selected headers can change meaning and rendering.
  • A defensible result preserves the exact signature, canonicalization, prefix and suffix lengths, hashes, observed key, verifier and trusted Authentication-Results boundary. dkim=pass alone is too lossy to reproduce the claim.

The check stopped before the message did

Imagine an evidence export with two rows:

authentication: dkim=pass

canonicalized body: 16,244 octets; l=12,000

The first row looks conclusive until the second supplies its scope. The verifier hashed the first 12,000 canonicalized octets. It did not validate the remaining 4,244. Those bytes might be a mailing-list footer, a harmless archive marker, an altered MIME continuation or content designed to dominate the recipient's display. The cryptographic result alone does not choose among them.

This is not a bug hidden outside the standard. RFC 6376 defines l= as an optional body-length count. Its default, when absent, is the entire body. When present, it tells the verifier how many octets of the canonicalized body enter the hash, beginning immediately after the header/body boundary. The specification is equally direct about the consequence: data beyond that limit is not validated by DKIM.

A verifier may apply stricter local policy. It can regard extra bytes with suspicion or reject a partly signed body. But if its cryptographic procedure successfully validates the requested scope, the signature can still reach success. The honest sentence is therefore not “the message is intact.” It is “this signature validated these selected headers and this canonicalized body prefix under the key observed for this signing domain.”

The distinction sits inside work associated with Murray Kucherawy. RFC 6376 names Dave Crocker, Tony Hansen and Murray S. Kucherawy together; it is a collective specification, not a personal invention certificate. RFC 8601, the current Authentication-Results specification, names Kucherawy as author. His official IETF profile listed 34 RFCs when captured for this research, while its autobiographical paragraph still said 33. That mismatch is a useful warning in miniature: even an authoritative page needs a timestamp and an exact field before it becomes evidence.

Count the body that the algorithm saw

The number in l= is not a convenient offset into a downloaded .eml file. DKIM first applies the body canonicalization selected by c= and then counts octets in that result. simple and relaxed canonicalization handle whitespace and empty lines differently. A raw-body length minus l= can therefore calculate the wrong tail.

Reproduction needs a defined sequence. Preserve the raw message. Select one exact DKIM-Signature field. Parse its c= value. Canonicalize the body with the named algorithm. Measure the canonicalized result. If l= exists, take exactly that initial prefix into the body hash; if it does not, use the entire canonicalized body. Compare the computed value with bh= and then verify the header signature with the observed public key.

The arithmetic becomes operational evidence:

unsigned suffix = canonicalized body octets - l

Record the full canonicalized-body hash, signed-prefix hash and unsigned-suffix hash as separate values. A zero suffix says that this body instance ended at the signature boundary. A positive suffix says only that bytes exist outside the boundary; it does not explain their origin or intent. l=0 is the extreme case: the body is completely unsigned even though header verification may still succeed.

The key observation also needs its own clock. d= names the signing domain and s= selects a DNS record. A later DNS lookup may find a rotated, revoked or replaced key. Reproducing an earlier decision therefore requires the key material, resolver result and observation time used by the verifier, with DNSSEC state recorded only if it was actually measured.

Robustness and abuse share the same opening

The original rationale for l= is practical. Mailing lists often append unsubscribe instructions or other trailers. If the original signer covered the entire body, that addition would break the signature. A bounded prefix can let a verifier recognise that the original portion survived while accepting extraneous material according to local policy.

That interoperability choice grants an intermediary room to add content. RFC 6376's security discussion warns that a malicious addition can benefit the attacker and, in some clients, appear to replace the original message. Altering MIME structure, exploiting permissive HTML parsing or interfering with duplicate detection can make a suffix far more visible than its position at the end suggests.

The correct response is not to label every mailing-list footer hostile. Nor is it to let the signed prefix confer integrity on the tail. Assess the two regions separately. Determine whether the intermediary was expected, whether the suffix matches its declared transformation, whether the MIME tree changed, and what the recipient's renderer actually presented.

This is where running code outranks a comforting icon. The RFC describes the byte procedure and warns about the display risk. Only the captured message, verifier implementation and renderer trace show which bytes a particular system authenticated and which bytes a person saw. A green badge that discards the boundary cannot answer either question.

The headers have a second perimeter

Even a fully signed body does not imply that every header field is signed. The h= tag contains an ordered, colon-separated list of header field names. DKIM's selection rule matters when fields repeat: the verifier chooses instances from the bottom upward for successive occurrences in h=. A receipt that stores only a set of names loses that ordering.

RFC 6376 requires From to be included. It strongly advises coverage for fields likely to affect display or processing, such as Date, Subject, Reply-To, Sender and MIME fields. With l= in use, Content-Type is especially consequential: changing it can cause a receiving client to render materially different content while the signed body prefix remains the same byte sequence.

“The subject was signed” is therefore incomplete unless the record identifies which Subject instance the algorithm selected. The same applies to duplicate From fields, MIME boundaries and newly inserted headers. Oversigning a header name that is not present can prevent a later insertion from going unnoticed, but that protection must be visible in the exact h= sequence.

For incident work, build a header coverage map. List every raw header in order, mark the instance selected by the chosen signature and state which display-relevant fields remain outside it. Keep that map separate for each signature. A message may carry a signer-domain signature, a list signature and a later gateway signature with different coverage and different keys.

Pass belongs to one signature, one key and one boundary

A DKIM pass is not a statement that a named person wrote the message. It says that the selected signature verified with a key advertised under a domain and selector, over the material that signature chose. Key custody, authorised use of the signing service, visible From identity, message truth and attachment safety are later assessments.

RFC 5585 makes the narrow integrity claim explicit: a valid signature shows that the signed message or signed portion was not modified after signing. It does not automatically raise or lower trust. RFC 5863 tells assessors to consider only the material within signature scope authentic; its example for l= limits that claim to the covered content. RFC 8301 updates algorithm and key requirements, adding another independent check. A strong acceptable key cannot expand a short body prefix.

This also keeps the present article distinct from DMARC. DMARC asks whether SPF or DKIM identifiers align with the visible From domain and gives receivers a policy signal. It does not enlarge DKIM's byte coverage. An aligned signature with an unsigned tail still has an unsigned tail; a complete DKIM body signature can exist whether or not DMARC passes.

The assessor should say which question it answered. Cryptographic validity, identifier alignment, signer reputation, content safety, delivery policy and final rendering are different columns. Combining them under “authenticated email” creates a result no component was authorised to produce.

Authentication-Results is not self-authenticating

Many downstream systems never perform DKIM themselves. They consume a header such as Authentication-Results written by an earlier verifier. RFC 8601 defines that handoff, but it does not turn the header into an independent proof object.

The producer and consumer must operate within a trust context. The authserv-id identifies the authentication service whose assertions the consumer is configured to accept. At an administrative boundary, forged fields that claim to come from inside must be removed or neutralised before a trusted result is added. A message sender can type dkim=pass into a header; the text becomes evidence only when the receiving architecture establishes who inserted it.

Store the raw Authentication-Results field, its position, authserv-id, producer identity and the rule that makes that producer trusted. Link it to the exact DKIM-Signature instance and verifier output. If a gateway collapses several signatures into one unqualified pass, the downstream consumer cannot recover which d=, s=, h= or l= produced the result.

Version and policy also matter. An implementation may report cryptographic success yet locally reject partial coverage. Another may admit the message but flag the tail. The receipt should preserve both the method result and the disposition decision without pretending that one caused every later action.

Build a scope ledger, not an authentication sticker

The minimum useful record begins with a content-addressed raw message. It then retains each DKIM-Signature field in original order and, for each one, d=, s=, i= if present, a=, c=, h=, l=, bh=, signature value and signing or expiry times when present.

Next comes reproducibility: observed DNS key and lookup time; canonicalized header and body representations or an exact procedure version; ordered header-instance resolution; full canonicalized-body length; signed-prefix and unsigned-suffix lengths and hashes; verifier implementation, result and reason. The trusted Authentication-Results producer and administrative boundary belong beside, not inside, the cryptographic result.

Finally, preserve the presentation layer. Parse the MIME tree, record which parts the client selected, and capture whether bytes outside l= influenced the visible result. This need not mean retaining a reader's private screen forever. A renderer version, selected part identifiers and a privacy-preserving render hash can establish the join without turning the audit system into a second mailbox.

Heng Lu's agency principle assigns each claim to the actor able to make it true. The standards authors define syntax. The signing domain and key custodian choose scope. An intermediary may transform the message. The verifier evaluates bytes and a key. The administrative domain vouches for its result channel. The mail client renders. The reader judges meaning. None can donate its authority to all the others.

The clean conclusion is longer than dkim=pass, but it survives scrutiny: signature two verified under this observed key; these ordered headers and the first N canonicalized body octets were covered; this suffix was outside validation; this trusted verifier recorded the result; this renderer displayed these parts; authorship, safety and intent remain separate assessments.

Sources