A DKIM pass does not mean every displayed header was signed. Each signature selects header fields through its h tag and applies a specified canonicalization algorithm. To decide whether a subject, recipient field or other value was protected, inspect the actual coverage of the passing signature.
Start with the right signature
Record d, s, h and c for each DKIM-Signature header. Associate the receiver's trusted result with the corresponding signature rather than treating a message-level pass as evidence about all of them. A signature must include From, but not every other header is mandatory. RFC 6376 §5.4 explains the selection rules and recommends useful coverage.
If Subject is not selected, a change to Subject does not by itself alter the data protected by that signature. That statement is about cryptographic coverage, not whether the modified message is acceptable. A receiving service can still apply independent policy. Similarly, signing To does not bind the SMTP envelope recipient: the visible To header and RCPT TO address are different data; RFC 5321 §2.3.1 separates the SMTP envelope from message content.
Account for repeated fields
The h tag is not simply a set of unique names. Under RFC 6376 §5.4.2, repeated names select repeated physical occurrences, working from the bottom of the header block upward. For example, if a message has three Received fields and h lists Received twice, the bottom two occurrences are selected. Adding more occurrences of a name to h than exist at signing can detect later insertion of that field. This technique is often called oversigning.
Do not conclude that a topmost field is signed merely because its name appears once in h. Reconstruct the selection against the actual header block. Duplicate fields that should ordinarily be singular also raise parsing and message-validity questions; a DKIM calculation is not permission to ignore those concerns.
Distinguish value changes from normalized formatting
Under simple header canonicalization, the selected field must be presented exactly as signed. Relaxed header canonicalization lowercases field names, unfolds continuation lines and normalizes specified whitespace. It does not lowercase field values or make different subject text equivalent. Read the selected algorithm before attributing a failure to capitalization or rewrapping.
Illustrative test specification: one controlled signature selects From and Subject. Changing the Subject words is expected to invalidate that signature. A second signature selects From but omits Subject; the same subject change need not invalidate the second signature. The contrast explains expected coverage, not an endorsement of omitting Subject.
Improve coverage at the signer
Choose fields that affect the recipient's interpretation and can remain stable through the supported route. Inspect the recommendations in RFC 6376 §5.4.1 and your signer's capabilities. Avoid casually signing trace fields that legitimate transport will add or alter. Test the complete route with duplicate-field and formatting cases in a controlled environment.
Document the intended coverage profile alongside the signing configuration. A useful review states exactly which headers and occurrences are protected, which normalizations are allowed and which fields remain outside the signature. That is more defensible than describing DKIM as a seal over the entire message.
Trace a synthetic header selection
Imagine three X-Example fields in physical top-to-bottom order: newest, middle, oldest. A signature listing h=From:X-Example:X-Example selects oldest and then middle, not newest. With only one X-Example present at signing, listing X-Example twice also includes an absent occurrence; later insertion of another X-Example changes the selected input and can invalidate the signature. This is a selection exercise, not an executed signature test or a recommendation to permit duplicate normally singular fields.