A DKIM-Signature is a set of semicolon-separated tags describing how a domain signed a message. Reading those fields helps you choose the right DNS lookup and investigation path. It does not let you validate the cryptography by eye. Preserve the original message before copying or reformatting a signature for inspection.
Start with the lookup and algorithm fields
The required d= value is the signing domain; required s= is the selector. With the normal DNS TXT query method, these lead to s._domainkey.d. The a= tag identifies the signing and hash algorithm. The required v= tag must have value 1 for RFC 6376 signature syntax. This differs from the version tag in a DNS key record. These values describe the signature, not its verification outcome. RFC 6376 §3.5, RFC 6376 §3.6.2.
Illustrative fragment, deliberately incomplete and not a valid signature: d=example.com; s=outbound2026; a=rsa-sha256; c=relaxed/relaxed; h=from:to:subject:date. Its lookup name is outbound2026._domainkey.example.com. Its canonicalisation uses relaxed processing for both headers and body. Its signed-header list names the selected header fields. The fragment omits required cryptographic values and must never be used as a production record.
Distinguish content coverage from signature data
The h= tag lists header fields supplied to the signing operation, in their defined order. It is not a hash algorithm. From must be included in a valid DKIM signature. Repeated header names and duplicate message fields need the selection rules in the specification; a casual glance at the list cannot resolve every coverage question.
The bh= tag holds the body hash. The b= tag holds the signature value. Matching or plausible-looking encodings do not prove validity. The c= tag describes canonicalisation, which permits specific normalisation of the signed representation. It does not permit arbitrary rewriting of a message. If c= is omitted, the default is simple/simple; if only one algorithm is named, it applies to headers and the body defaults to simple. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §5.4.
The optional l= tag limits the number of canonicalised body octets included. Its presence requires care: a valid signature may not cover content appended beyond that length. Do not describe every DKIM pass as proof that every visible byte is unchanged. RFC 6376 §3.5, RFC 6376 §8.2.
Interpret identity and time carefully
The optional i= value is an agent or user identifier asserted under the signing domain's rules; it is not necessarily a working mailbox. DMARC uses validated d=, not i=, for DKIM alignment. The t= and x= tags describe signing time and signature expiration. RFC 6376 §3.5 formally marks both RECOMMENDED, although they may be absent. They are signature metadata, not proof of actual SMTP arrival time. Preserve Received headers and system logs for transit analysis.
A signature using obsolete cryptography should not be accepted merely because its fields parse. RFC 8301 §3.1 prohibits rsa-sha1; RFC 8301 §3.2 updates RSA key requirements. Use supported verification software and current provider guidance rather than manually implementing these checks from this field guide.
Finish with the receiver result
Collect the d/s pair, algorithm, relevant coverage fields, trusted DKIM result and failure reason. If DNS is missing, investigate the exact owner name and key lifecycle. If the key is available but verification fails, compare signing and delivery paths without changing the original evidence. Confirm any remediation with a newly sent message and a trusted receiver result. The goal is a defensible explanation of a signature, not a visual pass/fail guess.
Apply the distinction
Read the illustrative fragment in four groups: d/s selects identity and lookup; a/c specifies algorithm and canonicalization; h and any l define coverage; b/bh carry values that software verifies. Missing required v/b/bh means the fragment is not a valid signature. If l=0 appears in a real signature, zero body octets are hashed, so body integrity is not protected; RFC 6376 §3.5 defines that length mechanism. None of these observations is a cryptographic pass.