DMARC Analyzer

TL;DR

• 14 canonical tags per RFC 6376 §3.5: 7 REQUIRED (v=, a=, d=, s=, h=, bh=, b=) and 7 OPTIONAL (c= with a default, i=, q=, l=, t=, x=, z=).
• Two hashes, not one: bh= is the body hash; b= is the signature over the signed-header set INCLUDING the DKIM-Signature header itself (with b= temporarily emptied for the signing computation). Most dkim=fail comes from bh= mismatch (forwarder rewrote the body).
• Modern defaults: v=1, a=rsa-sha256, c=relaxed/relaxed, q=dns/txt (the only defined query method). rsa-sha1 is forbidden by RFC 8301; simple/simple and 1024-bit keys are permitted but fragile or discouraged, and stricter receivers may score them down.
• NEVER use l=. The body-length-limit tag is a documented replay-attack vector (attacker appends content past the signed prefix and the signature still verifies). RFC 6376 §8.2 itself cautions against it.
• t= yes, x= usually no. The signing timestamp gives receivers replay-detection material. Hard expiration via x= trades replay defense for clock-skew failure modes — set generously (24+ hours past t=) or omit.
• h= must cover From. RFC 6376 §5.4 mandates signing the From: header; a verifier must ignore a signature whose h= omits it (dkim=permerror). Modern signers cover From, Subject, Date, To, Message-ID, Reply-To, Sender, MIME-Version at minimum.
• d= drives DMARC alignment, not i=. The DMARC engine compares the d= tag to the From: header per RFC 7489 §3.1 — the M365 onmicrosoft.com gotcha and Workspace gappssmtp.com gotcha are both d= misalignment bugs (dkim=pass but DMARC fails).
• Tag ordering and case: tags MAY appear in any order; tag NAMES are case-sensitive lowercase per RFC 6376 §3.2 ABNF; tag VALUES vary by tag (case-sensitive too unless the tag's description says otherwise, as with the domain in d=). Convention: tags appear in the order v;a;c;d;s;t;x;h;bh;b but verifiers do not depend on it.

What this guide covers

A complete byte-by-byte reference for the DKIM-Signature header per RFC 6376 §3.5. Where DKIM explained documents the high-level signing pipeline (key generation, canonical body-hash, signature production, verifier workflow) and DKIM canonicalization documents the c= tag's simple-vs-relaxed semantics in depth, THIS page documents EVERY tag in the DKIM-Signature header. Each tag gets its own section: what it carries, what its valid values are, what default applies when absent, what operational decisions it encodes, and what failure modes it produces.

The page is the SENDER-SIDE companion to DKIM failures explained, which documents the RECEIVER-SIDE verdict catalogue. The two pages together form the canonical DKIM message-level reference: this page documents what the signer EMITS; the failures page documents what the verifier OUTPUTS after evaluating it.

Operators arriving here typically have a DKIM-Signature header they need to decode, debug, or audit — either inspecting an inbound message to understand the sender's posture, or inspecting an outbound message to verify their own signer's output. The decision matrix section at the end maps from "I see this tag value" to "this is what it means operationally".

Shape of a DKIM-Signature header

A complete DKIM-Signature header is a single long header value (typically line-folded for readability) containing semicolon-separated tag=value pairs:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=selector1;
        t=1715430123;
        h=From:To:Subject:Date:Message-ID:Reply-To;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=AbCdEf1234567890PqRsTu+/0987WxYz1234567890ABCDef
          ghIJklmnopQRSTuvWXYZabcdef1234567890abcdefghIJKL
          mnopqrstUVWXYZ1234567890abcdef==

Whitespace between tags is irrelevant (per RFC 6376 §3.2 ABNF the inter-tag whitespace is folded out during parsing). The header MAY be expressed entirely on one logical line; folding into multiple visual lines is a presentation convenience.

The 14 tags

The RFC 6376 §3.5 tag dictionary, with required/optional status:

REQUIRED:
  v=    Version (always 1)
  a=    Algorithm (rsa-sha256, rsa-sha1 deprecated, ed25519-sha256)
  d=    Signing-domain identifier (drives DMARC alignment)
  s=    Selector (locates the public-key TXT in DNS)
  h=    Signed-header list (colon-separated header names)
  bh=   Body hash (base64-encoded SHA hash of canonical body)
  b=    Signature (base64-encoded crypto signature of signed-header set)

OPTIONAL (defaults apply when absent):
  c=    Canonicalization (default: simple/simple — but modern signers
        always emit relaxed/relaxed)
  i=    AUID (default: @<d=value>)
  q=    Query method (default: dns/txt — the only defined method)
  l=    Body-length limit (default: none — DO NOT USE)
  t=    Signing timestamp (default: none — receivers MAY require it)
  x=    Expiration timestamp (default: none — never expires)
  z=    Copied headers (default: none — diagnostic-only)

A signer MUST emit all REQUIRED tags; omitting any one produces a malformed DKIM-Signature header that verifiers reject with dkim=permerror. The OPTIONAL tags are signer-chosen — their absence means the spec's default applies.

v= — Version

Required. The DKIM protocol version. The only valid value is v=1.

What it carries

A single integer identifying the protocol version under which the signature was produced. RFC 6376 §3.5 specifies v=1; no other version has ever been published. Even algorithm extensions (RFC 8301 deprecating rsa-sha1, RFC 8463 adding Ed25519) did not bump the version — they extended the a= tag's value space instead.

Validity rules

• MUST appear (REQUIRED).
• MUST equal 1.
• Conventionally the FIRST tag in the header; verifiers do not depend on this convention.

Failure mode

A DKIM-Signature without v= or with v= not equal to 1 is REJECTED by verifiers per RFC 6376 §6.1.1. The verdict is dkim=permerror with reason "incompatible DKIM version" or similar.

a= — Signing algorithm

Required. The cryptographic algorithm pair: signature algorithm + hash algorithm.

Defined values

• a=rsa-sha256 — modern default. RSA signature + SHA-256 hash. Mandatory per RFC 8301 and the only algorithm most receivers accept without question.
• a=rsa-sha1 — forbidden by RFC 8301 §3.1: it MUST NOT be used for signing or verifying. SHA-1 is broken; verifiers that follow RFC 8301 treat signatures using it as permanently failed. Senders MUST migrate away.
• a=ed25519-sha256 — introduced by RFC 8463. EdDSA over Curve25519 + SHA-256 hash. Smaller public keys, faster verification. Adoption growing but not yet universal — some legacy verifiers emit dkim=permerror on Ed25519 signatures because they do not implement the algorithm.

Validity rules

• MUST appear (REQUIRED).
• MUST be one of the registered algorithm names in the IANA DKIM Algorithms registry.
• MUST match the algorithm declared in the public-key TXT's k= tag (default k=rsa; k=ed25519 for Ed25519 signatures).

Failure modes

• a= missing → dkim=permerror.
• a= value not recognized by the verifier → dkim=permerror.
• a= recognized but deprecated by receiver policy → dkim=policy.
• a= does not match k= in the public-key TXT → dkim=permerror.

Operational guidance

Use a=rsa-sha256. Migrate any remaining rsa-sha1 signers immediately. Adopt a=ed25519-sha256 only after confirming your top inbound receivers all support it (most modern verifiers do as of 2024).

c= — Canonicalization

Optional (default: simple/simple — but modern signers always emit relaxed/relaxed).

Format

Two slash-separated values: c=<header-canon>/<body-canon>. Each side may be simple or relaxed:

• simple — STRICT. No modifications to whitespace, case, or line endings. Any single-byte change breaks the signature.
• relaxed — FORGIVING. Collapses runs of whitespace, normalizes header-name case to lowercase, strips trailing whitespace, ignores empty lines at body end.

The four combinations

• c=simple/simple — strictest; almost no message survives forwarding intact. Avoid.
• c=simple/relaxed — strict headers + forgiving body. Rare in practice.
• c=relaxed/simple — forgiving headers + strict body. Rare in practice.
• c=relaxed/relaxed — modern industry default. M365 and Workspace both default to this. Tolerates the common forwarder/MTA modifications without sacrificing security.

Failure mode

c=simple/simple messages almost always produce dkim=fail after forwarding through any list, security gateway, or MIME-re-encoding MTA. The common modern recommendation is relaxed/relaxed. See DKIM canonicalization for the algorithmic deep dive.

d= — Signing-domain identifier

Required. The domain that authorized the signature. THIS is the DMARC alignment anchor.

What it carries

A DNS domain name (case-insensitive). Receivers compare it against the From: header per RFC 7489 §3.1 for DMARC alignment:

• Strict alignment: d= must equal From: exactly.
• Relaxed alignment: d= must share the same organizational domain as From: (via Public Suffix List).

Common values

• d=example.com — your custom sending domain (correct).
• d=tenant.onmicrosoft.com — M365 falling back to tenant identity (the #1 M365 DMARC failure mode; fix is Set-DkimSigningConfig for the custom accepted domain — see DKIM for Microsoft 365).
• d=tenant.gappssmtp.com — Workspace falling back to tenant identity (the #1 Workspace DMARC failure mode; fix is clicking Start authentication for the custom domain — see DKIM for Google Workspace).

Validity rules

• MUST appear.
• MUST be a valid DNS domain name.
• The public-key TXT at <s=>._domainkey.<d=> MUST resolve.

Failure modes

• d= domain has no <s=>._domainkey TXT → dkim=permerror.
• d= domain has the TXT but it is empty (revoked) → dkim=permerror.
• d= does not align with From: → dkim=pass but DMARC fails.

s= — Selector

Required. The DKIM selector, locating the public-key TXT record under d=.

What it carries

A short token forming the leftmost label of the public-key lookup name:

; The verifier looks up:
<s=value>._domainkey.<d=value>  IN  TXT

; Example: s=selector1, d=example.com
selector1._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=..."

Common per-provider naming

• selector1 / selector2 — Microsoft 365 (two selectors for automatic rotation).
• google — Google Workspace (single default selector).
• default — cPanel and many self-hosted DKIM signers.
• s1 / s2 — SendGrid (rotation pair).
• mte1, k1, mta, 20221208 (date-based) — various ESPs.

Failure mode

Wrong-selector lookups produce dkim=permerror (NXDOMAIN at the constructed lookup name). See DKIM selectors explained for the cross-provider naming catalogue.

h= — Signed-header list

Required. Colon-separated list of header names included in the signature.

What it carries

The exact header-name sequence that forms the signing input. The verifier reconstructs this sequence by concatenating the named headers (with canonicalization applied) before verifying b=.

; Common conservative h= list:
h=From:To:Subject:Date:Message-ID:Reply-To:Sender:MIME-Version

; Extended h= list (modern signers):
h=From:To:Subject:Date:Message-ID:Reply-To:Sender:MIME-Version:
  Content-Type:Content-Transfer-Encoding:List-Unsubscribe:
  Auto-Submitted:References:In-Reply-To

Required header coverage

Per RFC 6376 §5.4, From: MUST appear in h=. A verifier MUST ignore a signature that omits it and return PERMFAIL (From field not signed), that is dkim=permerror. Modern senders also cover Subject, Date, To, Message-ID, Reply-To, and Sender at minimum.

Repeated header names

A header name MAY appear multiple times in h= to sign multiple instances of that header in the message (e.g., signing two Received headers separately). RFC 6376 §3.5 specifies "first instance from the bottom" matching for each occurrence — useful to bind a signature to specific Received hops against a downstream MTA's later insertions.

Null-header behaviour

A header name in h= that does not exist in the message is treated as a null header for signing — its absence is signed by its absence. Downstream insertion of that header will then invalidate the signature.

Failure modes

• h= missing → dkim=permerror.
• h= missing From: → dkim=permerror (the signature is ignored as invalid).
• Downstream MTA modified a signed header → dkim=fail.

bh= — Body hash

Required. Base64-encoded cryptographic hash of the canonicalized message body.

What it carries

The hash output (SHA-256 for rsa-sha256 / ed25519-sha256; SHA-1 for the deprecated rsa-sha1) of the message body after applying the body canonicalization side of the c= tag. Verifiers compute the same hash from the received body and compare against bh=.

The two-hash design

RFC 6376 §3.7 specifies TWO independent cryptographic operations: the body hash (bh=) and the signed-header-set signature (b=). The signed-header set INCLUDES the DKIM-Signature header itself (with b= temporarily emptied to avoid recursion). The bh= is part of the signed-header set, so b= implicitly authenticates the body hash.

The verifier checks them sequentially: body hash first (cheap — pure SHA), then signature (expensive — public-key crypto). Body-hash mismatches abort early without consuming the public-key operation.

Failure mode

A bh= mismatch produces dkim=fail with reason "body hash did not verify" — by far the most common dkim=fail in practice. Almost always traces to a forwarder/list rewriting the body (footer injection, MIME re-encoding, line-ending normalization). See dkim=fail in the failures catalogue for the full diagnostic walkthrough.

b= — Signature

Required. Base64-encoded cryptographic signature over the canonicalized signed-header set.

What it carries

The output of the a=<sig-alg>-<hash-alg> cryptographic operation applied to the canonicalized signed-header set. For rsa-sha256 it is a 256-byte (2048-bit-key) or 512-byte (4096-bit-key) RSA signature, base64-encoded. For ed25519-sha256 it is a 64-byte Ed25519 signature.

The signed-header set

The signing input is constructed by:

1. Take each header named in h=, in the order they appear in h=.
2. Apply the header canonicalization side of c= to each named header.
3. Concatenate the canonicalized headers in h= order.
4. Append the DKIM-Signature header itself, canonicalized, with b= temporarily emptied (so the value of b= does not recursively appear in its own input).
5. Hash and sign the resulting input.

Failure mode

A b= mismatch produces dkim=fail with reason "signature did not verify". Rarer than bh= mismatch and typically points at header modification by an intermediate MTA — Subject prefix added by an anti-spoof rewriter, Reply-To inserted by a mailing-list manager, or DKIM-Signature header tampered with after signing.

Signature truncation in Authentication-Results

Receivers typically record the first 8 bytes of the base64 signature as header.b= in Authentication-Results (e.g., header.b=AbCdEf12). This short prefix uniquely identifies which DKIM-Signature instance produced the verdict when a message carries multiple signatures.

i= — AUID (Agent or User Identifier)

Optional. Defaults to @<d=value>.

What it carries

A local-part + @ + domain construction identifying the agent or user on whose behalf the message was signed. Examples:

• i=@example.com (default when absent if d=example.com).
• i=alice@example.com — specific user.
• i=marketing@example.com — organizational sub-agent.

The domain part of i= MUST equal d= OR be a subdomain of d=. The local-part is free-form.

Operational guidance

i= is rarely consequential. DMARC alignment evaluates against d=, not i=. Omit unless you have a specific reason to identify a sub-agent (a marketing-platform sub-account, a per-user signing identity for legal-hold purposes).

Failure mode

i= with a domain that is not a subdomain of d= → dkim=permerror. Some receivers compare i= local-part against From: local-part for additional verification, though this is non-normative.

q= — Query method

Optional. Defaults to q=dns/txt.

What it carries

The method by which the verifier should retrieve the public key. The only defined value per RFC 6376 §3.6 is q=dns/txt — DNS TXT lookup. Omit the tag to use this default. Future extension methods could add new query methods; none have been standardized.

Failure mode

q=<unknown> → dkim=permerror with reason "unsupported query method".

Operational guidance

Omit. The default is correct for every deployed DKIM signer.

l= — Body-length limit (DO NOT USE)

Optional. No default.

What it carries

An integer specifying how many bytes of the body to include in the body-hash computation. The remainder of the body is UNSIGNED.

Why it exists

The tag was originally introduced so mailing-list footers appended AFTER signing would not break the body hash — the signer would set l=<body-byte-count> so only the original body (not the appended footer) is included in the hash.

Why it is dangerous

The same property is a replay-attack vector. An attacker can take a legitimately-signed message with l=, append arbitrary malicious content past the signed prefix, and the modified message still verifies because the appended bytes are OUTSIDE the hashed region. The appended content can be a malicious payload, a phishing link, or arbitrary abuse content — all under the cover of a legitimate DKIM signature.

RFC 6376 §8.2 itself cautions

Use of the "l=" tag might allow display of fraudulent content
without appropriate warning to end users. [...]
To avoid this attack, Signers should be extremely wary of using
this tag, and Assessors might wish to ignore signatures that use
the tag.

The modern recommendation

NEVER use l= in production. Accept body-hash mismatches from forwarders/lists, configure ARC sealing for forwarder survivability (see ARC explained), and let DMARC relaxed-alignment SPF + DKIM any-pass-wins handle the policy decision.

Failure mode

Receivers do NOT reject l= signatures (they verify correctly per RFC 6376) but every modern security analysis since 2007 has cautioned against the tag. Some strict receivers emit dkim=policy when l= is present.

t= and x= — Signing and expiration timestamps

Both optional. Both expressed as seconds since the Unix epoch (1970-01-01T00:00:00Z).

t= — Signing timestamp

The time at which the signature was produced. Receivers MAY use it to detect signature replay — rejecting (or flagging) signatures with t= older than some threshold (e.g., 7 days). The tag is INFORMATIONAL — verifiers do not require it but its presence helps receiver-side defenses.

x= — Expiration timestamp

The time after which the signature MAY be considered invalid. Verifiers checking x= ignore signatures whose x= is past the current time and return PERMFAIL (signature expired). RFC 6376 permits this but does not require it — a receiver MAY reject an expired signature.

Operational guidance

• Include t= — gives receivers replay-detection material without committing to hard expiration.
• Avoid x= — introduces clock-skew failure modes. If signer and receiver disagree by more than the x= window, legitimate mail fails dkim=policy with reason "signature expired".
• If you must use x=, set generously: 24+ hours past t= minimum. Make sure your signer's clock is NTP-synchronized.

Failure modes

• x= past current time → dkim=policy with reason "signature expired".
• t= older than receiver replay-detection threshold → dkim=policy with reason "signature too old".

z= — Copied headers (diagnostic-only)

Optional. No default.

What it carries

Pipe-separated copies of selected message headers at the time of signing, encoded for transport (whitespace replaced with `=20` etc. per RFC 6376 §3.5 DKIM-Quoted-Printable encoding). The tag is diagnostic only — verifiers do NOT use z= for verification, just for failure forensics.

Use case

When a verifier emits dkim=fail because a signed header was modified downstream, z= lets the operator compare the signed snapshot against the current message header to identify which header was tampered.

Operational guidance

Generally omit. z= bloats the DKIM-Signature header substantially. Include only if you actively investigate downstream-modification incidents and need the forensic snapshot.

Detecting malformed DKIM-Signature headers

The most common malformations operators encounter when auditing signed mail:

1. Missing required tag

Any of v=, a=, d=, s=, h=, bh=, b= absent. Verdict: dkim=permerror. Cause: signer misconfiguration or header truncation.

2. Inconsistent algorithm declarations

a= declares one algorithm but the public-key TXT's k= tag declares a different one. Verdict: dkim=permerror.

3. Invalid base64 in b= or bh=

A character outside the base64 alphabet appears in either tag, or the length does not match the algorithm's signature/hash output size. Verdict: dkim=permerror.

4. i= domain not under d=

i=user@foreign.com with d=example.com is invalid — the i= domain must equal or be a subdomain of d=. Verdict: dkim=permerror.

5. From: header missing from h=

Per RFC 6376 §5.4, From MUST be signed. §6.1.1 tells the verifier to ignore a signature without it. Verdict: dkim=permerror.

6. l= present in production

Not technically malformed but a red flag. The replay-attack risk should prompt an investigation: who set the tag, why, and can it be removed?

Diagnostic tools

The Email Header Analyzer (header_analyzer.php) parses DKIM-Signature headers tag-by-tag via includes/EmailHeaderParser.php and surfaces all malformation patterns above. The Domain Security Checker validates the public-key TXT side of the equation — confirming the d= and s= referenced by a DKIM-Signature actually resolve to a valid public-key record.

Frequently asked questions

What does the DKIM-Signature header look like?

A typical DKIM-Signature header is one wrapped logical line containing tag=value pairs separated by semicolons. Example: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=From:To:Subject:Date:Message-ID; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=AbCdEf1234567890... The required tags are v= (version, always 1), a= (algorithm, modern senders use rsa-sha256), d= (signing domain), s= (selector), h= (signed-header list), bh= (body hash base64), and b= (signature base64). Optional tags are c= (canonicalization, default simple/simple; modern senders use relaxed/relaxed), i= (AUID), q= (query method, defaults to dns/txt), l= (body-length limit), t= (signing timestamp), x= (expiration timestamp), and z= (copied headers).

What is the difference between the b= and bh= tags?

The b= tag (base64) holds the cryptographic signature of the SIGNED-HEADER set including a representation of the DKIM-Signature header itself (with the b= value temporarily empty for the signing computation). The bh= tag (also base64) holds a SEPARATE hash of the message body. The verifier checks both: it computes the body hash and compares against bh=, and it reconstructs the signed-header set and verifies the signature against b=. Most dkim=fail verdicts in practice come from a bh= mismatch — a forwarder rewrote the body so the computed hash no longer equals the published bh=. dkim=fail from a b= mismatch is rarer and usually means a header was modified after signing (e.g., a Subject prefix added by an anti-spoof gateway). The two-hash design is intentional: it lets receivers verify the body hash cheaply (without performing public-key cryptography) before committing to the expensive signature verification.

What does v=1 mean in DKIM-Signature?

v=1 is the protocol version per RFC 6376 §3.5. There has never been a v=0 or v=2 in production DKIM — the spec was published as v=1 from the start and no subsequent algorithm revisions (RFC 6376 errata, RFC 8301 algorithm update, RFC 8463 Ed25519 algorithm addition) have bumped the version. As an operator you must always emit v=1 and verifiers MUST reject signatures lacking it. The tag is required per §3.5 and is conventionally the first tag in the header. If you see a DKIM-Signature without v=1 it is malformed and verifiers will emit dkim=permerror.

What is the h= tag and which headers should it cover?

The h= tag lists the names of message headers covered by the signature, colon-separated and case-insensitive. The verifier reconstructs the signed-header set by concatenating these exact headers in the listed order (with canonicalization applied per the c= tag). The most-commonly signed headers per the RFC 6376 Appendix C example: From (REQUIRED — RFC 6376 §5.4 mandates From signing), Subject, Date, To, Message-ID, Reply-To, Sender, MIME-Version, Content-Type, Content-Transfer-Encoding. Modern signers also include List-Unsubscribe (RFC 8058 one-click), Auto-Submitted, References, In-Reply-To, and Resent-* headers when applicable. A header named in h= that does not exist in the message is treated as a null header for the signing computation. If h= omits From, the verifier MUST ignore the signature and return PERMFAIL (From field not signed); for other important headers a receiver may emit dkim=policy when its local policy requires them signed.

What is the difference between c=simple/simple and c=relaxed/relaxed?

c= specifies the canonicalization algorithm pair: c=<header-canon>/<body-canon>. simple is the strict mode — no whitespace or case modifications allowed; any single-byte change anywhere breaks the signature. relaxed is the forgiving mode — collapses runs of whitespace, normalizes case in header names, strips trailing whitespace, and ignores empty lines at the end of bodies. The modern industry default is c=relaxed/relaxed because forwarders, mailing lists, and security gateways routinely perform whitespace normalization that simple cannot tolerate. Microsoft 365 and Google Workspace both default to relaxed/relaxed. Use simple/simple only for closed-loop signing where you control every hop in the delivery path. The full canonicalization tradeoff is in help_dkim_canonicalization.php.

When should I use the t= and x= timestamp tags?

The t= tag is the signature timestamp (seconds since Unix epoch); the x= tag is the signature expiration timestamp. Both are optional. Receivers MAY use t= to detect signature replay (refusing signatures with t= older than some threshold) and MAY use x= to refuse signatures past their declared expiration. The operational tradeoff: including t= and x= reduces replay-attack dwell time (see help_dkim_replay_attacks.php) but introduces clock-skew failure modes — if your signer and the receiver disagree on the current time by more than the expiration window, legitimate messages fail dkim=policy. Modern recommendation: include t= but not x=. The t= alone gives receivers replay-detection material without committing to a hard expiration. If you do use x=, set it generously (24 hours minimum past t=) and ensure your signer clock is NTP-synchronized.

What is the l= tag and why is it dangerous?

The l= tag is the body-length-limit per RFC 6376 §3.5 — it tells the verifier "only hash the first N bytes of the body when computing bh=". Operators sometimes add l= so mailing-list footers appended after signing do not break the body hash. But l= is dangerous as a replay-attack vector: an attacker can take a legitimately-signed message with l=, append arbitrary malicious content past the signed prefix, and the modified message still verifies because the appended bytes are outside the hashed region. The canonical industry advice (RFC 6376 §8.2 itself + every security analysis since) is: NEVER USE l= in production. Set the body completely without partial-hash, accept the body-hash-mismatch failures from forwarders, and let DMARC alignment handle the policy decision via SPF + relaxed alignment. If you do use l=, set it to the full body length and remove the tag — at which point it adds nothing and you might as well omit it.

What does the i= tag mean and when should I set it?

The i= tag is the Agent or User Identifier (AUID) per RFC 6376 §3.5 — typically a local-part @ d= construction like i=alice@example.com or @example.com. It identifies the SPECIFIC user or agent on whose behalf the message was signed, distinct from the d= signing-domain identifier. When absent, i= defaults to @<d=value>. The AUID is OPTIONAL and rarely consequential — DMARC alignment evaluates against d=, not i=. Practical guidance: omit i= unless you have a specific reason to identify a sub-agent (a marketing-platform sub-account, a per-user signing identity). When emitted, the i= local-part must match what the verifier expects per any local policy that constrains AUIDs. Some receivers compare i= against the From: header local-part for additional verification, though this is non-normative.

Related guides

• DKIM explained — the protocol primer. Start here if you have not seen the high-level signing pipeline.
• BIMI explained — the PER-MESSAGE-DKIM-ALIGNED-PASS-AS- UPSTREAM-PRECONDITION-FOR-PER-MESSAGE-BIMI- BRAND-INDICATOR-RENDERING companion reference. Where THIS page documents the per-message DKIM-Signature header tag wire- format (the canonical v=1; a=rsa-sha256; d=<domain>; s=<selector>; c=relaxed/relaxed; h=From:To:Subject:Date; bh=<base64-body-hash>; b=<base64-signature> tag-list grammar per RFC 6376 §3.5), the BIMI- explained pillar documents the per-receiver per-message brand-indicator rendering OUTCOME the per-message DKIM-aligned-pass verdict produced by THIS DKIM-signature wire-format STRUCTURALLY GATES: (i) per- message-DKIM-aligned-pass-as-upstream- precondition-for-per-message-BIMI-rendering — the per-receiver per-message BIMI brand-indicator rendering at the consumer-inbox-view is STRUCTURALLY GATED on a per-message DKIM-aligned-pass verdict plus a publisher DMARC policy at p=quarantine or p=reject; the per-receiver rendering policy checks BOTH the per- message DKIM signature THIS page documents AND the publisher's DMARC terminal- enforcement state at the moment of per-message rendering; (ii) per- publisher-BIMI-record-publication-as- downstream-consumer-of-per-publisher-DKIM- key-publication — the BIMI TXT record at default._bimi.<author- domain> only becomes operationally meaningful when the publisher has FIRST published the DKIM public-key TXT records at every signing selector THIS page documents the per-message s= tag points at; the BIMI publication is downstream of the DKIM infrastructure publication; (iii) per-receiver-brand-indicator- cache-as-downstream-consumer-of-per-message- DKIM-pass-rate — the per-receiver BIMI rendering cache stores the per- publisher per-author-domain rendering eligibility as a per-day per-author-domain rolling-average of per-message DKIM-pass rate; per-author-domain DKIM-pass-rate regression (selector rotation defects, body- modification-by-relay defects, key-revocation defects THIS page documents) DIRECTLY suppresses per-receiver brand-indicator rendering at consumer-inbox-views; (iv) per-publisher-BIMI-VMC-binding-as- downstream-consumer-of-per-publisher-DKIM- d-tag-canonical-author-domain — the X.509 Verified Mark Certificate (VMC) bound to the publisher's trademark-registered brand uses the author-domain identity that the per-message DKIM d= tag THIS page documents must be DMARC-aligned with at every BIMI-rendering-eligible per-message verification event. Read this WITH the DKIM-signatures wire-format reference when the publisher's Phase 6 brand-trust- monetisation question moves to the operator's queue: THIS page documents the per-message cryptographic-signature authoring discipline, the BIMI-explained pillar documents the brand-trust- monetisation OUTCOME the per-message DKIM-aligned-pass verdict STRUCTURALLY UNLOCKS at the publisher's recipient-side brand-impression surface.
• BIMI SVG Tiny PS logo requirements — the CROSS-ASSET-CLASS-PARALLEL-BYTE- PROFILE-AUTHORING-DISCIPLINE companion reference. Where THIS page documents the DKIM-Signature header tag wire-format (the per-message v=1; a=rsa-sha256; d=<domain>; s=<selector>; c=relaxed/relaxed; h=From:To:Subject:Date; bh=<base64-body-hash>; b=<base64-sig> tag-value grammar at RFC 6376 §3.5 + §3.6 byte precision the SIGNING-MTA stamps into the outgoing message at the application layer), the BIMI-SVG-Tiny-PS spoke documents the STRUCTURALLY-PARALLEL publisher-side byte-profile authoring discipline for the SVG-Tiny-PS image profile (a strict W3C SVG-Tiny-1.2 subset compliance contract with baseProfile="tiny-ps" root attribute + <title> element + square viewBox + the forbidden-element / forbidden-attribute taxonomy), across four cross-asset-class byte-conformance dimensions: (i) both wire- formats are byte-precision-strict — DKIM-Signature header bytes feed the receiver-side hash recomputation that MUST recompute the exact same bh= body hash and b= signature bytes the signer produced; SVG-Tiny-PS image bytes feed the MUA-side VMC SVG-hash-binding validator that MUST match the VMC certificate's embedded hash exactly, (ii) both wire-formats have a canonical-form discipline at the producer side — DKIM body canonicalization (simple vs relaxed) per RFC 6376 §3.4 normalises body bytes prior to bh= hash; SVG-Tiny-PS authoring constraints constrain element and attribute orderings to a canonical producer-side output prior to hashing into the VMC, (iii) both wire-formats have a publisher-side observability gap — the signer cannot directly observe which receivers' verifiers reject a per-tag DKIM-Signature header field; the publisher cannot directly observe which MUAs' BIMI-renderers reject a per-byte SVG-Tiny-PS image, and (iv) both wire- formats compose into the same downstream BIMI-display gate at the MUA — DKIM-pass is a prerequisite for the DMARC-pass that is a prerequisite for the BIMI display eligibility the SVG-Tiny-PS authoring contract THIS page's DKIM-Signature header produces alignment evidence for, AND the SVG-Tiny-PS byte-compliance gate is the co-prerequisite for the same BIMI display eligibility. Read the BIMI-SVG-Tiny-PS spoke alongside this page when scoping the publisher-side cross-asset-class byte- profile authoring discipline — the per-message DKIM-Signature header tag wire-format authoring contract THIS page documents and the publisher-side SVG-Tiny-PS image profile authoring contract the BIMI-SVG-Tiny-PS spoke documents share structurally-parallel byte-precision strictness, canonical-form discipline, publisher-side observability gap, and downstream BIMI-display composition relationships.
• SPF include: vs ip4: vs a: vs mx: decision tree — the ENVELOPE-LAYER-IP-AUTHORIZATION- MECHANISM-CHOICE-VS-APPLICATION-LAYER- SIGNATURE-VERIFICATION CROSS-PROTOCOL DECISION-TREE COMPLEMENT to this DKIM-Signature header tag-anatomy deep dive. Where THIS page documents the per-message DKIM-Signature header tag anatomy (the v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tags the sender stamps INTO the outgoing message at the APPLICATION layer where the receiver's verifier recomputes the signature against the published public key WITHOUT reference to which IP transmitted the message), the include- vs-ip4-vs-a-vs-mx decision-tree spoke is the ENVELOPE-MAIL-FROM-LAYER companion documenting the FOUR structurally-distinct SPF IP-providing mechanism choices the operator must decide between when authoring the SPF record that the receiver consults BEFORE DKIM verification runs: (i) ip4: / ip6: — direct CIDR enumeration, the LOWEST- DELEGATION-RISK envelope-layer choice because each authorized IP is enumerated explicitly with no further DNS resolution required at the receiver, structurally parallel to the DKIM-Signature application-layer self-containment THIS page documents (the signature blob is the cryptographic proof the message author held the private key, requiring only the s= + d= TXT-record lookup); (ii) include:other. example — delegated authorization to a third-party SaaS sender, recursively expands the included domain's SPF record (counting against the RFC 7208 §4.6.4 ten-lookup budget) and is the HIGHEST-DELEGATION-RISK envelope- layer choice because the operator transitively trusts whatever IPs the included SaaS publishes — a SaaS- sender envelope-IP-set compromise produces spoofed messages envelope-layer-indistinguishable from legitimate vendor traffic, leaving DKIM application-layer signature verification as the independent second factor that catches the spoof when the SaaS platform's d= attribution is correctly per-tenant- isolated per the SaaS-senders spoke already cross-referenced from this page; (iii) a:<name> and bare a — name-based IP authorization via A/AAAA-record lookup, couples envelope-layer authorization to the dynamics of A/AAAA records (which may legitimately renumber without the operator updating the SPF record), structurally parallel to the DKIM application-layer DNS- coupling THIS page documents (the selector._domainkey.<d=> TXT-record lookup is the cryptographic-key-publication dependency whose dynamics this page's s= + d= tag-anatomy section treats); (iv) mx:<name> and bare mx — MX-server- based IP authorization via MX + A/AAAA-record lookup, couples envelope-layer authorization to the inbound MX topology (counts as ONE include- budget hit plus N A/AAAA lookups per resolved MX target) and is operationally distinct from DKIM application-layer verification THIS page documents in that DKIM- Signature verification has NO dependency on MX topology (the verifier never consults MX records at signature-verification time). Read the four-IP-providing-mechanism decision-tree spoke alongside THIS DKIM-Signature header tag-anatomy deep dive when the operator faces the upstream architecture question of "which SPF IP-providing mechanism do we author for this sending domain" PRIOR to (or in parallel with) the per-message DKIM-signing decisions THIS page covers, so the ENVELOPE-LAYER IP-authorization decision and the APPLICATION-LAYER signature decision compose into the DMARC alignment verdict that the receiver ultimately renders.
• DKIM DNS record syntax — the DKIM-HEADER-S-TAG-AND-D-TAG-RESOLVE- TO-DNS-SELECTOR-RECORD-BYTE-SYNTAX companion to this DKIM-Signature header tag-anatomy deep dive. Where THIS page documents the per-message DKIM-Signature HEADER tag anatomy (the v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tags the sender stamps INTO the outgoing message), the DKIM DNS-record- syntax spoke is the DNS-LAYER companion documenting the byte-syntax of the TXT record the s= + d= tags POINT TO. The DKIM-HEADER-S-TAG-AND-D-TAG-RESOLVE-TO- DNS-SELECTOR-RECORD-BYTE-SYNTAX cross- reference establishes four specific header-to-DNS-record resolution mappings: (i) s= tag value → selector component of the DNS query name — the s= value (e.g. s=k1 or s=selector1) is the FIRST label of the selector._domainkey.<domain> DNS name the receiver constructs; THIS page's s= tag-anatomy section explains the SENDER-side encoding; the byte- syntax spoke documents the RECEIVER-side DNS lookup the value triggers; (ii) d= tag value → domain component of the DNS query name — the d= value (e.g. d=example.com) is the DOMAIN label of the selector._domainkey.<domain> DNS name; THIS page's d= tag-anatomy section explains why d= matters for DMARC alignment; the byte-syntax spoke documents the published TXT-record-at- d= byte format the receiver fetches; (iii) a= tag value in the header → k= + h= tag values in the DNS record — when the header carries a=rsa-sha256, the receiver verifies that the published TXT record's k= = rsa AND h= permits sha256; THIS page's a= tag-anatomy section is the SENDER-stated algorithm; the byte-syntax spoke is the RECEIVER- published algorithm constraint set the a= value must satisfy; (iv) b= signature value in the header → verified against the p= public key in the DNS record — the cryptographic verification reads the b= BASE64-encoded signature blob from the header, computes the body+header hash per c= canonicalisation, and verifies against the public key published in the p= tag of the TXT record; THIS page documents the SENDER- side signature-creation; the byte- syntax spoke documents the DNS- published public-key byte format the verification consumes. Read THIS page for the per-message HEADER tag anatomy the sender stamps; read the DKIM DNS- record-syntax spoke for the DNS-LEVEL TXT record byte-format the s= and d= tags POINT TO at receiver-side verification time.
• MX records explained — the per-domain apex MX-RR publication- discipline IS the LOAD-BEARING UPSTREAM mail- routing primitive whose per-receiver per-domain MX-RR resolution precedes the per-message DKIM-Signature header verification THIS page documents at four per-domain MX-RR-publication- discipline-vs-DKIM-verification coupling dimensions: (i) per-domain apex MX-RR priority-and-hostname publication (e.g., example.com. MX 10 mx1.example.com. + example.com. MX 20 mx2.example.com.) is the per-publisher per-domain DNS-RR-class primitive that EVERY sending MTA consults via RFC 5321 §5.1 MX-priority-ordered resolution BEFORE establishing the SMTP session that carries the per-message envelope whose DKIM-Signature header THIS page documents — no per-domain MX-RR publication, no per-message DKIM-verification-event at the per-receiving-MX verifier; (ii) per-domain MX-RR resolution and DKIM-DNS-syntax (`<selector>._domainkey.<domain>` TXT-RR) resolution are sibling per-domain DNS-RR-class lookups at structurally PARALLEL receiver-side mail-flow stages — MX-RR at envelope-routing-time at the SENDING MTA, DKIM-TXT-RR at signature-verification-time at the RECEIVING MTA — both per-domain publisher publication-discipline primitives the receiver consumes during the per-message authentication pipeline; (iii) per-domain MX-RR publication discipline is load-bearing upstream of per-receiving-MX TLS-fingerprint observability: the per-domain MX-RR hostname is the FQDN the per-receiving-MX presents at SMTP-EHLO + the per-receiving-MX TLS certificate SAN must match for MTA-STS-mode-enforce STARTTLS-fail-closed + the per-receiving-MX is the per-day per-MX- host TLS-RPT JSON-aggregate attribution row's receiving-mx field value; (iv) per-domain MX-RR publication discipline is the per-publisher per-domain receiver-identification anchor that pivots into the per-receiving-MX FCrDNS / PTR identity-corroboration the DKIM signer's receiver-side debugger consumes when triaging per-receiver per-message DKIM-verify- result drift (per-receiving-MX hostname → per-receiving-MX IP via A/AAAA lookup → reverse PTR-RR per-IP identity-corroboration); read THIS page for the per-message DKIM-Signature header tag-anatomy; read the MX-records spoke for the per-domain apex MX-RR publication- discipline whose per-receiving-MX resolution precedes EVERY per-message DKIM-verification- event the per-tag anatomy this page documents produces verdicts at.
• DKIM canonicalization — the c= tag deep dive. simple-vs-relaxed semantics byte-by-byte.
• DKIM selectors explained — the s= tag deep dive. Cross-provider naming catalogue.
• DKIM key rotation — rotation operational discipline. How signers change s= over time without breaking in-flight messages.
• DKIM replay attacks — the threat model behind why l= is dangerous and why t= exists.
• How attackers bypass DMARC — the DKIM-SIGNATURE-HEADER-BYTE-LEVEL- ANATOMY-AS-PER-TAG-BYPASS-VECTOR-SURFACE companion to this RFC 6376 §3.5 DKIM-Signature header tag-anatomy reference. Where THIS page documents the byte-level semantics of every tag the verifier reads (v= protocol version, a= signing algorithm, b= signature value, bh= body hash, c= canonicalization, d= signing domain, h= signed header list, i= identity, l= body length, q= query method, s= selector, t= timestamp, x= expiration), the attacker-bypass spoke documents the STRUCTURED 22-TECHNIQUE BYPASS CATALOGUE in which the authentication-evasion class enumerates the SEVEN structurally-distinct per-DKIM-Signature-tag exploit paths a sophisticated attacker can use to construct a forged-or-replayed signature that passes cryptographic verification while delivering an attacker-controlled message: (i) the l= body-length tag enabling body-extension after legitimate signing (attacker appends attacker-controlled MIME parts beyond the signed byte-prefix; the legitimate signature still validates because the body-hash covered only the byte-prefix the original sender authored — DKIM-replay- attack family member catalogued in the dkim_replay_attacks spoke above); (ii) the h= header-list under-coverage enabling header-injection of unsigned attacker-controlled headers like a forged From: when only To: is signed (the legitimate signature still validates because the per-tag header-list explicitly bounded the cryptographic commitment to the signer-chosen header subset); (iii) the x= expiration tag MISSING from the signature meaning the signature never expires and an attacker can replay a captured legitimate signature indefinitely (the mitigation: best-practice deployments publish x= with a bounded expiration window per the dkim_best_practices spoke); (iv) the s= selector squatting against a previously-deprovisioned selector name where an attacker who controls the d=-domain's DNS can publish a new public key under the stale selector and emit signed messages that validate against the squatted selector (the mitigation: defense-in-depth requires d=-domain DNS access-control isolation and selector-name rotation discipline); (v) d= cousin-domain signing where an attacker registers a typosquat domain similar to the victim's signing domain and emits legitimately-signed messages under the cousin domain that pass DKIM but FAIL DMARC alignment unless the receiver-side homoglyph/typosquat detection layer is deployed; (vi) a= algorithm downgrade to rsa-sha1 (RFC 6376 §3.3 still permits rsa-sha1 SHOULD-NOT but receivers may still verify — the mitigation: receivers SHOULD treat rsa-sha1 as no signature per modern best practice); (vii) b= signature reuse across messages by extracting a legitimate b= value and substituting attacker-controlled bytes — the cryptographic verification fails so this is a NEGATIVE control demonstrating the b= tag IS load-bearing against the per-message-body-substitution exploit class. Read the attacker-bypass spoke when constructing the DKIM-deployment threat model — the spoke's authentication-evasion class maps each per-DKIM-Signature-tag exploit path onto a concrete threat-actor TTP (T1556 modify-authentication-process, T1078 valid-accounts compromise of the DKIM signing key, T1583.001 acquire-infrastructure domain registration for cousin-domain attacks) so the defender knows which per-tag mitigation (publish x= bounded expiration; enforce h= minimum signed-header set covering From:/To:/Subject:/Date:/Message-ID:; prohibit l= in outbound signing; rotate s= selectors on a published cadence; restrict a= to rsa-sha256 or ed25519 only) closes the corresponding exploit path.
• Phishing protection (defense-in-depth catalogue) — the DKIM-SIGNATURE-CRYPTOGRAPHIC-INTEGRITY- AS-PHISHING-PAYLOAD-MODIFICATION-DETECTION- CONTROL companion to this RFC 6376 §3.5 DKIM-Signature header tag-anatomy reference. Where THIS page documents the per-tag byte- level semantics of every cryptographic commitment the verifier evaluates (b= signature, bh= body hash, h= signed-header set, c= canonicalization, d= signing-domain identity), the phishing-protection spoke documents the LAYERED DEFENSE-IN-DEPTH CONTROL CATALOGUE in which the DKIM-Signature cryptographic-integrity verification is the AUTHENTICATION-LAYER LOAD-BEARING CONTROL that detects phishing-payload- modification attempts. FIVE structurally- distinct DKIM-SIGNATURE-VS-PHISHING- CONTROL operational classes the spoke catalogues that THIS per-tag reference intentionally elides: (i) per- message body-content modification detection via bh= body-hash cryptographic commitment — the phishing-payload-modification class attacker (T1566.002 spearphishing-link- injection, T1204.001 user-execution-via- malicious-link) cannot modify the signed body bytes without invalidating the bh= body-hash, so the receiver-side bh= verification documented on THIS page is the cryptographic detection-of-record for attacker-injected URL substitution and malicious-attachment swap-in; (ii) per-message header-content modification detection via h= signed-header-set cryptographic commitment — the phishing- attacker cannot modify a signed From: / Subject: / Reply-To: header without invalidating the b= signature, so the receiver-side h=- anchored signature-verification this page documents detects header-spoofing of-record; (iii) per-message signing-domain identity attestation via d= tag plus DKIM-DMARC- alignment — the phishing- attacker can publish a DKIM key under their own attacker-controlled domain but cannot construct a d= tag for the victim's signing domain without possessing the victim's signing key, so the d= tag this page documents IS the signing-domain identity assertion that DMARC alignment then cross-validates against the Header-From:; (iv) per-message replay-attack- window bounding via x= expiration tag plus t= timestamp tag — phishing attackers who capture a legitimate- message DKIM-signed envelope cannot replay it indefinitely if the original signer published a bounded x= expiration, so the x= and t= tags this page documents ARE the temporal-replay-window- constraint phishing-defense control; (v) per-deployment cousin- domain look-alike-sender detection via DKIM-d=-VS-Header-From-strict-alignment — phishing attackers register typosquat domains similar to the victim's signing domain to harvest user-trust signals, so the d= tag this page documents PAIRED with strict DMARC alignment (adkim=s) IS the cousin-domain-impersonation detection control. Read the phishing- protection spoke alongside this per-tag signature reference when constructing the security-team's phishing-defense threat-model — the spoke maps each DKIM-Signature tag onto the concrete phishing-TTP class (T1566 phishing, T1566.001 spearphishing-attachment, T1566.002 spearphishing-link, T1566.003 spearphishing-via-service) the per-tag cryptographic commitment defends against.
• DKIM cryptography basics — RSA-SHA256, Ed25519, 2048-bit key sizes, public-key verification chain. Understanding the crypto explains the structure of b= and bh=.
• DKIM best practices — the production-defaults sibling for the tags this page documents. Once you know what every tag MEANS, the best-practices page tells you what VALUE each tag SHOULD have in a modern deployment: v=1 (only valid value), a=rsa-sha256 or a=ed25519-sha256 (RFC 8301 deprecates rsa-sha1; RFC 8463 adds Ed25519), c=relaxed/relaxed (survives most forwarder body-mangling), no l= tag (length-limited signatures are trivially body-extended after capture), the RFC 9103 x= expiration tag for bounded replay windows, and the selector-naming + dual-selector rotation conventions that govern s= over time. Read once you understand the tag-by-tag anatomy on this page and need the production-defaults consolidated view rather than per-topic deep dives.
• DKIM failures explained — the receiver-side verdict catalogue. THIS page documents what the signer emits; the failures page documents what the verifier outputs.
• DKIM troubleshooting — the SIGNATURE-HEADER-ANATOMY-TROUBLESHOOTING-INPUT companion to this DKIM-Signature byte-level field reference. Where THIS page documents WHAT each tag in the RFC 6376 §3.5 DKIM-Signature header MEANS structurally (the v= version tag, the a= algorithm (rsa-sha256 / ed25519-sha256), the c= canonicalization (simple/simple / relaxed/relaxed / relaxed/simple), the d= signing domain, the s= selector, the h= signed-header list, the bh= body hash, the b= signature blob, the t=/x= timestamp + expiry pair, the optional i= AUID, the optional l= body length limit, the optional q= query method), the troubleshooting spoke documents the OPERATOR DIAGNOSIS PATH for translating a captured-but-failing DKIM-Signature header into a concrete remediation: per-tag misconfiguration signature (v=-other-than-1 → signer-software-defect, a=rsa-sha1 → RFC 8301 deprecation, mismatched d= vs From:-domain → DKIM-alignment-rather-than-DKIM- failure misdiagnosis, missing s=-record-at-DNS → selector-not-published or propagation-pending, h=-omits-Subject → attacker-replay-replay-prevention defeat, bh=-mismatch + c=simple → downstream-transit-modification (mailing-list, archive-scrubber, legal-disclaimer-injector), b=-verification-fail- with-bh=-pass → signed-header-modification-in- transit, t=+x= expired → clock-skew-or-replay- suppression). The troubleshooting spoke also documents the per-receiver verdict translation (Gmail's dkim=fail reason codes, Microsoft 365's Authentication-Results header reason= field semantics, Yahoo's dkim=neutral vs dkim=temperror distinction), the dig _domainkey.<selector>.<domain> TXT DNS verification 1-liner every operator runs against an observed-failing DKIM-Signature header, and the canonical per-signer-platform remediation catalogue (Workspace google._domainkey, M365 selector1._domainkey / selector2._domainkey, SendGrid s1._domainkey / s2._domainkey, cPanel default._domainkey). Read the troubleshooting spoke when this page's byte-level reference identifies a STRUCTURALLY-MALFORMED or VERIFICATION-FAILING DKIM-Signature header in an observed message — the spoke is the load-bearing translator from "I can decode the signature header" to "I can fix the underlying misconfiguration".
• DKIM for Microsoft 365 — provider-specific deployment guide. The dual-selector CNAME-delegated model in tag terms: d=<your-domain> + s=selector1 or s=selector2 per the Defender portal CNAME publication.
• DMARC for Microsoft 365 — the M365-TENANT-DKIM-SIGNATURE-AS- UPSTREAM-INPUT-TO-M365-TENANT-DMARC- VERDICT companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the per-message DKIM- Signature header byte-by-byte grammar the M365 Exchange Online Protection outbound signing stack produces under the selector1._domainkey.<tenant>.onmicrosoft.com and selector2._domainkey.<tenant>.onmicrosoft.com CNAME-delegated key-publication topology (the v=1; a=rsa-sha256; c=relaxed/relaxed; d=<tenant-domain>; s=selector1|selector2; h=From:To:Subject:Date; bh=<base64-body-hash>; b=<base64-signature> wire format), the DMARC-for-M365 spoke documents the per-tenant DMARC TXT publication discipline at four per-tenant-DKIM-publication-to-DMARC- evaluation-coupling dimensions: (i) per-tenant DKIM-aligned-pass at relaxed-via-PSL-orgdomain alignment as the load-bearing M365 outbound-mail compliance path — the per-message DKIM d=<tenant-domain> tag THIS page documents must align with the RFC 5322 From: author-domain for the M365-tenant DMARC verdict to register a policy_evaluated.dkim=pass row, and the CNAME-delegated key infra guarantees the d= tag carries the protected tenant domain (not the <tenant>.onmicrosoft.com substrate) IF the operator has published both selector CNAMEs and toggled DKIM-signing ON via the Defender portal or Set-DkimSigningConfig cmdlet; (ii) per-tenant selector1/selector2 key-rotation discipline as DMARC-aligned-pass- stability input — Microsoft rotates the per-tenant CNAME-targeted keys on a quarterly cadence at Microsoft's tenancy infrastructure side, and the per-tenant DMARC RUA operator must observe per-selector DKIM-aligned-pass continuity across the rotation boundary in the aggregate-report row stream this DKIM-Signature wire-format's downstream verdict produces; (iii) per- tenant DMARC policy advancement gate as DKIM-aligned-pass-rate-driven — the canonical M365-tenant DMARC rollout ramp from p=none → p=quarantine → p=reject is gated on a per-author-domain DKIM-aligned-pass- rate baseline (≥99% for legitimate mail) observed in the RUA-aggregate- report row stream the per-message DKIM-Signature wire-format THIS page documents produces; (iv) per- tenant DKIM-OR-SPF-aligned-pass disjunction as per-message-DKIM- signature-as-sole-surviving-leg-when- SPF-breaks — when M365 outbound traverses a forwarder that breaks SPF at the second hop, the per-message DKIM-Signature wire-format THIS page documents is the SOLE surviving alignment leg the M365- tenant DMARC verdict honours; the DMARC-for-M365 spoke documents the operational discipline that ensures per-message DKIM survives forwarder body-rewrites between EOP egress and the receiver-side alignment evaluation. Read the DMARC-for-M365 spoke immediately after this DKIM-Signature wire-format reference when the operator's M365-tenant DMARC compliance program needs to trace the per-message DKIM-Signature header bytes THIS page documents through the CNAME-delegated key-publication topology to the per-tenant DMARC verdict the receiver- side observes.
• DKIM for Google Workspace — provider-specific deployment guide. The single-selector TXT-publication model in tag terms: d=<your-domain> + s=google.
• DMARC alignment — the alignment-evaluation rules that translate d= into DMARC outcomes.
• DMARC myths and misconceptions — the DKIM-SIGNATURE-CRYPTOGRAPHIC- SEMANTICS-AS-CANONICAL-REFUTATION-OF- DMARC-ENCRYPTS-EMAIL-MYTH companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the DKIM-Signature header byte-by-byte (the v=1 / a=rsa-sha256 / c=relaxed/relaxed / d=signing-domain / s=selector / h=signed-header-set / bh=body-hash / b=signature / l=body-length / t=signing-timestamp / x=expiration-timestamp / i=signing-identity tag anatomy with full RFC 6376 semantic attribution per tag), the DMARC-myths-and-misconceptions spoke is the OPERATOR-MENTAL-MODEL-CORRECTION catalogue cataloguing the 18 distinct misconceptions about DMARC that recur in operator rollout-blocker decision-making, FOUR of which directly engage with the DKIM-Signature cryptographic-semantic mechanics THIS page documents and which this DKIM pillar is the canonical refutation- source for: (i) Myth 2 ("DMARC encrypts email") — the canonical encryption-vs-authentication- confusion myth, refuted at the protocol-semantic level by the DKIM- Signature header's cryptographic purpose: DKIM is a DIGITAL-SIGNATURE mechanism producing a tamper-evident proof of message integrity over the signed-header-set h= and body-hash bh=, NOT an encryption mechanism — the signed bytes remain in plaintext throughout transport, with SMTP-layer encryption a SEPARATE TLS-handshake concern documented in the MTA-STS / TLS-RPT cluster (and DMARC is itself just an alignment-and-policy- evaluation layer built ATOP DKIM and SPF, adding NO encryption mechanism of its own); (ii) the implicit "DKIM is encryption" confusion — refuted by THIS page's b= tag semantic-attribution section: the b= tag contains a BASE64-ENCODED RSA-SHA256 SIGNATURE over the canonicalised header set and body hash, NOT a base64-encoded encrypted version of any message content (the message remains plaintext; only the cryptographic signature attesting message integrity is base64-encoded); (iii) the "DKIM-Signature header is the encrypted body" confusion — refuted by THIS page's body-hash bh= tag section: the body-hash is a SHA256-of-the-canonicalised-body DIGEST, a one-way fingerprint that proves the body has not been modified in transit, NOT an encrypted representation that can be decrypted back to the original body bytes (a digest is one-way; encryption is reversible — they are mathematically distinct cryptographic primitives); (iv) the "b= tag is the encrypted message content" confusion — refuted by THIS page's l= body-length tag section: the optional l=<N> tag specifies how many leading bytes of the body are covered by the bh= body-hash, which would be a nonsensical concept if b= were encrypted body content (you'd encrypt the WHOLE body, not the leading N bytes). Read the myths catalogue alongside this DKIM signature reference when designing operator-facing rollout documentation that must overcome the "I thought DMARC was end-to-end encryption" objection operators raise when explaining DMARC's actual cryptographic-authentication-and- alignment scope to stakeholders unfamiliar with the message-authentication-vs-encryption distinction — the myths catalogue is the canonical misconception- correction substrate; this DKIM signature reference is the canonical protocol-semantic refutation source.
• DMARC for cPanel — the cPanel-tenant DMARC deployment guide (the DKIM-COMPANION-MECHANISM-FOR-CPANEL-TENANT companion to this DKIM signature reference) — the DKIM-COMPANION-MECHANISM-FOR-CPANEL-TENANT companion documenting the cPanel-tenant DMARC deployment workflow whose Phase 2 DKIM-alignment prerequisite consumes the DKIM signature mechanics documented on THIS page. Where THIS page is the DKIM-Signature header tag-by-tag reference (the v= / a= / c= / d= / s= / h= / bh= / b= / l= / q= / t= / x= / i= / z= tags), the dmarc_for_cpanel spoke is the CPANEL-TENANT DEPLOYMENT REFERENCE that documents how those signature mechanics translate to cPanel's OpenDKIM operational surface. The cPanel-tenant DKIM deployment has FIVE distinct DKIM-mechanic adaptations vs the M365/GW tenant-tier deployments the cross-reference makes explicit: (i) cPanel uses OpenDKIM with manually-managed keys — unlike M365's CNAME-delegated s=selector1 / s=selector2 model OR Google Workspace's s=google model where the provider hosts the public key, cPanel tenants generate RSA key pairs in OpenDKIM's /etc/opendkim/keys/<domain>/ directory and publish the public key as a TXT record under <selector>._domainkey.<domain> via cPanel Zone Editor; (ii) cPanel operator-empowerment ceiling on per-domain DKIM signing — many shared-hosting cPanel platforms do NOT support per-tenant custom-domain DKIM signing in the platform's default Exim/OpenDKIM configuration, meaning the operator must request platform-level OpenDKIM activation or accept that outbound mail signs with the PROVIDER's d= domain rather than the customer's; (iii) cPanel's default 1024-bit RSA key size is below current best-practice — cPanel's default DKIM signing-key generation produces RSA-1024 keys, but DKIM-replay attack research and Gmail/Yahoo sender-requirements recommend RSA-2048 minimum; cPanel operators must manually regenerate at 2048-bit via the WHM Manage DKIM Keys UI; (iv) cPanel + third-party-ESP relay DKIM signing — when a cPanel tenant uses SendGrid / Mailgun / SES, outbound mail through the ESP gets re-signed with the ESP's DKIM key (which may be CNAME-delegated under the customer's domain) rather than cPanel's OpenDKIM key, so two d=-aligned-identity paths coexist; (v) cPanel key-rotation is a manual WHM operation — unlike M365's Rotate-DkimSigningConfig PowerShell cmdlet OR Google Workspace's automated key-rotation, cPanel operators rotate DKIM keys via the WHM Manage DKIM Keys "Generate New Key" workflow, which means cPanel-tenant DKIM-rotation cadence depends on operator discipline rather than platform automation. Read the cPanel deployment spoke when the cPanel-tenant operator is in the Phase 2 DKIM-prerequisite-validation step of the DMARC deployment workflow.
• DMARC for shared hosting documenting the shared-hosting-tenant (cPanel / Plesk / DirectAdmin / non-cPanel multi-tenant control-panel) per-vanity-domain DMARC deployment workflow whose per-account DMARC TXT-RR publication at _dmarc.<vanity-domain> structurally consumes the per-message DKIM-Signature header d=<vanity-domain> identifier THIS page's RFC 6376 §3.5 tag-list byte-grammar reference produces at every shared-hosting per-account message-emission event — the shared-hosting topology is STRUCTURALLY DISTINCT from the cPanel-specific spoke (which assumes the cPanel control-panel UI and Exim MTA), covering the generalised per-account vanity-domain publication discipline across all shared-hosting control-panel families. Four per-shared-hosting-tenant DKIM-Signature-vs-DMARC-publication coupling dimensions: (i) the per-account per-vanity-domain default._domainkey.<vanity-domain> DKIM TXT-RR publication-discipline (typically auto-provisioned by the shared-hosting control-panel's DKIM-key-management plugin) is the load-bearing upstream of the per-message DKIM-Signature header d=-tag this page documents the byte-grammar of; without the per-account vanity-domain TXT-RR publication, every per-message DKIM-Signature header emitted by the shared-hosting MTA's per-account signing pipeline produces dkim=permerror at the receiver per RFC 6376 §6.1.2 receiver-side public-key-lookup failure-mode classification. (ii) The per-shared-hosting-tenant per-vanity-domain DMARC TXT-RR publication at _dmarc.<vanity-domain> with adkim=r/adkim=s alignment-mode tag governs whether the receiver-side DKIM-Signature d=-tag identifier this page documents the byte-grammar of is considered ALIGNED with the From:-header RFC 5322.From organizational domain at the per-receiver-side DMARC evaluator boundary — the shared-hosting-tenant operator who publishes v=DMARC1; p=quarantine; adkim=s at _dmarc.<vanity-domain> bounds the per-message DKIM-Signature d=-tag identifier publication-discipline to STRICT organizational-domain match per RFC 7489 §3.1.1, whereas adkim=r relaxes the receiver-side per-organizational-domain match policy to per-subdomain match. (iii) The per-shared-hosting-tenant per-vanity-domain DMARC rua=mailto: aggregate-report observability channel surfaces per-tenant per-vanity-domain DKIM-Signature d=-tag-identifier-vs-From:-header-organizational-domain alignment-pass-rate-vs-fail-rate ratios as the operator-side observability primitive driving the per-tenant per-vanity-domain DKIM key rotation cadence and p=none→p=quarantine→p=reject enforcement-ramp cadence the shared-hosting-tenant operator schedules — the per-message DKIM-Signature header tag-grammar THIS page documents is the load-bearing per-message observability primitive whose receiver- side per-aggregate-report attribution the shared-hosting DMARC deployment operator depends on for the per-vanity- domain enforcement-ramp scheduling decision. (iv) The per-shared-hosting- tenant cross-vanity-domain DKIM-key- provisioning discipline (one default._domainkey.<vanity-domain> DKIM TXT-RR keypair per per-account vanity-domain, NOT one global shared-hosting-MTA-wide signing key) is the structural precondition for the per-vanity-domain DMARC adkim=-evaluation per-account alignment-attribution evidence chain at the per-receiver-side DMARC evaluator boundary — the shared-hosting deployment topology this spoke documents the per-account per-vanity-domain DKIM-publication discipline of is the structurally distinct generalisation of the cPanel-specific spoke at the per-shared-hosting-control-panel-family DMARC publication-and-DKIM-signing coordination boundary the per-message DKIM-Signature header tag-anatomy THIS page documents the wire-format of depends on.
• DKIM alignment with DMARC — the DKIM-specific deep dive on the d=-tag-to-From:-header alignment evaluation that this tag-by-tag page introduces but does not exhaustively cover. Where the sibling help_dmarc_alignment.php page documents the alignment-evaluation rules for the FULL DMARC pipeline (SPF + DKIM in parallel), the dedicated DKIM-alignment-with-DMARC page focuses narrowly on the DKIM half: how the d= value in this DKIM-Signature header gets compared against the From: header domain, the adkim=r (relaxed: organisational-domain match, e.g. d=mail.example.com aligns with From: example.com) vs adkim=s (strict: byte- identical match required) DMARC policy knob, the canonical dkim=pass-but-DMARC-fail patterns each mode produces (Microsoft 365's d=<tenant>.onmicrosoft.com gotcha, Google Workspace's d=<domain>.gappssmtp.com gotcha, SendGrid-style ESP shared signing-domain patterns), and the mitigation sequence (publish CNAME- delegated or hosted-domain DKIM that signs with d=<your-domain> instead of the ESP's shared signing domain). Read this page first to understand WHAT the d= tag means at the signing layer, then jump here to learn HOW receivers evaluate that d= value against DMARC's identifier-alignment rules — and why a structurally-valid DKIM signature can still cause dmarc=fail when the d= value and the From: domain do not share an organisational suffix.
• ARC explained — the Authenticated Received Chain. The protocol-level fix for forwarder-induced bh= mismatches.
• Reverse DNS PTR records and FCrDNS — the DKIM-SIGNER-IP-IDENTITY-VIA-PTR- LOOKUP forensic-investigation companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the DKIM-Signature header tag wire-format (v=1; a=rsa-sha256; d=<domain>; s=<selector>; c=relaxed/relaxed; h=From:To:Subject:Date; bh=<base64-body- hash>; b=<base64-sig> at RFC 6376 §3.5 + §3.6 byte precision) the SIGNING-MTA stamps into outgoing messages, the reverse-DNS-PTR spoke is the SIGNING-IP-TO-SIGNER-ORGANIZATION resolution reference that the receiver-side DKIM- verification debugger uses when the tag- anatomy alone is insufficient to determine WHICH organization actually signed the message. The DKIM-SIGNATURE-HEADER- FORENSIC-INVESTIGATION-REQUIRES-SIGNER-IP- IDENTITY cross-reference establishes FOUR structurally-distinct DKIM-debugging dimensions where PTR resolution is the load-bearing pivot: (i) i= AUID-resolution- to-signing-infrastructure — RFC 6376 §3.5 permits the i= AUID to be a strict-subdomain of d= (e.g., d=example.com; i=@bounces. marketing.example.com); when receivers debug dkim=fail for AUID-vs-d= disputes (or AUID-vs-From-header-domain disputes), the canonical investigation pivot is "which IP signed this message?" — the signing-IP from the SMTP receive-chain (Received: from <ehlo-name> (<ptr> [<ip>]) header) pivots through PTR to the signing-organization identity, which the debugger compares against the AUID-declared sub-identity to identify legitimate-subdomain-signing vs cohabitant-tenant-signing vs attacker- injected-AUID scenarios; (ii) multi-signer DKIM chain per- signer IP attribution — RFC 6376 §3.5 permits multiple DKIM-Signature headers per message (a publisher signing with their own d= + an intermediary signing with theirs); receiver-side debugging of multi-signer messages requires per-signer IP attribution to determine which signer signed at which hop — the per-Received:- header IP-stack walked through PTR yields the per-hop organizational-identity sequence the multi-signer DKIM verification path must reconcile against the d= domains declared in each DKIM-Signature header; (iii) DKIM-Signature b= byte forensics for replay-attack investigation — DKIM replay attacks re-emit a captured message with its valid DKIM-Signature header intact but from a different (attacker-controlled) IP than the original signer; receiver-side replay detection requires correlating the b= byte signature (cryptographically valid) with the currently-receiving IP (attacker-controlled, not the original publisher's egress IP) — PTR resolution of the currently-receiving IP yields the organizational-identity that the receiver compares against the d=-declared signing-domain's canonical egress-IP-organization to detect the replay (publisher's IP-organization consistent across messages; attacker's PTR resolves to a different organization despite the same b= bytes verifying as valid); (iv) tenant DKIM key custody attribution at multi-tenant signing boundary — multi-tenant signing platforms (M365 EOP, Google Workspace, SendGrid, Mailgun) sign messages on behalf of many customer tenants from shared egress IPs; receiver-side debugging of "which tenant's key signed this message" requires PTR resolution of the signing-IP to confirm the signing-PLATFORM identity matches the DKIM-Signature header's d= declared domain (M365 outbound IPs PTR- resolve to protection.outlook.com; SendGrid outbound IPs PTR-resolve to sendgrid.net; mismatches between PTR-derived platform identity and d=-declared tenant domain surface as DKIM-tenant-key-custody-defect candidates). Read the reverse-DNS-PTR spoke when the DKIM-Signature header tag-anatomy alone is insufficient to identify WHICH organization actually signed the message — the PTR-resolution pivot is the canonical next step in the forensic investigation decision tree at all four dimensions above.
• MTA-STS policy file syntax (byte-level reference) — the orthogonal-trust-models companion byte-syntax reference. Where THIS page documents the message-layer byte-syntax of the DKIM-Signature: header that rides INSIDE the TLS-encrypted SMTP session (verifying the message content has not been tampered with after signing), the MTA-STS-policy-syntax spoke documents the transport-layer byte-syntax of the mta-sts.<domain>/.well-known/mta-sts.txt HTTPS-served policy file that authenticates the TLS session itself (verifying the receiving MX presented a certificate matching a hostname enumerated in the policy's mx: directive). The two protocols defend different attack surfaces: a message can pass MTA-STS transport-layer verification and still fail DKIM message- layer verification if a content-modifying gateway breaks the body hash or canonicalisation post-signing; conversely, a message can pass DKIM and still arrive over an unencrypted session if the receiving domain has no MTA-STS policy or publishes mode: none. Read this when designing a message-vs-transport authentication matrix for inbound and outbound mail flow.
• TLS-RPT record syntax — the per-publisher per-policy-domain TRANSPORT-LAYER-REPORTING-RECORD-BYTE- GRAMMAR-PUBLICATION-DISCIPLINE-AS-PEER- PUBLICATION-DISCIPLINE-COUSIN companion to this RFC 6376 §3.5 DKIM-Signature header tag-anatomy reference. Where THIS page documents the per-message DKIM-Signature header tag-by-tag byte-grammar (v= protocol version, a= signing algorithm, b= signature value, bh= body hash, c= canonicalization, d= signing domain, h= signed header list, s= selector, t= timestamp, x= expiration) at the application-layer per-message DKIM-Signature header publication-discipline tier, the TLS-RPT-record-syntax spoke documents the per-publisher per-policy-domain _smtp._tls.<d> TXT-RR byte-grammar (the v=TLSRPTv1 version tag, the rua=mailto: reporting-URI list, the optional rua=https:// HTTPS-collection- endpoint authorization, and the optional URI-list comma-separation grammar) at the transport-layer reporting-record byte- grammar publication-discipline tier. Three BYTE-GRAMMAR-PUBLICATION-DISCIPLINE coupling dimensions the TLS-RPT-record-syntax spoke documents the per-publisher per-domain operator MUST AUTHOR alongside the per- message DKIM-Signature header tag-grammar THIS page documents: (i) per- publisher per-domain tagged-key-value-list byte-grammar publication-discipline parallel at distinct protocol layers — both the per-message per-signer DKIM- Signature header tag-list THIS page documents (semicolon-separated tag=value pairs per RFC 6376 §3.5) and the per-publisher per-policy- domain TLS-RPT TXT-RR tag-list the spoke documents (semicolon-separated tag=value pairs per RFC 8460 §3) are tagged-key-value-list byte-grammar publication primitives at distinct protocol layers (per-message application-layer message-integrity-and-authenticity vs per- publisher per-policy-domain transport-layer TLS-failure-reporting) with the SAME semicolon-separated tag=value list-syntax discipline operators familiar with DKIM-Signature tag-list authoring can transfer directly to TLS-RPT TXT-RR authoring; (ii) per-publisher per- domain version-tag publication-discipline parallel at distinct protocol layers — both the per-message v=1 DKIM-Signature protocol-version tag THIS page documents (committing the per-message DKIM-Signature to the RFC 6376 protocol version) and the per-publisher per-policy- domain v=TLSRPTv1 TLS-RPT protocol-version tag the spoke documents (committing the per-publisher per-policy- domain TLS-RPT record to the RFC 8460 protocol version) are per-publisher per- domain version-anchor publication primitives operators MUST publish first-in-tag-list across both protocols; (iii) per- publisher per-domain URI-list publication- discipline parallel at distinct verdict- stream attribution tiers — both the per-message h= signed- header-list publication discipline THIS page documents (the colon-separated list of per-message header names the per- signature byte-coverage commits to) and the per-publisher per-policy-domain rua= reporting-URI-list publication discipline the spoke documents (the comma-separated list of mailto: + https:// URIs the per-publisher per-policy-domain TLS-RPT aggregate-report publication commits to) are per-publisher per-domain delimiter-separated-list byte-grammar publication primitives at distinct verdict-stream attribution tiers operators MUST author with delimiter-specific attention. Read the TLS-RPT-record-syntax spoke ALONGSIDE this DKIM-Signature header reference whenever the per-publisher per- domain operator AUTHORS the per-publisher per-domain underscore-prefixed-TXT-RR publication portfolio at the per-domain application-layer-plus-transport-layer byte-grammar-publication-discipline boundary.
• SPF PermError vs TempError — the LOAD-BEARING per-publisher per-domain SPF-VERIFICATION-TIME- DNS-RESOLVER-FAILURE-MODE-PEER-OF- DKIM-VERIFICATION-TIME-DNS-RESOLVER- FAILURE-MODE companion documenting the SPF-side spf=permerror / spf=temperror verdict family the RFC 7208 §4 / §8.5 evaluation algorithm produces when the per-publisher per-domain SPF-record lookup encounters the RFC 7208 §4.6.4 ten-DNS-lookup-limit exhaustion (PermError) or per-publisher per- domain authoritative-DNS-server transient unreachability (TempError) — the STRUCTURAL VERIFICATION-TIME DNS-RESOLVER-FAILURE-MODE PEER of the DKIM-side dkim=permerror (DKIM-Signature header references a per-selector TXT-RR with syntactically- invalid byte-grammar / wrong-record- type / non-existent NXDOMAIN response) / dkim=temperror (per- selector authoritative-DNS-server transient resolver failure) verdict family the per-message verifier produces when the per-selector d= / s= tag- anchored TXT-RR lookup this page's DKIM-Signature byte-grammar publication-discipline references encounters DNS-resolver-failure-mode at receiver-side verification time. Where THIS page documents the per- message per-publisher per-selector RFC 6376 §3.5 DKIM-Signature HEADER FIELD BYTE-GRAMMAR (the b= signature- value tag, the bh= body-hash tag, the v= version tag, the a= algorithm tag, the d= domain tag, the s= selector tag, the c= canonicalization tag, the h= signed-headers tag, the l= body- length tag, the t= timestamp tag, the x= expiration tag, the i= AUID tag), the PermError vs TempError spoke documents the PARALLEL SPF-side per- publisher per-domain RFC 7208 SPF-RECORD-LOOKUP-FAILURE-MODE CATALOGUE the per-message SPF verifier encounters at the per- publisher per-domain SPF-TXT-RR- lookup boundary that PARALLELS the per-message DKIM verifier's per- selector key-record-TXT-RR-lookup boundary this page's DKIM-Signature byte-grammar references. Read THIS page when AUTHORING / VERIFYING the per-message per-publisher per- selector DKIM-Signature header byte-grammar; read the PermError vs TempError spoke when DIAGNOSING the per-publisher per-domain SPF- side permerror vs temperror verdict that PARALLELS the DKIM-side permerror vs temperror verdict the DKIM-Signature header verification path this page documents can produce when the referenced per-selector key- record TXT-RR fails byte-grammar validation or the per-selector authoritative-DNS-server transient lookup fails at receiver-side verification time.
• DMARC reporting pipeline — the PER-MESSAGE-DKIM-VERDICT- DOWNSTREAM-CONSUMER companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the per-message DKIM-Signature header tag- emission mechanics (the v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tags the per-publisher per-selector signer stamps INTO each outgoing message per RFC 6376 §3.5 that the receiver-side DKIM verifier consumes to emit the per-message dkim=pass / dkim= fail / dkim=permerror / dkim=temperror verdict at message-acceptance time), the DMARC-reporting-pipeline spoke is the AGGREGATE-AND-FORENSIC-REPORT-DOWNSTREAM- CONSUMER documenting how that per- message DKIM verdict propagates THROUGH the per-publisher per-domain RUA + RUF reporting pipeline at FOUR per-pipeline- stage per-message DKIM-verdict propagation dimensions: (i) per- message DKIM-verdict aggregate-report emission per RFC 7489 §7.2 — the per-receiver per-day per-publisher per-day per-message DKIM-verdict emission INTO the per-publisher per- domain RUA aggregate-report XML <auth_results><dkim> row (per-message DKIM-domain attribution, per-message DKIM-selector attribution, per-message DKIM-result verdict, per-message DKIM-human-result diagnostic) the per-publisher per-domain DMARC-reporting-pipeline spoke parses out of the per-receiver-emitted aggregate-report XML; (ii) per- message DKIM-verdict forensic-report emission per RFC 6591 — the per-receiver per-aligned-fail per- message DKIM-verdict EMISSION INTO the per-publisher per-domain RUF forensic- report (per-failure-message DKIM- Signature header diagnostic block, per- failure-message DKIM-canonicalization diagnostic, per-failure-message DKIM- body-hash-mismatch diagnostic) the per-publisher per-domain DMARC- reporting-pipeline spoke parses out of the per-receiver-emitted forensic- report ARF stream; (iii) per- message DKIM-verdict pipeline-storage- and-retention discipline — the per-publisher per-domain per-message DKIM-verdict per-receiver per-day per- publisher per-day per-message DKIM- verdict longitudinal-trend storage and retention cadence (per-publisher per- domain per-day DKIM-pass-rate floor time-series, per-publisher per-domain per-selector per-day DKIM-pass-rate floor time-series, per-publisher per- domain per-receiver per-day per-message DKIM-aligned-pass-rate floor time- series) the per-publisher per-domain DMARC-reporting-pipeline spoke materializes at the per-publisher per- domain operator dashboard; and (iv) per-message DKIM-verdict per-publisher per-domain alerting cadence — the per-publisher per-domain per-day per-publisher per- domain per-selector per-receiver per-day per-message DKIM-aligned-pass-rate floor-regression alerting cadence (per- publisher per-domain per-selector DKIM-key rotation observation gate, per-publisher per-domain per-receiver DKIM-aligned-fail-rate spike alerting, per-publisher per-domain per-selector permerror / temperror verdict-class regression alerting) the per-publisher per-domain DMARC-reporting-pipeline spoke emits at the per-publisher per- domain operator alerting boundary. Pair this DKIM-Signature header tag-anatomy reference with the DMARC-reporting- pipeline spoke when DIAGNOSING per- publisher per-domain per-day per- receiver per-day per-message DKIM- aligned-pass-rate-floor regressions observed in the RUA aggregate-report stream — the DMARC-reporting-pipeline spoke is the PER-AGGREGATE-AND-FORENSIC- REPORT-DOWNSTREAM-CONSUMER REFERENCE whose per-message DKIM-verdict per- receiver per-day per-publisher per-day per-message DKIM-aligned-pass-rate-floor time-series the per-publisher per- domain operator structurally consumes as the per-publisher per-domain observable-output proxy for the per- message DKIM-Signature header verification verdict THIS page's per- tag-anatomy emission discipline materially produces at the per-receiver- side DKIM verifier.
• TLS-RPT explained — the per-message DKIM-Signature header tag-anatomy this page documents produces application-layer per-receiver DKIM-aligned-pass verdicts, while TLS-RPT produces per-receiver per-day transport-layer TLS-negotiation outcomes. Adopting both gives publishers a dual-stream per-day observability surface where a DKIM-aligned-pass-rate floor regression and a TLS-encryption- rate regression can be diagnosed independently — distinguishing body-hash recomputation failures at intermediary hops from in-transit downgrade attacks against the same publisher per-domain mail flow.
• DMARC for Microsoft 365 hybrid Exchange — the hybrid-Exchange dual-egress deployment companion to this DKIM-Signature header byte-anatomy reference. Where THIS page documents the per-tag byte-level semantics of every DKIM-Signature: header tag (v=, a=, c=, d=, s=, h=, b=, bh=, i=, q=, l=, t=, x=, z=) plus default values and tag-interaction rules, the hybrid-Exchange spoke documents the canonical DOWNSTREAM deployment topology where the per-message DKIM-Signature tag anatomy is the load-bearing per-egress-leg attribution primitive. The DKIM-SIGNATURE- VS-HYBRID-EXCHANGE cross-reference establishes FOUR coupling dimensions: (i) per-message d= (signing-domain) tag value attributes each aggregate-report row to the correct hybrid leg — EXO publishes d=<tenant>.onmicrosoft.com absent DKIM-Enable, vs d=<custom-domain> when CNAME-delegation is active; on-prem Edge Transport with OpenDKIM publishes operator-chosen d=; the hybrid spoke documents the per-tag attribution path operators rely on; (ii) per-message s= (selector) tag distribution partitions the hybrid mail-flow by signing infrastructure — EXO publishes selector1/selector2 rotation, on-prem Edge Transport publishes operator-chosen selectors; per-leg signing-posture regressions surface through abrupt s= distribution shifts; (iii) per- message b=/bh= cryptographic-proof survivability differs structurally per hybrid leg's relaxed-canonicalization mode and per- boundary transit-rewrite catalogue — the hybrid spoke documents the per- boundary canonicalization-mode- survivability distinction whose per- tag mismatch patterns this page's byte-anatomy reference catalogues; (iv) per-message h= (signed-header list) divergence between EXO and on-prem Edge Transport signers is a canonical hybrid-coexistence regression cause — the hybrid spoke documents the per-boundary coordination invariant whose h=-tag inclusion contract this page's byte-anatomy reference anchors. Read the hybrid-Exchange spoke when diagnosing per-message DKIM-Signature header tag-distribution regressions whose root cause is per- leg signing-infrastructure divergence.
• Email spoofing techniques and defenses — the SEVEN-TECHNIQUE-SPOOFING-ATTACK- CATALOGUE companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the per-tag byte-level semantics of every DKIM-Signature: header tag (v=, a=, c=, d=, s=, h=, b=, bh=, i=, q=, l=, t=, x=, z=), the email-spoofing spoke documents the seven-technique attack catalogue whose per-message header-From-forgery and body-tampering variants the per-message DKIM-Signature header cryptographic-verification THIS page documents structurally closes at four DKIM-Signature-as-anti-spoofing coupling dimensions: (i) per- message d= author-domain tag binding plus b= cryptographic signature proof closes the direct-domain From: forgery technique class — an attacker spoofing From: ceo@<victim- domain> cannot produce a valid b= signature matching the <selector>._domainkey. <victim-domain> published key without possessing the per-publisher per-selector private key, so receiver- side verification surfaces dkim=fail (signature did not verify) as the per-message spoofing-detection signal the email- spoofing catalogue defense section operationalises; (ii) per- message bh= body-hash tag recomputation closes the in-flight message-content tampering spoofing technique class — a man-in- the-middle attacker rewriting wire- transfer routing numbers, substituting phishing URLs, or modifying attachment references causes receiver-side canonicalized-body recomputation to diverge from the publisher signed bh= tag, surfacing dkim=fail (body hash did not verify) as the structurally distinct in-flight-tampering detection signal the email-spoofing catalogue body-tampering-vs-header-forgery disambiguation discipline consumes; (iii) per-message h= signed-header list closes the header- injection spoofing technique sub-class — when an attacker prepends a forged From: header above a legitimately-signed message body, the signed-header list first-From:- only signing-discipline (RFC 6376 §5.4) ensures the prepended forged header falls outside the signature coverage, surfacing the header-injection at receiver-side DMARC-alignment-vs- DKIM-d= comparison as a misalignment signal the email-spoofing catalogue header-From-vs-envelope-From disjunction technique class catalogues; (iv) per-message c= canonicalization-mode tag and l= body-length-limit tag close the canonicalization-ambiguity and body- length-substitution spoofing technique sub-classes — attackers attempting to exploit canonicalization ambiguity under c=simple/simple whitespace substitution or body-length truncation under l= <N> bytes produce per- message DKIM-verification outcomes the email-spoofing catalogue defense-in- depth recommendations explicitly counter by mandating c=relaxed/relaxed plus omitted l= as canonical publisher discipline. Read the email-spoofing catalogue alongside this DKIM-Signature header tag-anatomy reference when translating the per-tag wire-format semantics this page documents into per-attack-technique anti-spoofing defense surface mapping the operator threat-model and incident- response program requires.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-PER-MESSAGE-DKIM- SIGNATURE-APPLICATION-LAYER-ALONGSIDE- TRANSPORT-LAYER-MTA-STS companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the per-tag byte-level semantics of every DKIM-Signature: header tag materialised on Workspace-egress mail via the per-tenant d=<workspace- custom-domain>; s=google; a=rsa-sha256 tag-distribution at the cryptographic-signing layer, the MTA-STS-for-Google-Workspace spoke documents the per-Workspace-tenant per- custom-domain transport-layer TLS- enforcement publication discipline that runs ALONGSIDE the application-layer DKIM-Signature publication discipline THIS page documents at four Workspace- tenant cross-layer per-tenant- publication-discipline coupling dimensions: (i) per-tenant Workspace inbound transport-layer mx: allow-list pinning coordinated with per-tenant application- layer DKIM signing-key publication — Workspace tenants publish per-custom-domain MTA-STS policy-file with mx: aspmx.l.google.com + mx: alt[1-4].aspmx.l.google.com wildcard patterns to pin the receiver- side inbound-MX cohort, while simultaneously publishing per-custom- domain google._domainkey.< workspace-domain> DKIM TXT-RR with Workspace-managed key material; per-tenant publication-rollout discipline ensures the application-layer + transport- layer publications land coherently on the same per-tenant DNS-zone-edit commit boundary; (ii) per-tenant Workspace MTA-STS mode: enforce commitment as transport-layer peer of per-tenant DKIM cryptographic- signing commitment — the Workspace tenant per-custom-domain mode: enforce commitment commits sending MTAs to require STARTTLS- with-valid-cert at Workspace inbound MX, running alongside the per-tenant cryptographic-signing-commitment the per-message DKIM-Signature header THIS page documents materialises; both commitments are per-tenant per-custom- domain scoped and observed downstream through complementary receiver-side Authentication-Results headers and TLS- RPT failure-evidence streams; (iii) per-Workspace-tenant outbound- relay DKIM signing operates alongside per-tenant outbound MTA-STS policy- consumption at receiver-side enforcement boundaries — Workspace's outbound MTAs sign per-message with the per-tenant d=<workspace-domain> + s=google tags THIS page documents, simultaneously honoring receiver-side MTA-STS policies they encounter at delivery time; the per- message DKIM-Signature header survives the receiver-side TLS-enforced transport leg producing per-tenant per-receiver downstream dkim=pass + tls=pass composite verdict; and (iv) per-tenant per-custom- domain TLS-RPT _smtp._tls.< workspace-domain> aggregation as transport-layer evidence stream peer to per-tenant DKIM-verification rate as application-layer evidence stream — Workspace tenants publish per-custom-domain TLS-RPT v=TLSRPTv1; rua=mailto:< ops>@<workspace-domain> receiving per-receiver per-day JSON- aggregate failure-evidence stream; per-tenant per-day TLS-RPT failure- rate runs PARALLEL to the per-tenant per-day DKIM-pass rate as cross-layer observability KPI the per-tenant operator program consumes. Read the Workspace-MTA-STS deployment spoke alongside this DKIM-Signature header tag-anatomy reference when co-deploying per-Workspace-tenant per-custom-domain application-layer cryptographic-signing and transport-layer TLS-enforcement publication discipline.
• Why SPF alone is insufficient — the structural-limitations-of-SPF reference cataloguing the four reasons every per-publisher per-domain email- authentication posture requires additional protocols beyond SPF: (i) RFC 7208 §11.4 forwarding-MAIL-FROM-rewrite-breaks-SPF at the second-hop alias / forwarder / mailing-list boundary; (ii) no message- content cryptographic integrity at the envelope-layer SPF authorization perimeter; (iii) no DMARC-composite-policy alignment signal absent a per-publisher per-domain DKIM key publication; (iv) no BIMI display- eligibility gating absent the cryptographic- anchor DKIM produces. THIS page documents the DKIM-Signature RFC 6376 §3.5 per-tag anatomy (v=, a=, d=, s=, c=, h=, bh=, b=, i=, t=, x=, l=, q=, z=) at the per-message header-stamp boundary as the canonical CRYPTOGRAPHIC-ANCHOR per-publisher per-domain DKIM publishes to close exactly the four structural-SPF-insufficiency gaps the why-SPF-alone-is-insufficient catalogue enumerates — DKIM survives forwarding because per-message body-hash and header- hash verification is independent of envelope MAIL-FROM rewriting, DKIM provides message- content cryptographic integrity at the application-layer, DKIM enables DMARC- composite alignment via the per-publisher per-domain d= tag, and DKIM produces the upstream cryptographic-anchor every BIMI Tiny-PS-SVG display-eligibility gate consumes. Read the why-SPF-alone-is- insufficient spoke alongside this DKIM- Signature tag-anatomy reference when scoping the per-publisher per-domain DKIM- publication discipline that structurally closes the four SPF-only structural- limitations catalogued, when authoring the per-publisher per-domain defense-in-depth SPF + DKIM dual-protocol-leg deployment playbook, or when sequencing the per- publisher per-domain DMARC ramp on DKIM-aligned-pass-rate evidence rather than SPF-alone evidence.
• RFC 6376 §3.5 — DKIM-Signature header field — the normative source for every tag definition.
• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — modern algorithm guidance: rsa-sha256 only, 2048-bit minimum, rsa-sha1 deprecated.
• RFC 8463 — Ed25519 algorithm for DKIM — the Ed25519 algorithm addition.
• DMARC for SaaS senders — the DKIM-SIGNATURE-PROTOCOL-MECHANICS- FOR-MULTI-TENANT-SHARED-IP-SAAS-PLATFORM companion to this DKIM-Signature header tag-anatomy deep dive. Where THIS page documents the per-message DKIM-Signature header tag anatomy (the v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tags the sender stamps INTO each outgoing message), the SaaS-senders spoke is the MULTI-TENANT-SIGNER-OPERATOR- PERSONA companion documenting the FOUR distinct DKIM-protocol-mechanics implications a SaaS-platform sender faces vs a single-tenant operator: (i) per-tenant d= attribution in the DKIM-Signature header — the SaaS platform must stamp the CUSTOMER's d= domain (not the platform's d= domain) for the DMARC- alignment-with-the-customer-From: to succeed; the SaaS platform's outbound MTA dynamically selects the d= tag per outgoing message based on which tenant authored the campaign; (ii) per-tenant s= selector rotation — each tenant has a distinct s= selector (typically k1, k2, hs1, mte1, scph0125) published in the tenant's DNS zone as a CNAME to a SaaS-platform-managed key-bearing host; the SaaS platform rotates the underlying key on the platform side while the tenant's CNAME continues to resolve, decoupling the rotation from the tenant's DNS-change cadence; (iii) per-tenant key isolation at the cryptographic layer — the SaaS platform must implement per-tenant private- key separation so a key-compromise incident at one tenant's selector does NOT enable cross-tenant brand impersonation (a SaaS platform that signs all tenants with a shared key violates this isolation property); (iv) per-tenant canonicalisation + algorithm defaults — the SaaS platform must consistently choose c=relaxed/relaxed + a=rsa-sha256 (or a=ed25519-sha256 with appropriate algorithm-key-strength publishing in the DNS record's k= tag) so the DKIM-Signature header byte-format THIS page documents renders correctly for every per-tenant-d= variant the platform signs. Read the SaaS-senders spoke alongside this page when designing a SaaS-platform DKIM-signing pipeline, or when consuming a SaaS-platform-signed DKIM-Signature header during receiver-side verification investigation, and you need the MULTI-TENANT-SIGNER- PROTOCOL-MECHANICS reference for the operator persona this page's per- tag anatomy supports.
• DMARC for transactional email — the TRANSACTIONAL-ESP-PER-MESSAGE-DKIM- SIGNATURE-HEADER-BYTE-CORRECTNESS companion to this DKIM-Signature header tag-anatomy deep dive. Where THIS page documents the per-message DKIM-Signature header tag anatomy (the v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tags the sender stamps INTO each outgoing message), the transactional-email spoke is the TIME-SENSITIVE-DELIVERY-OUTCOME COMPANION documenting the FOUR PER-MESSAGE-SIGNATURE- TAG DELIVERABILITY GATE dimensions every transactional ESP (SendGrid / Mailgun / Amazon SES / Postmark / SparkPost / Twilio / Resend) materialises distinctly from the marketing-ESP signature pattern: (i) per-customer-domain d= tag at the transactional ESP CNAME- delegated signing boundary — every transactional ESP signs with the customer's d=<customer-domain> via CNAME-delegated DKIM publication (s1._domainkey.<customer> CNAME s1.domainkey.u123.wl.sendgrid.net) so the per-message DKIM signature aligns with the customer's From:-domain for DMARC evaluation — distinct from the marketing- ESP per-platform-managed d=<esp- signing-domain> pattern; the per- customer d= tag in the DKIM-Signature header IS the load-bearing per-tenant publisher-distinguisher every transactional ESP customer's p=quarantine / p=reject posture depends on at every major receiver; (ii) per-customer s= selector at the ESP-managed-key publication boundary — transactional ESPs publish per-customer DKIM keys at ESP- controlled CNAME targets so the per-customer s= selector in the DKIM- Signature header dereferences to an ESP-managed key the customer never directly handles — rotation discipline lives at the ESP side with the customer's per-customer CNAME continuing to resolve through the rotation; THIS page's per-s= tag anatomy is the canonical reference for receiver-side verifier reconstruction of the transactional ESP's per-customer published-key lookup; (iii) per- message t= timestamp + x= expiry tags as time-sensitive-transactional- message replay-protection — RFC 6376 §3.5 t= and x= tags are LOAD-BEARING for transactional ESPs whose time-sensitive OTP / MFA / password-reset messages must NOT be replayable hours-to-days after issuance; THIS page's per-t=/x= tag anatomy IS the byte-precise reference for the transactional ESP's per-message time-bounded signature publication discipline; (iv) per-message c=relaxed/relaxed + a=rsa- sha256 canonicalisation discipline for transactional-ESP message-integrity survival through receiver-side MTA pre- delivery rewriting — transactional messages traverse the customer's per-tenant MTA, the ESP-managed outbound MTA, the receiver-side MTA, and the per-mailbox delivery agent — at every hop, whitespace and header-folding can change; THIS page's per-c= canonicalisation tag anatomy IS the byte-precise reference for the transactional ESP's canonicalisation- choice discipline that preserves DKIM-pass through the multi-hop transit topology time-sensitive transactional mail depends on. Read the transactional-email spoke alongside this page when investigating per-customer-domain DKIM-Signature header byte-correctness for a transactional ESP customer's outbound stream, or when designing the per-customer CNAME-delegation + per-customer d=-stamping + per-message t=/x= tagging discipline a transactional ESP platform must implement at the per- customer signing boundary — the per-tag anatomy THIS page documents IS the per- message contract the transactional ESP operational topology must satisfy for every time-sensitive product-issued message at the per-receiver deliverability gate.
• DMARC forensic reports (RUF) — the PER-FAILED-MESSAGE-AFRF-ENVELOPE- EMBEDDED-DKIM-SIGNATURE-EVIDENCE-STREAM companion to this DKIM-Signature header tag-anatomy deep dive. Where THIS page documents the per-message DKIM-Signature header tag anatomy (the v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tags the sender stamps INTO the outgoing message and the receiver's verifier recomputes against the published s=._domainkey.d= public key), the DMARC forensic-reports (RUF) spoke documents the EVIDENCE STREAM that preserves the OFFENDING message's COMPLETE DKIM-Signature header bytes EXACTLY as the receiver's verifier saw them, enabling BYTE-LEVEL forensic reconstruction of which per-tag mechanic produced the DKIM verification failure that drove the downstream DMARC alignment outcome. The RUF envelope's embedded message/rfc822 part (RFC 5965 outer message/feedback-report MIME container + RFC 6591 Auth-Failure feedback-type stamping + the original message's complete header block + optional embedded original-message body) is the ONLY diagnostic surface that preserves the EXACT BYTES the receiver's verifier failed on, including: (i) the b= signature blob's base64 bytes — instantly revealing whether a content-modifying intermediary mutated the signed-content covered by the h= tag list post-signing (mailing-list footer injection, subject-line tagging, antivirus header-rewriting) versus a key-rotation race where the receiver fetched a stale public key before the new key had DNS-propagated; (ii) the bh= body-hash bytes — instantly revealing whether the body was modified post-signing (Outlook autosignature injection, Reply-Above-Quote header insertion, ESP-side tracking-pixel rewrites, URL-shortener Mailto-rewrites) versus the canonicalisation algorithm chosen (c= relaxed/simple body canonicalisation has different whitespace-handling semantics and a whitespace-only modification can cause a c=simple bh= mismatch but not a c=relaxed mismatch); (iii) the h= tag listing the signed header block — instantly revealing whether the sender omitted a load-bearing header like Subject, From, To, Date the receiver's DMARC-aligned-signing policy requires for full message authenticity; (iv) the d= tag versus the From: organisational-domain pair — instantly revealing whether the failure was a structural alignment failure (d=tenant.onmicrosoft.com Workspace-relay pathology, d=sendgrid.net SaaS-platform unaligned-signing pattern) versus a cryptographic verification failure (the b= signature blob does not match the recomputed signature under the resolved public key) versus a key-rotation race (the s= selector resolves NXDOMAIN at the receiver's resolver because the new selector has not yet DNS-propagated to all receivers); (v) the a= algorithm tag — instantly revealing whether the receiver rejected an obsolete rsa-sha1 signature per RFC 8301's hard deprecation, or whether the receiver did not yet implement RFC 8463 Ed25519 verification. Read the DMARC forensic-reports spoke when authoring the DKIM-Signature diagnostic playbook — the ruf=mailto:dmarc-forensic@… publication, the fo=d DKIM-specific failure-reporting-options posture (emit RUF on DKIM failure even when SPF aligned and the message survived DMARC evaluation overall — the operator- facing knob surfacing the maximum DKIM-diagnostic evidence volume), the still-active forensic receivers (Yahoo / AOL / Mail.ru — Microsoft and Gmail DEPRECATED RUF emission so the DKIM evidence stream for messages delivered to those receivers is unavailable), and the GDPR Art 28 processor-agreement scrutiny governing operator-side RUF ingestion — for DKIM-Signature diagnostic purposes the operator typically does NOT need the embedded body bytes and the per-receiver redaction (header-only RUF) is the privacy- preserving operational baseline.
• Email security & privacy glossary — the DKIM-SIGNATURE-HEADER-BYTE-ANATOMY- RESOLVES-BACK-TO-GLOSSARY-VOCABULARY- DEFINITIONS reverse-direction companion to this RFC 6376 §3.5 byte-by-byte tag anatomy reference. Where THIS page documents every one of the 14 canonical DKIM-Signature tags byte-by-byte (the 7 required tags v= a= d= s= h= bh= b=, plus the 7 optional tags c= i= q= l= t= x= z=) with format, defaults, validity rules, failure modes, and operational guidance, the email-security-glossary spoke is the SINGLE-SENTENCE TERM-OF-ART DEFINITION CATALOGUE for the security-and-privacy vocabulary every per-tag mechanic this page covers either implements, defends against, or surfaces as a failure-class. The reverse-direction symmetric backlink completing the sender-side-byte-anatomy↔security- vocabulary pair (the GLOSSARY-AS- UNIVERSAL-SOURCE pattern per memory feedback_glossary_as_universal_source shipped the forward direction in the prior loop). Four structurally-distinct DKIM-SIGNATURE-TAG-VS-GLOSSARY- VOCABULARY operational classes the spoke covers that THIS page's per-tag byte-by-byte reference intentionally elides: (i) cryptographic- algorithm-name vocabulary → glossary single-sentence definition resolution — the a= tag's accepted values (rsa-sha256, ed25519-sha256, rsa-sha1) resolve to the glossary's single- sentence definitions of those cryptographic-algorithm names plus the RFC 8301 §3.2 receiver-side weak- algorithm-rejection discipline, RFC 8463 ed25519-curve adoption status, and the historical NIST 800-131A SHA-1 deprecation timeline that contextualises why rsa-sha1 is now a cryptographic-failure-class trigger rather than a deployment choice; (ii) signature-replay-attack vocabulary → glossary l= body-length- limit single-sentence definition resolution — the l= tag's body-length- limit-replay-vector documentation on THIS page (the RFC 6376 §3.5 cautionary text warning operators against publishing l= because it allows attackers to APPEND content to a legitimately-signed message without invalidating the b= signature) resolves to the glossary's single-sentence signature-replay-attack and l= body-length limit term-of- art definitions — pairing the byte- level mechanism this page documents with the threat-class single-sentence catalogue entry the glossary surfaces in the operator-side security- vocabulary lexicon; (iii) body-modification-vs-header-tampering failure-class vocabulary → glossary two-hash-design single-sentence definition resolution — the TWO-HASH-DESIGN section on THIS page (the bh= body-hash check INDEPENDENT from the b= signed-header-set signature verification, with the b= verification covering the canonicalised signed-header set INCLUDING the DKIM-Signature header itself with b= temporarily empty) resolves to the glossary's single-sentence body modification versus header tampering failure- class definitions — the cryptographic decomposition every verifier implementation follows that determines WHICH of the two cryptographic verifications failed for a given DKIM verdict the operator triages; (iv) key-compromise- and-rotation-overlap vocabulary → glossary single-sentence definition resolution — the s= tag's selector-naming- discipline documentation on THIS page (per-selector key publication at <s>._domainkey.<d> DNS path supporting key-rotation- overlap with old + new selectors co-published) resolves to the glossary's single-sentence key compromise, key rotation, signing material as protected key, and rotation overlap threat-vocabulary entries — pairing the per-tag operator-side discipline this page documents with the threat- class definitions the glossary catalogues. Required reading for operators who need to translate the per-tag byte-anatomy this page documents into the security-and- privacy term-of-art vocabulary the glossary defines for incident- response playbook authoring, compliance-evidence narrative composition, and cross-team security communication.
• SPF DNS-record syntax — the DKIM-SIGNATURE-HEADER-BYTE- ANATOMY-IS-MESSAGE-EMBEDDED-WHEREAS- SPF-v=spf1-TXT-RR-IS-DNS-PUBLISHED companion to this DKIM-Signature header byte-anatomy reference. Where THIS page documents the per-message DKIM-Signature header byte-anatomy (the canonical RFC 6376 §3.5 v= / a= / b= / bh= / c= / d= / h= / l= / q= / s= / t= / x= tag list embedded INSIDE the per- message message envelope as a per- message header that the receiver- side verifier parses out-of-the- message-stream), the SPF DNS-record syntax spoke documents the STRUCTURALLY-PARALLEL per-domain v=spf1 TXT-RR DNS- publication byte-grammar whose per- domain publication-discipline is consumed by the receiver-side SPF evaluator OUT-OF-BAND from the per- message message envelope. The four- axis DKIM-SIGNATURE-HEADER-vs-SPF- v=spf1-TXT-RR byte-format LOCUS comparison exposes the structurally- distinct per-publisher per-message- vs-per-domain byte-format roles: (i) per-publisher per-message DKIM-Signature header byte-anatomy is MESSAGE-EMBEDDED — the receiver- side verifier parses the per-message DKIM-Signature header out-of-the- SMTP-DATA-phase per-message byte- stream, whereas per-publisher per- domain SPF v=spf1 TXT-RR byte- grammar is DNS-PUBLISHED — the receiver-side SPF evaluator retrieves the per-domain v=spf1 TXT-RR via an OUT-OF-BAND DNS query at receiver- side SPF-evaluation time — the SPF DNS-syntax spoke documents the per-domain v=spf1 TXT-RR publication-byte-grammar (255-octet character-string- fragmentation, "exactly one SPF record per scope" rule, whitespace-and-case mechanics) that runs ALONGSIDE the per- message DKIM-Signature header byte-anatomy THIS page documents, with the two byte-formats materialising at structurally- distinct LOCI (per-message header embedded in SMTP DATA-phase bytes vs per-domain TXT-RR retrieved via OUT-OF-BAND DNS query); (ii) per-publisher per-message DKIM-Signature header binds the per-message bh= body-hash cryptographically to the per- message byte-stream — the per- message DKIM-Signature header survives or breaks at every forwarder hop based on the per- message bh= body- hash's per-hop byte-modification- survival under the c=relaxed/relaxed vs simple/simple canonicalisation choice, whereas per-publisher per-domain SPF v=spf1 TXT-RR encoding the per-domain authorised-sender IP set is STATIC under per-message forwarding — the per-message SPF evaluation re-runs at every forwarder hop against the per- domain TXT-RR but the TXT-RR itself does not mutate per- message — the SPF DNS- syntax spoke documents the per- domain TXT-RR publication-byte- grammar whose per-publication- discipline (the "exactly one SPF record per scope" rule, the publication-mode commitment -all vs ~all) determines the per-message SPF re-evaluation result at every forwarder hop, whereas the DKIM-Signature header-anatomy THIS page documents determines the per- message DKIM re-evaluation result via the per-message bh= body-hash and b= signature-bytes survival; (iii) per- publisher per-message DKIM- Signature header d= / s= tag binding couples the per-message signature to the per-publisher per-domain <s>._domainkey.<d> TXT-RR public-key publication — making the DKIM verification chain a per-message-header- embedded-tag-PLUS-per-domain-DNS- published-TXT-RR STRUCTURALLY-PARALLEL to the per-message-envelope-MAIL-FROM- PLUS-per-domain-SPF-TXT-RR binding chain at the SPF leg — both authentication legs couple a per-message-stream primitive (DKIM-Signature header / envelope-MAIL-FROM domain) to a per-domain DNS- published TXT-RR (DKIM public-key TXT-RR / SPF v=spf1 TXT- RR) — the SPF DNS- syntax spoke documents the per- domain TXT-RR byte-grammar that SPF-side of the dual per-message- primitive-PLUS-per-domain-TXT-RR binding chain depends on, while the DKIM-Signature-header byte- anatomy THIS page documents the DKIM-side per-message-header primitive that the parallel per-domain <s>._domainkey.<d> TXT-RR DNS publication binds to; and (iv) per-publisher per-message DKIM-Signature header l= body- length-limit tag (RFC 6376 §3.5) is the per-message body-byte-range-limit commitment publisher injects INTO the per-message header, STRUCTURALLY PARALLEL to the per-publisher per-domain SPF v=spf1 TXT-RR's publication-mode commitment (-all / ~all / ?all) the publisher injects INTO the per-domain TXT-RR — both are per-publisher commitments about how to handle deviation from the per- publisher-authored authentication policy, BUT the DKIM l= commitment is per-message-embedded whereas the SPF -all commitment is per-domain- DNS-published — the SPF DNS-syntax spoke documents the per-publisher per-domain v=spf1 TXT-RR publication-mode commitment discipline (the publisher's choice of -all vs ~all vs ?all as the authoritative receiver-side publisher-signal about how to handle unauthorised sending IPs) every per- message DKIM-Signature- header-authoring publisher must coordinate against at the per-publisher authentication-policy- commitment boundary. Read the SPF DNS-record syntax spoke when authoring per- publisher per-domain SPF and per-publisher per- domain DKIM publication AT THE SAME deployment change-set (audit the per-domain v=spf1 TXT- record's 255-octet character-string- fragmentation discipline AND the per-publisher per- domain <s>._domainkey.<d> DKIM public-key TXT-record publication in the same change-set), and when diagnosing per-message DKIM verification failures that correlate with per- domain SPF permerror events suggesting per- publisher per-domain zone-file syntax drift across BOTH per-domain authentication-leg TXT- records.
• DMARC aggregate (RUA) reports — the PER-MESSAGE-DKIM-SIGNATURE- HEADER-VERDICT-AS-PER-ROW-AUTH-RESULTS- DKIM-XML-EVIDENCE-AT-FOUR-PER- SIGNATURE-TAG-TO-RUA-FIELD-MAPPING- DIMENSIONS companion to this DKIM- Signature header tag-anatomy reference. Where THIS page documents the RFC 6376 §3.5 DKIM-Signature header tag-list (the v= version tag, the a= algorithm tag, the c= canonicalization tag, the d= signing-domain tag, the s= selector tag, the t= signature-timestamp tag, the x= signature- expiry tag, the h= signed-header-list tag, the bh= body-hash tag, the b= signature-bytes tag, the i= identity tag, the l= body-length-limit tag, the z= copied-header- canonicalization tag), the aggregate- reports spoke is the RECEIVER-EMITTED- PER-ROW-EVIDENCE-XML-SCHEMA companion documenting which signature-header bytes the receiver preserves verbatim in the per-row aggregate-report XML for the publisher's per-source-IP per-day analysis. Concretely, the spoke documents FOUR per-signature-tag to RUA-field mapping dimensions: (i) d= tag → per-row <auth_results><dkim> ><domain> — the receiver-emitted per-row XML records the d= tag literal from the verified DKIM-Signature header verbatim — providing the publisher with per-source-IP per-day attribution evidence for which signing- domain identity the receiver cryptographically verified the per- message DKIM-Signature against, which is the canonical attribution primitive the publisher reads to pin legitimate-publisher-signing vs cohabit- tenant-signing vs attacker-replay- signing root causes; (ii) s= tag → per-row <auth_results><dkim> ><selector> — the receiver-emitted per-row XML records the s= selector literal from the verified DKIM- Signature header verbatim — providing the publisher with per-source-IP per- day evidence for which DKIM key publication record under <s=>._domainkey.<d=> the per-message signature was verified against, which is the canonical selector-coverage diagnostic primitive the publisher reads when monitoring dual-selector rotation overlap windows or per-tenant selector-isolation compliance; (iii) cryptographic verification outcome → per-row <auth_results><dkim> ><result> — the receiver-emitted per-row XML records the RFC 8601 verification verdict (pass / fail / permerror / temperror / policy / neutral / none) — the per-receiver per-day verdict-distribution evidence the publisher monitors as the canonical signing-infrastructure-health KPI whose regression-rate-threshold gates every per-tag publication change THIS page documents; (iv) multiple DKIM-Signature headers per message → multiple per-row <auth_results><dkim> repetitions reflecting any-aligns-wins evaluation — the receiver- emitted per-row XML records EACH DKIM- Signature header verified against the message (publisher's own first-party signature + downstream-relay-resigner signature + ARC-signer signature), each in its own <auth_results><dkim> block — the per-row XML preserves the any-aligns-wins evaluation evidence the multi-signature double-signing operator-discipline THIS page documents as the deliverability hedge depends on. Read the aggregate-reports spoke ALONGSIDE this DKIM-Signature header tag-anatomy reference to close the feedback loop between the per- signature-tag byte-publication discipline and the per-row XML evidence stream every receiver emits.
• DMARC policy modes — the per-publisher per-domain DMARC policy- mode publication-discipline COMPANION to this per-message DKIM-Signature header tag-anatomy reference. Where THIS page documents the per- message DKIM-Signature header byte-correctness discipline (the per-signature v=1; a=rsa- sha256; c=relaxed/simple; d=...; s=...; h=...; bh=...; b=... tag-vocabulary + canonicalisation + signing-and-verification algorithm contract per RFC 6376 §3.5), the DMARC policy-modes spoke documents the per- publisher per-domain canonical p=none → p=quarantine → p=reject staged-ramp publication-discipline whose per-message enforcement decision (deliver / quarantine / reject) consumes the per-message DKIM- Signature verification outcome THIS page documents as the load-bearing application- layer authentication-leg input feeding the DMARC composite-pass algorithm. The per- publisher per-domain DKIM byte-correctness discipline IS therefore the load-bearing per-message application-layer-authentication primitive every DMARC policy-mode-enforcement decision structurally depends on at the per- publisher per-domain composite per-message DKIM-verification-vs-DMARC-policy-enforcement coupling boundary.
• DMARC multi-domain strategy — the PER-ORG-DOMAIN CRYPTOGRAPHIC- IDENTITY-PUBLICATION companion to this DKIM-Signature header tag-anatomy reference. Where THIS page documents the SINGLE-message DKIM-Signature header byte-anatomy (the d= signing-domain identity tag, the s= selector tag, the bh= body-hash tag, the b= cryptographic-signature tag, the a=/c=/ h=/i=/ l=/t=/ x= protocol tags, the multi-signature stacking rule), the multi-domain-strategy spoke is the PER-ORG-DOMAIN CRYPTOGRAPHIC-KEY- PUBLICATION COORDINATION REFERENCE documenting how the same per-message DKIM-Signature header tag-anatomy multiplies across every distinct Friendly-From-header organisational domain a multi-brand publisher emits under plus every sibling subdomain under each operator-published org- domain. Concretely the spoke documents FOUR per-org-domain DKIM-publication- discipline-vs-signing-coordination dimensions: (i) per-org-domain <selector>._domainkey.<d-domain> TXT-RR publication discipline runs INDEPENDENTLY per Friendly-From-header organisational domain — every distinct brand / business-unit / acquired-company org-domain the multi- brand publisher emits under requires its OWN per-org-domain DKIM public- key TXT-RR publication, and the d=<org-domain> tag binding in every per-message DKIM- Signature header points at the per- org-domain selector-keyed TXT-RR — the multi-domain-strategy spoke documents the per-org-domain DKIM- key-publication coordination contract the multi-brand publisher must apply; (ii) per-tenant cloud- mailbox-provider CNAME-delegation coordination across every operator- published org-domain is the PER-ORG- DOMAIN DKIM-CNAME-DELEGATION EXTENSION — the multi-brand publisher emitting through M365 must publish per-org-domain selector1-<tenant>._domainkey.<org-domain> + selector2-<tenant>._domainkey.<org-domain> CNAME records pointing at the Microsoft-managed selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com + selector2-<tenant>._domainkey.<tenant>.onmicrosoft.com keys per RFC 6376 §3.6.2.1 CNAME- chase, and the per-org-domain CNAME publication-discipline must be coordinated across every operator- published org-domain in the tenant because per-org-domain unconfigured CNAME-delegation produces d=<tenant>.onmicrosoft.com signing the multi-domain-strategy spoke documents as the per-org- domain DMARC-non-alignment failure mode; (iii) per-subdomain signing coordination across every sibling subdomain under every operator-published org-domain is the PER-SUBDOMAIN DKIM-KEY- PUBLICATION EXTENSION — the per-org-domain marketing.<org-domain> / support.<org-domain> / noreply.<org-domain> per-subdomain signing surfaces require per-subdomain DKIM TXT-RR publication coordination so the per- message DKIM-Signature header d=<subdomain>.<org-domain> tag points at a published per- subdomain selector-keyed TXT-RR, and the multi-domain-strategy spoke documents the per-subdomain signing-publication coordination every multi-brand publisher must apply alongside the per-subdomain DMARC sp=-tag inheritance contract; and (iv) per-org- domain dual-selector overlap-window key-rotation coordination runs INDEPENDENTLY per Friendly-From- header org-domain — the per-message DKIM-Signature header s=-tag selector identification across the per-org- domain dual-selector overlap window (selector1 + selector2 active simultaneously during cryptographic key rotation) runs INDEPENDENTLY per Friendly-From-header organisational domain because per- org-domain dual-selector overlap- window discipline is per-org-domain operator-published, and the multi- domain-strategy spoke documents the per-org-domain dual-selector coordination contract every multi- brand publisher must apply to prevent the transient-rotation- window infrastructure-evasion attacker-bypass technique per RFC 6376 §3.6.1. Read the multi-domain- strategy spoke ALONGSIDE this DKIM- Signature header tag-anatomy reference when authoring the multi- brand publisher's per-org-domain cryptographic-key-publication coordination playbook — the spoke documents how the per-message DKIM- Signature header d=/ s= tag binding THIS page establishes multiplies across every Friendly-From-header org- domain plus every sibling subdomain the multi-brand publisher emits under.
• Business Email Compromise (BEC) — the DKIM-SIGNATURE-HEADER-TAG- ANATOMY-AS-LOAD-BEARING-BEC-FINANCIAL- FRAUD-DEFENSE-PRIMITIVE companion to this DKIM-Signature header anatomy reference. Where THIS page documents the per-message RFC 6376 §3.5 DKIM- Signature header tag-list byte-anatomy (v= a= c= d= s= t= h= bh= b= + optional i= l= q= x= z=), the business-email-compromise spoke documents the canonical BEC financial- fraud-attack-category catalogue (CEO-fraud, vendor / supplier-invoice fraud, payroll- redirect, attorney impersonation, data / W-2 theft, account-compromise BEC — six canonical variants per FBI IC3 USD 2.9B reported 2023 loss + USD 55B+ cumulative since 2013), the five-stage BEC kill-chain (reconnaissance → spoof / impersonate → social-engineer → financial-instrument- redirect → exfiltrate), and the per- variant defense-in-depth control stack whose CRYPTOGRAPHIC FOUNDATION is the DKIM-Signature header tag-list THIS page documents — at four DKIM-Signature-tag- to-BEC-financial-fraud-defense coupling dimensions: (i) d-tag publisher- domain attestation as BEC-CEO-fraud- impersonation-prevention primitive — the per-message d=<publisher- domain> tag THIS page documents is the message-layer-cryptographic- attestation that the message originated from the publisher-domain's authoritative signing infrastructure (not from an attacker-controlled lookalike domain); the BEC CEO-fraud attack-variant relies on FROM-header-spoofing of the publisher's executive identity, and the d-tag's DMARC-alignment-evaluation against the RFC 5322 From: author-domain is the load-bearing receiver-side primitive that blocks the CEO-fraud impersonation at the per-message authentication gate; (ii) h-tag signed-header-list as BEC- Reply-To / From-header / Subject-line manipulation defense primitive — the per-message h=From:Subject: Reply-To:... tag THIS page documents is the message-layer-cryptographic- attestation that the publisher-side signing infrastructure committed to the EXACT byte-content of the listed headers; the BEC attacker's downstream-mutation of From / Reply-To / Subject (typical BEC mailing-list-style header-rewrite attack) is detected by DKIM-signature- verification at the receiver because the h-tag-listed header byte-content no longer matches the b-tag signature; (iii) bh-tag body-hash + b-tag signature as BEC-financial-instrument-redirect- substitution-defense primitive — the per-message bh=<base64> body-hash + b=<base64> signature THIS page documents are the message-layer-cryptographic-attestation that the publisher-side signing infrastructure committed to the EXACT byte-content of the message body (the wire-transfer-IBAN, the supplier-invoice- account-number, the W-2-tax-data, the payroll-redirect-account); the BEC attacker's downstream-body-mutation to substitute attacker-controlled financial- instrument data is detected by DKIM- signature-verification because the bh-tag body-hash no longer matches the post- mutation body and the b-tag signature no longer verifies; (iv) per- message t-tag timestamp + x-tag expiry as BEC-replay-attack-defense primitive — the per-message t=<unix-time> + x=<unix-time> tags THIS page documents are the message- layer-cryptographic-attestation primitives that limit DKIM-signature-replay windows; the BEC attacker's reuse of a cryptographically-valid DKIM-signed legitimate message (captured at an earlier time-window) to replay against a different downstream recipient is bounded by the t/x-tag emission discipline the publisher-side signing infrastructure adopts. Read the BEC spoke ALONGSIDE this DKIM-Signature header anatomy reference whenever the per-publisher per-domain defense-in-depth posture is being scoped for BEC-financial-fraud-attack-category coverage — the DKIM-Signature header tag- list THIS page documents IS the message- layer-cryptographic-attestation primitive the BEC defense-in-depth-control-stack the BEC spoke documents structurally consumes at every per-message authentication boundary.
• MTA-STS vs DANE for SMTP — the PER-EGRESS-PATH-TLS- ENFORCEMENT-PROTOCOL-CHOICE decision-matrix companion to this DKIM-Signature-header byte- anatomy reference. Where THIS page documents the per-message DKIM-Signature header byte- anatomy (the v= version, the a= signing algorithm, the b= signature value, the bh= body-hash, the c= canonical- ization, the d= signing-domain identifier, the h= signed-header set, the s= selector, the t= timestamp, the x= expiration tag), the mta_sts_vs _dane spoke documents the RFC- 8461-vs-RFC-7672 trust-anchor decision matrix that the per- publisher per-egress-shard TLS- encrypted SMTP path THIS page's per-message DKIM-Signature header in-transit-byte- preservation structurally depends on resolves to. FOUR structurally-distinct PER-TRUST- ANCHOR-VS-PER-DKIM-SIGNATURE-IN- TRANSIT-PRESERVATION-COUPLING- DIMENSIONS the mta_sts_vs_dane comparison spoke operationally documents: (i) per- publisher MTA-STS-policy- enforced TLS-handshake-success- rate AS LOAD-BEARING-UPSTREAM- PRECONDITION-OF-PER-MESSAGE- DKIM-SIGNATURE-BYTE-PRESERVATION via the per-publisher per- receiver _mta-sts.<d- domain> TXT-record + HTTPS-PKI-fetched policy-file publication — per- message DKIM-Signature header byte-integrity in transit REQUIRES the SMTP path to be TLS-encrypted AND TLS- authenticated against a trusted anchor; the mta_sts_vs_dane spoke documents the RFC 8461 §3.2 policy-file syntax (the version: STSv1 version-prefix, the mode: enforce terminal-state, the mx: mail-flow- authorization invariants) whose per-publisher publication IS the canonical Web-PKI- anchored TLS-enforcement- protocol-choice the per-message DKIM-Signature-header in- transit-byte-preservation depends on at every Web-PKI- anchored receiver; (ii) per-publisher DANE-EE TLSA-record-validated TLS- handshake-success-rate AS LOAD- BEARING-UPSTREAM-PRECONDITION-OF- PER-MESSAGE-DKIM-SIGNATURE-BYTE- PRESERVATION via the per-mail- exchanger _25._tcp.<mx- hostname> DNSSEC- anchored TLSA publication — DANE-validated TLS- handshakes carry per-publisher per-egress-shard DNSSEC-anchored cryptographic identity-binding the per-message DKIM-Signature header byte-integrity in transit depends on at every DANE-aware receiver; the mta_sts_vs_dane spoke documents the RFC 7672 §3.1 TLSA owner-name convention, the canonical DANE-EE (usage=3) + SPKI-selector (selector=1) + SHA-256-matching (matching- type=1) deployment shape whose per-publisher publication IS the DNSSEC-anchored TLS-enforcement- protocol-choice the per-message DKIM-Signature-header in- transit-byte-preservation depends on at every DANE-aware receiver; (iii) per- receiver MTA-STS-OR-DANE availability matrix AS LOAD- BEARING-PER-RECEIVER-PER- PROTOCOL-CHOICE-COVERAGE-INPUT of the per-publisher per-egress- shard DKIM-Signature-byte- preservation-coverage-rate — different receivers support different TLS- enforcement protocols (Gmail / Yahoo / Microsoft support MTA- STS; major German / Dutch / Scandinavian ISP-mailbox operators support DANE; some receivers support BOTH); the mta_sts_vs_dane spoke documents the per-receiver per-protocol- choice support matrix that publishers consume to maximise per-message DKIM-Signature-byte- preservation coverage across the receiver population; (iv) per-publisher coexistent MTA-STS + DANE publication AS RFC-7672-§1.3-COEXISTENCE-RULE- COMPLIANCE-STATE-MAXIMISING- DKIM-SIGNATURE-BYTE-PRESERVATION- COVERAGE — the mta_sts _vs_dane spoke documents the RFC 7672 §1.3 coexistence rule (DANE-aware senders prefer TLSA when both are published; MTA- STS-only senders fall back to the HTTPS-PKI policy file) that publishers exploit to maximise per-message DKIM-Signature-byte- preservation coverage across every Web-PKI-anchored AND DNSSEC-anchored receiver. Read the mta_sts_vs_dane comparison spoke ALONGSIDE this DKIM- Signature-header byte-anatomy reference whenever the publisher scopes a per-publisher per- egress-shard TLS-enforcement- protocol-choice deployment plan — the RFC-8461-vs-RFC-7672 decision-matrix THIS comparison spoke documents IS the canonical load-bearing TLS-enforcement- protocol-choice input every per- message DKIM-Signature-header byte-preservation outcome on the receiving side structurally depends on.
• Email Header Analyzer — paste any DKIM-Signature header and see the parsed tag-by-tag breakdown.
• Domain Security Checker — validates the public-key TXT side: confirms d= and s= resolve to a valid record.
• BIMI Verified Mark Certificates (VMCs) explained — the PER-MESSAGE-DKIM-SIGNATURE-AS- UPSTREAM-PREREQUISITE-FOR-PER-PUBLISHER- BIMI-VMC-RENDER companion to this DKIM Signature header reference. Where THIS page documents the RFC 6376 DKIM-Signature header byte-anatomy (the v= / a= / d= / s= / c= / bh= / b= / h= tag catalogue, the per- message body-hash and signature-hash recomputation contract, the per-selector TXT-record cryptographic-trust-anchor), the BIMI-VMC-explained spoke is the per- publisher X.509 certificate Web-PKI trust- chain reference documenting the per-publisher VMC / CMC issuance contract whose per- publisher render-eligibility GATE is the per-publisher per-message DKIM-aligned-pass rate THIS page documents the cryptographic evaluation discipline of. The PER-MESSAGE- DKIM-SIGNATURE-VS-PER-PUBLISHER-BIMI-VMC- TRUST-CHAIN cross-reference establishes FOUR structurally-distinct dimensions: (i) per-publisher dual-cryptographic- trust-anchor publication discipline — the per-publisher per-selector DKIM-public-key TXT-record is the application-layer per- message-signing trust-anchor; the per- publisher BIMI VMC is the Web-PKI per- publisher mark-attestation trust-anchor — the per-publisher operator publishes BOTH the per-selector DKIM-public-key TXT-record AND the per-publisher BIMI l= SVG-Tiny PORTABLE-rendering target with a= VMC certificate URL; both cryptographic-trust-anchor publication disciplines share per-publisher key- rotation cadence and per-publisher-managed cryptographic-trust-anchor lifecycle; (ii) per-message DKIM-aligned-pass-rate- floor as per-publisher BIMI render-eligibility gate — the BIMI spec mandates the per- publisher domain achieve a per-publisher- per-receiver DMARC-aligned-pass-rate at the p=quarantine-OR-p=reject enforcement boundary as per-publisher BIMI deployment pre-condition — the per-publisher BIMI VMC issuance is gated on per-publisher DMARC-enforcement-mode commitment which is gated on per-publisher per-message DKIM-aligned-pass-rate floor; the BIMI-VMC spoke documents the per- publisher VMC-issuance pre-condition whose per-publisher DMARC-aligned-pass-rate floor is computed from the per-message DKIM- Signature byte-fidelity verification THIS page documents the cryptographic discipline of; (iii) per-receiver BIMI-renderer per-message DKIM-pass + DKIM-aligned + DMARC- aligned-pass-AND-policy-evaluation cascade as load-bearing per-message render-decision primitive — the per-receiver BIMI renderer per-message gate inspects per-message DKIM- Signature byte-verification result + per- message DKIM-aligned-pass + per-message DMARC-aligned-pass-AND-policy-evaluation before resolving the BIMI mark URL and validating the per-publisher VMC trust- chain — the per-message DKIM- Signature verification THIS page documents is the per-message granularity primitive feeding the per-receiver BIMI render- decision; the BIMI-VMC spoke documents the downstream per-receiver mark-rendering consumer contract; (iv) per-message DKIM-Signature byte-fidelity preservation across forwarder hops as load-bearing per- publisher BIMI-deliverability-through- forwarder primitive — DKIM survives some mailing-list and forwarding hops (relaxed canonicalization preserves header byte- fidelity past Subject: rewrites at certain mailing list MTAs); ARC-Authentication-Results AAR per-hop verdict preservation is the per-publisher BIMI-pass-through-forwarder operability primitive — the per-message DKIM- Signature byte-canonicalization choice THIS page documents directly impacts the per-publisher BIMI mark-render-rate at per-receiver forwarder-traversal boundaries; the BIMI-VMC spoke documents the per- publisher BIMI-deliverability-through- forwarder operational discipline whose upstream byte-fidelity primitive is the DKIM-Signature canonicalization choice. Read the BIMI-VMC-explained spoke alongside this DKIM-Signature-header reference whenever the operator scopes a per-publisher BIMI deployment plan — the per-message DKIM- Signature verification IS the per-message upstream cryptographic-trust-anchor primitive the per-publisher BIMI VMC X.509-Web-PKI render-eligibility gate depends on.
• SPF qualifiers explained — the CROSS-PROTOCOL-PARALLEL-PER-PUBLISHER- SENDER-SIDE-WIRE-FORMAT-VERDICT-MODIFIER-BYTE- SHAPE-AUTHORING-DISCIPLINE companion reference. Where THIS page documents the per-message DKIM-Signature header tag-value wire-format (the canonical v=1; a=rsa-sha256; d=<domain>; s=<selector>; c=relaxed/relaxed; h=From:To:Subject:Date; bh=<base64-body-hash>; b=<base64-signature> tag-list grammar per RFC 6376 §3.5 that the signing-MTA stamps into every outgoing message at the application layer), the SPF-qualifiers-explained spoke documents the STRUCTURALLY-PARALLEL per-publisher sender-side wire-format byte-shape at the SPF DNS publication-discipline layer (the four canonical mechanism-prefix qualifier bytes + Pass / - Fail / ~ SoftFail / ? Neutral per RFC 7208 §4.6.2 that prefix every a / mx / ip4 / ip6 / include / exists / all mechanism token in the publisher's v=spf1 TXT-record at the apex <org-domain> owner-name) across four cross-protocol verdict-modifier byte-authoring dimensions: (i) both wire-formats are per-publisher sender-side byte-precision-strict — each per-message DKIM-Signature tag-value byte deterministically maps to a per-receiver DKIM-verification verdict (Pass / Permerror / Temperror) at receiver-side hash recomputation time, just as each per-mechanism SPF qualifier-prefix byte deterministically maps to a per-receiver SPF-evaluation verdict (Pass / Fail / SoftFail / Neutral) at receiver-side check_host() evaluation time per RFC 7208 §4; (ii) both wire-formats feed the same downstream DMARC-aligned-pass verdict — the per-message application-layer DMARC verdict the receiver renders against the From: header author-domain is a logical-OR over DKIM-aligned-pass (driven by THIS page's DKIM-Signature wire-format) and SPF-aligned-pass (driven by the per-mechanism qualifier-prefix byte the SPF-qualifiers spoke documents); per-publisher sender-authentication health depends on BOTH per-message DKIM-Signature wire-format correctness AND per-mechanism SPF qualifier- prefix correctness at the same per-message evaluation event; (iii) both wire-formats publish to separate per-RR owner-names with the same per-publisher coordination discipline — the DKIM-Signature wire-format is keyed by the per-message s=<selector> tag pointing at the publisher's <selector>._domainkey. <d-tag-domain> DKIM public-key TXT-record, while the SPF qualifier-prefix bytes publish at the apex <org-domain> owner-name; per-publisher per-domain authoring tooling must keep BOTH RR-owner-name publication cadences synchronised across per-publisher per-domain DKIM-key-rotation and per-publisher per-domain SPF-mechanism-edit operations; (iv) both wire-formats share the same DMARC-record-tag-as-downstream-consumer coupling — the per-publisher _dmarc.<org-domain> TXT-record's p= / sp= / np= / adkim= / aspf= tag-values are evaluated against per-receiver per-message DKIM-aligned-pass verdicts (driven by THIS page's DKIM-Signature wire- format) AND SPF-aligned-pass verdicts (driven by the per-mechanism qualifier-prefix byte the SPF-qualifiers spoke documents) at every per-receiver per-message DMARC-policy-mode enforcement event. Read the SPF-qualifiers spoke alongside this DKIM-Signature wire- format reference whenever the per-publisher cross-protocol sender-authentication publication plan extends to a complete application-layer DKIM-and-SPF wire-format coordination plan — the per-mechanism SPF qualifier-prefix byte IS the application- layer per-publisher verdict-modifier primitive that runs ALONGSIDE the per-message DKIM-Signature tag-value byte discipline THIS page documents at every DMARC-aligned per-publisher sender-authentication publication event.
• DNS propagation timing — the PER-SELECTOR-PUBLIC-KEY-TXT-RECORD- DNS-PROPAGATION-AS-LOAD-BEARING-UPSTREAM- INFRASTRUCTURE-LAYER-PRECONDITION-FOR-PER- MESSAGE-DKIM-SIGNATURE-VERIFICATION companion reference. Where THIS page documents the per-message DKIM-Signature header tag-value wire-format at RFC 6376 §3.5 (the v=1; a=rsa-sha256; d=<domain>; s=<selector>; c=relaxed/relaxed; h=From:To:Subject:Date; bh=<base64-body-hash>; b=<base64-signature> tag-list grammar the per-message verifier consumes), the DNS-propagation spoke documents the per-publisher per-selector public-key TXT record DNS-zone-authoritative-server-to- receiver-side-recursive-resolver propagation- completion timing whose per-receiver-resolver- cache TTL-bounded completion gates whether the per-message DKIM-Signature header THIS page documents can be cryptographically verified at receiver-side per-message verification time, across four per-selector- publication-to-per-message-verification- coupling dimensions: (i) per-selector- public-key-TXT-record-DNS-propagation-as- upstream-precondition-for-per-message-DKIM- verification — the per-message DKIM verifier at receiver-side resolves the <selector>._domainkey. <d-tag-domain> TXT record to retrieve the per-selector public key bytes the per-message b= tag cryptographic signature THIS page documents must verify against; receiver-side resolver- cache propagation-incompleteness during the per-selector publication window produces per-message dkim=temperror / dkim=permerror verdicts at receivers whose recursive resolvers have not yet propagated the publisher's new selector TXT record, even though the per-message DKIM-Signature header THIS page documents is cryptographically well-formed at the signing MTA; (ii) per-selector-TTL-budget-as- receiver-cache-staleness-window — the per-publisher per-selector public-key TXT record's TTL value (typically 3600s or 300s during rotation windows) directly bounds the per-receiver-resolver-cache staleness window during which an in-flight per-selector rotation produces per-message dkim=permerror verdicts at receivers whose recursive-resolver cache still holds the prior public-key bytes that no longer match the per-message b= tag's RSA-SHA-256 / Ed25519 signature THIS page documents the per-message signer stamps; (iii) per-selector- rotation-pre-publication-window-discipline — DKIM operators publishing a NEW selector TXT record at <new-selector>. _domainkey.<d-tag-domain> must WAIT for the per-receiver-resolver-cache propagation-completion window (one TTL cycle at minimum, ideally three for worldwide cache convergence) BEFORE rotating the signing MTA's selector to emit per-message DKIM-Signature headers with the new s= tag value, ensuring receiver-side per-message verification of the per-message b= tag THIS page documents reliably resolves the matching per-selector public-key TXT record; (iv) per-selector-revocation-post- rotation-grace-period — the per-publisher per-selector revocation discipline RETAINS the old-selector TXT record at its publication zone-location for a grace period spanning the longest in-flight receiver-side resolver-cache TTL, allowing per-message DKIM-Signature headers with the old s= tag value (still in flight across slow-store-and-forward MTA relays) to verify against the matching per-selector public key the receiver-side resolver-cache still holds — without the per-selector-revocation post-rotation grace period, in-flight per-message DKIM-Signature headers THIS page documents would produce per-message dkim=permerror verdicts at receivers whose resolver-cache has already evicted the rotated-away public key. Read this WITH the DKIM-signatures wire-format reference when the publisher's per-selector publication / rotation / revocation discipline reaches the operator's queue: THIS page documents the per-message cryptographic-signature wire-format the receiver-side verifier consumes, the DNS- propagation spoke documents the INFRASTRUCTURE- LAYER propagation-timing discipline whose per-receiver-resolver-cache TTL-bounded completion gates whether the per-message DKIM-Signature header THIS page documents can be verified at receiver-side per-message verification time.
• DANE explained — the per-publisher per-MX DANE TLSA- record byte-grammar publication-discipline companion to this DKIM-Signature byte- grammar reference. Where THIS page documents the RFC 6376 §3.5 per-message DKIM-Signature header byte-grammar (v=1 version, a=rsa-sha256 algorithm, d=<domain> signing-domain identifier, s=<selector> selector, c= canonicalization, h= signed-headers list, bh= body-hash, b= signature value, t= / x= timestamp tags), the DANE- explained spoke is the PER-PUBLISHER-PER-MX- RFC-6698-RFC-7672-TLSA-RECORD-BYTE-GRAMMAR- PUBLICATION reference documenting the per-MX TLSA-record byte-grammar (the certificate usage field with values 0 / 1 / 2 / 3 governing CA-constraint vs service-cert-constraint vs trust-anchor vs domain-issued-cert binding semantics, the selector field with values 0 / 1 governing full-cert vs SubjectPublicKeyInfo binding, the matching type field with values 0 / 1 / 2 governing exact vs SHA-256-hash vs SHA-512-hash association, the certificate association data hex-encoded cryptographic-anchor value), the per-MX-host _25._tcp.<mx-host> TLSA publication coordinate, and the DNSSEC zone- signing prerequisite that establishes the per-MX cryptographic-trust-anchor binding gate at the transport layer. Four CROSS- LAYER-CRYPTOGRAPHIC-BYTE-GRAMMAR-PUBLICATION- COUPLING dimensions the DANE-explained spoke documents: (i) per-publisher per- domain cryptographic-anchor byte-grammar publication-discipline parallel at distinct cryptographic layers — both the per-message DKIM-Signature header byte- grammar this page documents and the per-MX TLSA-record byte-grammar DANE documents are per-publisher per-domain cryptographic- anchor-publication byte-grammar references — DKIM at the application layer (per-message signature header byte-grammar), DANE at the transport layer (per-MX TLSA-record byte- grammar); (ii) per-publisher per- selector vs per-publisher per-MX-host cryptographic-anchor publication-coordinate parallel — DKIM publishes per- selector key-records at <selector>._domainkey.<d-domain> while DANE publishes per-MX TLSA-records at _25._tcp.<mx-host> — both are per-publisher per-domain authoritative- DNS-zone cryptographic-anchor publication- coordinate primitives at distinct cryptographic layers; (iii) per- publisher per-selector cryptographic- algorithm choice byte-grammar vs per-MX TLSA-matching-type cryptographic-algorithm choice byte-grammar parallel — the DKIM a=rsa-sha256 vs a=ed25519-sha256 per-selector cryptographic-algorithm choice this page documents parallels the DANE matching type SHA-256 vs SHA- 512 per-MX cryptographic-hash-algorithm choice — both are per-publisher per-domain cryptographic-algorithm-choice publication byte-grammar primitives; (iv) per- message DKIM-signature-verification gate vs per-MX TLSA-record verification gate cross- layer composition — the per-message DKIM-Signature verification produces the per-message application-layer DKIM-aligned- pass verdict that DMARC consumes, while the per-MX TLSA-record verification produces the per-receiver-MX transport-layer trust-anchor verdict that STARTTLS-upgrade consumes — together they form the cross-layer cryptographic-anchor-verification-gate composition every per-publisher per-domain complete-stack authentication discipline depends on. Read the DANE-explained spoke alongside this DKIM-Signature byte-grammar reference when AUDITING the per-publisher per-domain cross-layer cryptographic-anchor byte-grammar publication-discipline that composes per-message DKIM-Signature header byte-grammar publication with per-MX TLSA- record byte-grammar publication into the per-publisher per-domain complete-stack cryptographic-trust-anchor publication discipline.
• MTA-STS explained — the per-publisher per-policy-domain transport-layer MTA-STS policy-publication- discipline companion to this per-message DKIM-Signature header byte-grammar reference. Where THIS page documents the RFC 6376 §3.5 per-message DKIM-Signature header byte-grammar (the v=1 / a=rsa-sha256 / d=<domain> / s=<selector> / c=relaxed/relaxed / h=From:To:Subject:Date:... / bh=<body-hash> / b=<sig> tag-and-value sequence the per-publisher per-selector DKIM-signing infrastructure emits) at the application-layer per-message message- authenticity-and-integrity publication boundary, the MTA-STS-explained spoke is the PER-PUBLISHER-PER-POLICY-DOMAIN- TRANSPORT-LAYER-MTA-STS-POLICY-PUBLICATION reference documenting the RFC 8461 per- publisher per-policy-domain _mta-sts.<d> TXT-RR publication + HTTPS-policy-host file publication + per-policy-domain mode: enforce commit choice publication discipline at the per-hop transport-layer SMTP STARTTLS enforcement boundary. Four CROSS-LAYER-PUBLICATION- DISCIPLINE coupling dimensions the MTA-STS-explained spoke documents: (i) per-publisher per-domain application-layer per-message-byte- publication discipline parallel to transport-layer per-hop-policy-byte- publication discipline at distinct protocol layers — both the per- message DKIM-Signature header byte-grammar publication discipline THIS page documents (the application-layer per-message message-authenticity-and-integrity primitive whose per-message byte-sequence the per-selector public-key cryptographically binds) and the per- publisher per-policy-domain MTA-STS- policy file byte-grammar publication discipline the spoke documents (the transport-layer per-hop confidentiality- and-MITM-resistance primitive whose per-policy-file byte-sequence the per- receiver MTA-STS-policy-discovery consumes) are per-publisher per-domain byte-grammar publication primitives at distinct protocol layers that COMPOSE at the per-publisher per-domain complete- stack authentication-and-encryption deliverability posture boundary; (ii) per-publisher per-domain cryptographic-trust-anchor publication parallel at distinct cryptographic-discipline scopes — both the per-publisher per-selector DKIM public-key TXT-RR (the application- layer per-message-signature trust-anchor the per-message DKIM-Signature b=-tag verification consumes) and the per-publisher per- policy-domain MTA-STS-policy-host TLS cert (the transport-layer per-hop Web-PKI trust-anchor the per-receiver MTA-STS-policy HTTPS-fetch consumes) are per-publisher per-domain cryptographic- trust-anchor publication primitives at distinct cryptographic-discipline scopes; (iii) per-publisher per-domain per-message-signed-bytes-vs-per-session- encrypted-bytes scope parallel at distinct protocol layers — the per-message DKIM-Signature byte-grammar publication discipline THIS page documents commits the per-message signed-bytes integrity-scope at the application layer (the per-message header + body byte-sequence the per- selector DKIM-Signature b=-tag binds), and the per- publisher per-policy-domain MTA-STS- policy publication discipline the spoke documents commits the per-session encrypted-bytes confidentiality-scope at the transport layer (the per-SMTP- session payload bytes the per-policy- domain MTA-STS-enforced STARTTLS protects); (iv) per-publisher per-domain receiver-side per-message verdict composition discipline at the per- receiver application-layer-and- transport-layer verdict-composition boundary — the per-message receiver-side DKIM-Signature verification outcome the per-message byte-grammar verification algorithm THIS page documents produces composes operationally with the per-receiver MTA-STS-enforced STARTTLS-accept-or- reject outcome the per-policy-domain MTA-STS-policy discipline the spoke documents produces at the per-receiver per-message application-layer-plus- transport-layer composite verdict- composition boundary. Read THIS page when AUTHORING the per-publisher per- message DKIM-Signature header byte- grammar publication discipline; read the MTA-STS-explained spoke when CO- AUTHORING the per-publisher per-policy- domain MTA-STS transport-layer policy- publication discipline whose per-policy- file mode: enforce commit composes operationally with the application-layer DKIM-Signature header byte-grammar publication discipline THIS page documents.
• MTA-STS for Microsoft 365 — the LOAD-BEARING per-M365-tenant per- custom-domain PER-M365-TENANT-MTA-STS- PUBLICATION-AS-PER-TENANT-PER-CUSTOM- DOMAIN-TRANSPORT-LAYER-PEER-OF-PER- MESSAGE-DKIM-SIGNATURE-HEADER- APPLICATION-LAYER-PUBLICATION-DISCIPLINE companion documenting the per-M365-tenant per-custom-domain MTA-STS publication tutorial — the per-tenant _mta-sts.<d> TXT-RR version + policy ID publication, the per-tenant https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication, the per-tenant mode: enforce policy-mode choice. Where THIS page documents the RFC 6376 §3.5 per-message DKIM-Signature header byte-grammar publication (the v= version tag, the a= signature algorithm tag, the c= canonicalization- mode tag, the d= signing- domain tag, the s= selector tag, the h= signed-header- list tag, the bh= body-hash tag, the b= signature-data tag, the per-message verification flow that retrieves the per-publisher per- selector key record from <s>._domainkey.<d>), the MTA-STS-for-M365 spoke documents the per-M365-tenant per-custom-domain TRANSPORT-LAYER MTA-STS publication discipline — the per-tenant per-custom- domain TRANSPORT-LAYER peer of the per- message APPLICATION-LAYER DKIM-Signature header byte-grammar publication discipline this page documents. The layered-pair: the per-message DKIM- Signature header travels in the application-layer message-body envelope; the per-tenant MTA-STS publication forces the receiver-side transport-layer SMTP session to TLS-fail-closed against the per-tenant inbound MX cone (M365's *.mail.protection.outlook.com), TOGETHER closing both the per-message APPLICATION-LAYER tampering attack surface (DKIM-signature-verification gates) AND the per-message TRANSPORT- LAYER eavesdropping + downgrade attack surface (MTA-STS-enforced STARTTLS gates) at the per-tenant per-custom-domain per-receiver-MX layered-protection boundary. Read THIS page when AUTHORING the per-message APPLICATION-LAYER DKIM- Signature header byte-grammar; read the MTA-STS-for-M365 spoke when COMPLEMENTING the application-layer DKIM-Signature publication with the per-M365-tenant per-custom-domain TRANSPORT-LAYER MTA- STS publication discipline at the per- tenant per-custom-domain LAYERED- PROTECTION publication-discipline boundary.
• DMARC troubleshooting — the PER-PUBLISHER-PER-DOMAIN-DKIM- VERDICT-OPERATIONAL-DIAGNOSIS companion to this DKIM-Signature header byte-grammar reference. Where THIS page documents the per-message DKIM-Signature header byte-grammar (the v=1 mandatory version-tag, the a=rsa-sha256 / a=ed25519-sha256 algorithm-tag, the d=<signing-domain> signing-identity tag, the s=<selector> per-selector key-lookup tag, the h=<header-list> signed-headers list, the bh=<body-hash> canonicalised-body hash, the b=<signature> cryptographic signature, the c=<header/body> canonicalisation algorithm-pair, the optional l=, t=, x=, i=, q= tags), the DMARC troubleshooting spoke is the PER-VERDICT-DIAGNOSIS- OF-DKIM-FAIL-AND-DKIM-PERMERROR companion documenting how each DKIM-Signature header tag THIS page catalogues is consumed as the per- message diagnostic payload during per-publisher per-domain DKIM- verdict-fail root-cause attribution. The composition operates through the per-tag-per-failure-mode mapping the troubleshooting decision-tree catalogues: (i) d= tag misalignment with RFC5322.From-domain — diagnosed via the per-message Authentication-Results header's dkim=pass verdict on a non-aligned signing-domain → dmarc=fail alignment- cascade; (ii) s= tag pointing to a non-publishing selector — diagnosed via the per-receiver DNS TXT-RR query at <selector>._domainkey.< d-domain> returning NXDOMAIN → dkim=permerror verdict; (iii) bh= body-hash mismatch — diagnosed via a per-MTA message-body-rewrite event (mailing- list footer append, content-filter body modification, MIME-boundary regeneration); (iv) b= cryptographic signature verification failure — diagnosed via the per- signer key-pair-management audit; (v) c= canonicalisation- mismatch — diagnosed via the simple/simple vs relaxed/relaxed publisher- side configuration audit; (vi) l= body-length-cap tag accepting attacker-appended content — diagnosed via the per- message replay-attack-detection audit. Read THIS page when AUTHORING the per-publisher per-domain DKIM- Signature header byte-grammar publication discipline; read the DMARC-troubleshooting spoke when DIAGNOSING per-message dkim=fail / dkim=permerror verdicts whose per-tag root-cause attribution depends on the per-tag byte-grammar THIS page documents at the per- publisher per-domain DKIM-verdict operational-diagnosis decision-tree boundary.
• SPF forwarding issues (the second-hop break) — the SPF-FORWARDER-INDUCED-BREAK-AS-CANONICAL- UPSTREAM-PRESSURE-FOR-DKIM-SIGNATURE-FORWARDER- SURVIVAL-DISCIPLINE companion to this DKIM- Signature header byte-anatomy reference. Where THIS page documents the per-publisher per- domain DKIM-Signature header byte-grammar (the canonical v=1; a=rsa-sha256; c=relaxed/relaxed; d=<domain>; s=<selector>; h=<signed-headers>; bh=<body-hash>; b=<signature> 14-tag grammar per RFC 6376 §3.5, the per-tag publisher-side publication discipline, and the per-tag receiver-side verification semantics), the SPF-forwarding-issues spoke is the CANONICAL-FORWARDER-SECOND-HOP-BREAK-SCENARIO companion documenting WHY the per-publisher per-domain DKIM-Signature header MUST be engineered for forwarder-hop survival — because forwarder-induced envelope-rewriting breaks the per-message SPF-aligned-pass leg, leaving the DKIM-Signature header as the SOLE DMARC-aligned- pass leg surviving every forwarder hop. The DKIM-Signature-vs-SPF-forwarding-issues relationship is per-tag-discipline-as-forwarder- survival-engineering: the per-publisher DKIM-Signature byte-grammar discipline THIS page architectures determines whether the per- message DKIM-aligned-pass leg survives the forwarder hop where SPF collapses. Four per- DKIM-Signature-tag-vs-forwarder-hop-survival coupling dimensions matter at the per- publisher per-domain DKIM-Signature-engineering boundary: (i) per-publisher c=<header- canonicalization>/<body-canonicalization> canonicalization-mode choice as forwarder- survival primitive — c=simple/simple is destroyed by any forwarder-injected whitespace mutation; c=relaxed/relaxed survives header-whitespace normalization and body-trailing-whitespace stripping that forwarders routinely apply; the per-publisher per-domain canonicalization-mode choice determines whether the DKIM-Signature SURVIVES the forwarder hop where SPF-aligned-pass breaks; (ii) per-publisher h=<signed- headers> header-list publication discipline as forwarder-survival primitive — oversigning stable headers (From, Subject, Date, To, Message-ID) and EXCLUDING forwarder- mutable headers (Received, Return-Path, Authentication-Results) prevents forwarder- injected header content from breaking the per-message signature recomputation at the second-hop receiver; (iii) per-publisher bh=<body-hash> body-hash computation discipline as forwarder-survival primitive — the body-hash is computed over the per-tenant canonicalized message body AT THE PUBLISHER but receiver-side verification recomputes the body-hash against the in-transit body; per-forwarder-injected footer content (mailing-list subscription footers, archive- URL footers, .forward-host appended notices) breaks the body-hash recomputation under either canonicalization mode but c=relaxed/relaxed body-mode survives mailing-list-manager whitespace-only body-mutations; (iv) per-publisher d=<domain> / s=<selector> identity binding as forwarder-survival anchor — the per-publisher per-domain d=-tag organisational-domain match with RFC 5322 From: persists across every forwarder hop unchanged, so the per-publisher per-selector public-key publication at <selector>._domainkey.<d-domain> remains the per-receiver verification target regardless of which forwarder hop the message traverses. Read THIS page when AUTHORING the per-publisher per-domain DKIM-Signature header byte-grammar publication discipline; read the SPF- forwarding-issues spoke when DIAGNOSING the canonical motivating scenario whose existence elevates the per-publisher per-domain DKIM-Signature header byte-grammar publication discipline THIS page architectures to LOAD- BEARING DMARC-aligned-pass forwarder-survival primitive at every forwarder-traversing send.
• DMARC for Google Workspace — the GOOGLE-WORKSPACE-TENANT-DKIM-CNAME- DELEGATED-SELECTOR-AS-CANONICAL-PER-TENANT- DKIM-SIGNATURE-HEADER-EMITTER companion to this DKIM-Signature header byte-anatomy reference. Where THIS page documents the per-message DKIM-Signature header tag anatomy (v=, a=, b=, bh=, c=, d=, h=, i=, l=, q=, s=, t=, x=, z=) and the byte-level cryptographic-signing discipline every per-publisher per-domain DKIM signer emits at the message-egress boundary, the Workspace-tenant spoke documents the per- Workspace-tenant per-custom-domain DKIM deployment topology where the google._domainkey.<tenant-domain> CNAME-delegated selector points at Google's per-tenant per-custom-domain managed public-key TXT record and the Workspace egress emits per-message DKIM- Signature headers with d=<tenant- domain> + s=google that THIS page's tag-by-tag byte-grammar reference decodes. The per-Workspace- tenant per-custom-domain DKIM-Signature header emission IS the per-tenant per- custom-domain canonical consumer of the DKIM-Signature header byte-grammar THIS page architectures at four Workspace- tenant-DKIM-deployment-vs-DKIM-Signature- header-byte-grammar coupling dimensions: (i) per-Workspace-tenant d=<tenant-domain> + s=google tag-pair as canonical per-tenant DKIM-Signature identifier- alignment-source — the per-Workspace- tenant per-custom-domain d=<tenant-domain> tag- value emitted by Google's egress signer IS the per-tenant per-custom-domain DKIM- identifier the per-receiver per-message DMARC alignment evaluator consults at the receiver-side DKIM-identifier-vs-RFC 5322 From: domain alignment-check boundary, coordinating the per-Workspace-tenant per-custom-domain DKIM-aligned-pass-rate floor THIS page's tag-grammar reference decodes; (ii) per-Workspace-tenant CNAME-delegated selector publication discipline as per-tenant DKIM key-rotation delegated-control surface — the per- Workspace-tenant per-custom-domain google._domainkey.<tenant- domain> CNAME publication DELEGATES per-tenant per-custom-domain DKIM key-rotation control to Google's managed per-tenant key infrastructure, so the per-Workspace-tenant operator publishes the CNAME ONCE and Google's per-tenant per-custom-domain managed rotation cadence operates the actual DKIM-private-key-rotation lifecycle THIS page documents at the byte-grammar publication layer; (iii) per-Workspace- tenant a=rsa-sha256 + RSA- 2048 key-size as Workspace-tenant DKIM- cryptographic-discipline floor — the per- Workspace-tenant per-custom-domain managed DKIM key-size selection (RSA-2048-minimum per RFC 8301) IS the per-Workspace-tenant per-custom-domain DKIM-cryptographic- discipline floor that defends the per- Workspace-tenant per-custom-domain DKIM- aligned-pass-rate floor against the DKIM- key-cryptanalysis attack-class catalogue; and (iv) per-Workspace-tenant c=relaxed/relaxed canonicalisation as forwarder-survival Workspace egress discipline — Google's per-Workspace-tenant per-custom-domain egress signer uses c=relaxed/relaxed canonicalisation by default, the canonicalisation algorithm-pair THIS page documents as the forwarder-survival canonical baseline, so the per-Workspace- tenant per-custom-domain DKIM-aligned- pass-rate floor through forwarders is preserved by the per-Workspace-tenant egress canonicalisation discipline the DKIM-Signature header byte-grammar reference THIS page architectures. Read THIS page when AUTHORING the per- publisher per-domain DKIM-Signature header byte-grammar publication discipline at the canonical signer-side reference layer; read the Workspace-tenant DMARC deployment spoke when AUDITING the per- Workspace-tenant per-custom-domain DKIM- aligned-pass-rate floor against the DKIM-Signature header byte-grammar THIS page documents at the per-Workspace- tenant per-custom-domain managed-egress DKIM-emission boundary.
• CAA records explained — the structurally parallel DNS-based cryptographic-identity-authority publication- discipline companion to this DKIM-Signature header cryptographic-identity-binding reference. Where THIS page documents the per-publisher per-selector DKIM DNS-based public-key- authority-binding via per-domain <selector>._domainkey.<domain> TXT-RR p=<public-key-bytes> publication, the CAA-records spoke documents the structurally parallel per-publisher per- domain DNS-based CA-authority-binding via per- domain <domain> CAA 0 issue "<ca-domain>" publication — both are per-publisher per-domain DNS-published cryptographic-identity-authority primitives at the per-domain zone-file commit- and-propagation boundary.
• Email authentication overview
• DMARC policy rollout
• Email authentication glossary
• TLS-RPT JSON aggregate-report format — the PER-PUBLISHER-PER-POLICY-DOMAIN-TLS-RPT-JSON-AGGREGATE-REPORT-FAILURE-DETAILS-PER-MX-HOST-PER-FAILURE-CLASS-ATTRIBUTION-STREAM-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-AGGREGATE-OBSERVABILITY-EVIDENCE-STREAM-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-SIGNATURE-HEADER-BYTE-GRAMMAR-APPLICATION-LAYER-PER-MESSAGE-AUTHENTICATION-EVIDENCE-STREAM companion at four per-publisher per-domain DKIM-Signature-application-layer-per-message-evidence-vs-TLS-RPT-transport-layer-per-day-per-MX-host-per-failure-class-evidence coupling dimensions: (i) per-publisher per-policy-domain TLS-RPT JSON aggregate-report failure-details[]/result-type/sending-mta-ip/receiving-mx-hostname per-day per-MX-host per-failure-class attribution stream per RFC 8460 §4.3 IS the load-bearing transport-layer aggregate-observability evidence-stream attributing per-publisher per-domain STARTTLS-strip / MTA-STS-violation / DANE-mismatch / certificate-host-mismatch transport-layer per-MX-host per-failure-class evidence — structurally parallel application-layer evidence-stream to per-publisher per-selector DKIM-Signature header-tag publication-discipline THIS page documents producing per-receiver per-message DKIM-verifier dkim=permerror/dkim=temperror/dkim=fail per RFC 8601 §2.7.1 verdict-stream surfacing in per-receiver per-day DMARC RUA auth_results/dkim/result attribution; (ii) per-publisher per-policy-domain TLS-RPT JSON aggregate-report policies[]/policy-type/policy-string per-policy attribution stream IS structurally parallel transport-layer per-policy publication-discipline reference to per-publisher per-selector DKIM-Signature header-tag publication-discipline (v=/a=/d=/s=/c=/bh=/b= tag-vocabulary) THIS page documents at the canonical signer-side reference layer — both per-publisher per-domain operator-side publication-discipline references coordinate at the per-publisher per-domain composite application-and-transport-layer publication-discipline-floor coordination boundary; (iii) per-publisher per-policy-domain TLS-RPT JSON aggregate-report summary/total-successful-session-count/total-failure-session-count per-day per-policy-domain composite-success-rate evidence-stream IS structurally parallel transport-layer per-day composite-success-rate evidence-stream to per-publisher per-domain DKIM-aligned-pass-rate floor evidence-stream the per-publisher per-selector DKIM-Signature header-tag publication-discipline THIS page documents the per-publisher per-selector application-layer per-message authentication-leg byte-grammar publication-discipline of feeds; (iv) per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format publication-discipline drift (malformed JSON / missing failure-details[] attribution / oversized aggregate-payload / non-conformant result-type vocabulary) directly opens per-publisher per-domain transport-layer-aggregate-observability per-day evidence-stream blackout-window structurally parallel to per-publisher per-selector DKIM-Signature header-tag publication-discipline drift (missing d= tag / malformed a= algorithm-identifier / truncated b= signature-bytes past RFC 6376 §3.5 byte-boundary) the per-publisher per-selector DKIM-Signature header-tag primer THIS page documents the per-publisher per-selector application-layer per-message authentication-leg byte-grammar publication-discipline-floor of catalogues against — together the per-publisher per-selector DKIM-Signature header byte-grammar publication-discipline THIS page documents AND the per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format publication-discipline compose the per-publisher per-domain composite application-and-transport-layer per-message-and-per-day aggregate-evidence-stream-floor coordination boundary.
• DMARC records explained
• Email deliverability — the inbox-placement companion to this DKIM-Signature header explainer. A valid, DMARC-aligned DKIM signature is one of the strongest positive deliverability signals a mailbox provider reads: it cryptographically binds the message to the signing domain whose sending reputation accrues over time, so the d= / s= / b= header-tag publication-discipline this page documents directly underwrites the domain- reputation leg of inbox placement. Conversely a body-hash-mismatch or missing-selector dkim=fail strips that positive signal and depresses placement. Read the deliverability spoke to see where DKIM-Signature validity sits in the broader inbox-placement reputation model.
• DMARC monitoring — the RUA aggregate stream is where the d=/s= signature validity this page documents becomes observable at scale: every report row carries a per-message dkim= verdict and alignment result, so monitoring is how you confirm a new selector signs cleanly and catch a body-hash regression before it depresses the aligned-pass rate. Read the monitoring spoke to set up the ongoing watch over your DKIM-Signature health.
• SPF 10-DNS-lookup limit — the OTHER-DMARC-LEG-DNS-PUBLICATION-DISCIPLINE companion to this DKIM-Signature primer: the DKIM-Signature this page documents is verified by fetching the <selector>._domainkey.<domain> TXT-RR — a single, bounded DNS lookup — whereas the SPF leg of the same DMARC composite consumes an include:-cascade DNS-lookup budget that silently collapses to spf=permerror once it crosses the §4.6.4 cap. When that happens the DMARC composite-disjunction per RFC 7489 §3.1.1 survives only on the DKIM-aligned leg this page documents, so robust DKIM signing is the resilience hedge against an SPF leg that has overrun its lookup budget. Read the SPF-10-DNS-lookup-limit spoke to understand the budget failure mode that shifts the whole DMARC verdict onto the DKIM signature.
• Microsoft SNDS + JMRP monitoring — a valid DKIM signature does not outrank a bad IP reputation at Outlook.com: SNDS shows how Microsoft's consumer network actually graded each sending IP (GREEN/YELLOW/RED) and JMRP surfaces the Junk clicks behind a degraded verdict.

Parse a DKIM-Signature now

DMARC Analyzer parses every DKIM-Signature header in uploaded messages and aggregate reports via includes/EmailHeaderParser.php, surfacing the tag-by-tag breakdown on the Header Analyzer view. The Email Header Analyzer at header_analyzer.php accepts any raw message headers and produces a parsed view of every DKIM-Signature instance — full tag inventory, base64 integrity checks, and red-flag indicators for malformed tag values. The Domain Security Checker validates the public-key TXT side: confirms the d= and s= referenced by any DKIM-Signature actually resolve to a valid record.

Sign up — Free plan Parse a DKIM-Signature header