DKIM Record Parser

Detects whether the input is a DKIM public-key TXT record (RFC 6376 section 3.6.1) or a DKIM-Signature header (RFC 6376 section 3.5) and parses it accordingly. It validates tag syntax and key material only. It cannot verify a signature, because that needs the complete message and a live DNS key lookup, and it performs no network access. Algorithms are classified against the current specifications, not RFC 6376 alone: rsa-sha256 is required (RFC 8301), ed25519-sha256 is a current standard algorithm (RFC 8463), and rsa-sha1 is historic — RFC 8301 forbids signing or verifying with it, so a conforming verifier treats such a signature as permanently failed (PERMFAIL), even though the tag is syntactically valid. Component registration and algorithm definition are checked separately: the IANA DKIM Key Type registry contains rsa and ed25519, the IANA DKIM Hash Algorithms registry contains sha1 (historic) and sha256 (active), and there is no registry of key-type/hash pairings. RFC-defined DKIM algorithm pairings are rsa-sha256, ed25519-sha256, and the historic rsa-sha1; the currently usable algorithms are rsa-sha256 and ed25519-sha256. Any other syntactically valid a= is reported as unsupported, with the reason given separately: an unregistered key type, an unregistered hash, or a pairing (such as ed25519-sha1) that no RFC defines. RFC 8301 section 1 prohibits use of the SHA-1 hash algorithm generally, and section 3.1 separately classifies rsa-sha1 as a historic DKIM algorithm whose signatures have permanently failed evaluation; a sha1 component in any other pairing is reported as a violation of the first rule. An h= tag that is empty or has an empty list element is malformed: RFC 6376 treats an empty tag value differently from an omitted tag. For an RSA public key the modulus bit length is reported only when the DER SubjectPublicKeyInfo or RSAPublicKey structure parses; otherwise only the decoded byte length is shown. RFC 8301 requires at least a 1024-bit RSA key and recommends 2048-bit. Input whitespace follows RFC 6376: only space and tab may surround tags and values, a line break counts as folding whitespace only when it is followed by a space or tab, and one folding-whitespace run holds at most one line break, so two folds in a row (a whitespace-only line, RFC 6376 section 2.8 excluding RFC 5322 obsolete syntax; see erratum 5070) are never merged into one (a bare line break, a bare CR, NBSP and other non-ASCII spaces are likewise reported, never silently removed), and a record pasted as DNS presentation-form quoted strings is concatenated with no intervening whitespace (RFC 6376 section 3.6.2.2). The p= value (and b= / bh= in a signature) must be a DKIM base64string as defined by RFC 6376 section 2.10 with RFC 2045 base64 semantics: standard alphabet only (base64url is rejected), folding whitespace only, and a complete, correctly padded final quantum. An ed25519 public key is then checked in three separate layers, each with its own finding: base64string syntax, decoded length of exactly 32 bytes (RFC 8463 section 4.2, 44 base64 octets), and decodability as an Ed25519 point encoding under RFC 8032 section 5.1.3 (y below p, an x on the curve, and no zero x with the sign bit set). The point check is structural only: it says the encoding decodes to a point, not that the key is cryptographically sound; the point's order and subgroup membership are not checked and no signature is verified. Verified against RFC 6376, RFC 2045, RFC 8301, RFC 8463, RFC 8032 (including its errata) and the IANA DKIM Parameters registries on 2026-09-18.