DMARC Analyzer

TL;DR

• DKIM canonicalization is the normalisation step a DKIM signer applies to the message headers and the message body before hashing, so the signature survives the typical in-transit modifications (whitespace folding, continuation-line re-breaking, trailing-whitespace normalisation) that intermediate MTAs perform on the message. Defined in RFC 6376 section 3.4.
• Two algorithms × two surfaces = four combinations. RFC 6376 §3.4 defines two canonicalization algorithms (simple and relaxed) and applies them independently to message headers and message body, producing four canonicalization combinations declared by the c= tag of the DKIM-Signature header in the form c=<header-canon>/<body-canon>.
• Production guidance: use c=relaxed/relaxed for every modern DKIM deployment. Relaxed canonicalization survives whitespace folding, continuation-line re-breaking, and trailing-whitespace normalisation; simple canonicalization does not. Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailgun, Mailchimp, Postmark, SparkPost, and every modern SaaS sender default to c=relaxed/relaxed.
• The RFC default is c=simple/simple — when the c= tag is absent, RFC 6376 §3.5 specifies simple/simple as the default. This is a historical anomaly preserved for backward compatibility with the DomainKeys predecessor (RFC 4870) and is almost never the right production choice. Every modern signer explicitly emits c=relaxed/relaxed.
• The four canonicalization combinations: (1) c=simple/simple — exact bytes, fragile, the RFC default rarely used in production; (2) c=simple/relaxed — exact headers + transit-tolerant body, niche use case; (3) c=relaxed/simple — transit-tolerant headers + exact body, occasionally used for body-integrity-critical mail; (4) c=relaxed/relaxed — transit-tolerant on both surfaces, the production standard.
• The seven most common mismatch causes are: (1) forwarder whitespace folding, (2) mailing-list footer injection, (3) content- transform middleware (antivirus, DLP, link-rewriting, URL-tracking), (4) transfer-encoding changes, (5) MIME re-encoding, (6) trailing CRLF normalisation, (7) Subject-prefix rewriting by mailing lists. Each is documented in section 8 with detection signatures and operational mitigations.
• The bh= tag is the canonicalized-body hash; the b= tag is the signature over the canonicalized headers plus the bh= value. A body hash mismatch (commonly reported as dkim=fail (body hash mismatch) in the Authentication-Results header per RFC 8601) means the body was modified in transit; a signature mismatch (dkim=fail (signature verification failed)) means a signed header was modified.

1. Overview: why DKIM defines canonicalization

A DKIM signature is a cryptographic hash of the canonicalized message (selected headers + body) signed with the signing domains private key. The verifier recomputes the hash over the canonicalized received message and compares it to the signature. For this scheme to work, the signer and the verifier MUST agree on the exact byte sequence they are hashing.

The problem: mail in transit gets touched. The canonical list of in-transit modifications email architects accept as inevitable:

1. Line-length folding. RFC 5322 section 2.1.1 recommends header lines no longer than 78 characters. Long lines get folded at column 78 (FWS — folding whitespace inserted) and refolded at different break points by intermediate MTAs. The visible header content is unchanged but the byte sequence is not.
2. Whitespace normalisation. Some MTAs collapse runs of internal whitespace in headers to single spaces; some preserve them verbatim. Some strip trailing whitespace before the CRLF; some keep it. The semantic content of the header is unchanged but the byte sequence is not.
3. Trailing empty lines in the body. Some MTAs append a trailing empty line to the body; some strip them; some normalise runs of trailing empty lines to a single CRLF. The body content is unchanged but the byte sequence is not.
4. Continuation-line re-breaking. A multi-line header (e.g. a long Subject: that wraps) may be re-broken by an intermediate MTA at a different word boundary. The header content is unchanged but the byte sequence is not.
5. Tab-to-space conversion. Some MTAs convert tabs to spaces in headers (one tab becomes one or more spaces). The visible content is similar but the byte sequence is not.
6. Date-header insertion. An MTA may add a Date: header if the sender omitted one. Adding a header does not affect signed headers already in the message, but a signer that named Date: in the h= list expecting the senders Date: will see an MTA-inserted Date: at verification time.
7. Message-ID rewriting. Some MTAs rewrite the Message-ID: header when the sender omitted one or when the sender used a non-canonical format.

Without canonicalization, any of these benign modifications would invalidate every DKIM signature on every message that passed through a transforming MTA. With canonicalization, the signer and the verifier both apply a deterministic normalisation that maps the modified byte sequence back to the same canonical form, so the hash matches and the signature verifies.

RFC 6376 section 3.4 defines two algorithms with deliberately different trade-offs:

• simple — minimal normalisation, fragile, exact-byte. Survives ONLY the most trivial mail-in-transit modifications (a single trailing empty line in the body). Any byte change beyond that invalidates the signature. Useful when bit-exact identity must be preserved.
• relaxed — robust normalisation. Header field names lower-cased, whitespace runs collapsed, continuation lines unfolded, trailing whitespace stripped. Survives the typical in-transit modifications. The production default for every modern signer.

The two algorithms apply independently to headers and body, so a DKIM signer can choose any of the four combinations. The c= tag of the DKIM-Signature header (RFC 6376 section 3.5) declares the choice in the form c=<header-canon>/<body-canon>.

2. The four canonicalization combinations

Two algorithms (simple, relaxed) applied to two surfaces (headers, body) produces four combinations. Each has a documented use case, but in practice production deployments concentrate on one combination almost exclusively.

The 95-percent rule: in real-world DKIM signing-corpus surveys, c=relaxed/relaxed accounts for approximately 95% of all DKIM signatures. The remaining ~5% is mostly legacy senders that have not migrated from the RFC default, plus a handful of intentional niche deployments. Operators auditing their own outbound DKIM should aim for 100% c=relaxed/relaxed across all signers.

3. Header canonicalization algorithms

RFC 6376 section 3.4 defines two header canonicalization algorithms. Each transforms the signed headers (those named in the h= tag of the DKIM-Signature header) into a deterministic byte sequence before hashing.

3.1 The simple header algorithm (RFC 6376 §3.4.1)

Definition: The simple header canonicalization performs essentially no transformation on signed headers. The header lines are presented to the hash function exactly as they appear in the message, byte-for-byte. The only rule is that no normalisation is applied at all.

Algorithm: Per RFC 6376 §3.4.1, the simple header canonicalization algorithm "does not change header fields in any way." Each signed header field (named in the h= tag) is passed to the hash function in the order listed, with its original CRLF terminator, exactly as it appeared in the message when the signer received it. The DKIM-Signature header itself is included last, with the b= tag value temporarily replaced by an empty string for the hash computation (the b= value is what the hash produces).

Use case: Niche. The simple header canonicalization is intended for mail flows where exact-byte header integrity must be preserved — notarised mail, legal-discovery archives, some end-to-end signed communication systems that do not traverse transforming intermediaries. The RFC default is simple only for backward compatibility with the DomainKeys predecessor; modern deployments should not rely on the default.

Pitfalls: (1) Any intermediate MTA that folds long header lines at a different column than the signer used will invalidate the signature — and most production MTAs do exactly that. (2) Tab-to-space conversion in headers (common in Microsoft Exchange transit) invalidates the signature. (3) Continuation-line re-breaking invalidates the signature. (4) Header case transformations (a verifier that lower-cases the Subject: to subject: before signing math) interact badly with simple because no case-normalisation is applied. The cumulative effect is that simple header canonicalization fails to verify on a substantial fraction of real-world mail flows even when the semantic message is unchanged.

3.2 The relaxed header algorithm (RFC 6376 §3.4.2)

Definition: The relaxed header canonicalization applies four normalisations to each signed header: header field name lower-casing, continuation-line unfolding, internal-whitespace-run collapsing, and leading/trailing whitespace stripping. The combined effect produces a canonical byte sequence that survives the typical in-transit modifications.

Algorithm: Per RFC 6376 §3.4.2, the relaxed header canonicalization algorithm transforms each signed header as follows:

1. Convert all header field names to lower-case. "Subject: Hello" becomes "subject: Hello". The colon and the value are not affected.
2. Unfold all header continuation lines. A header that spans multiple physical lines (folded with CRLF + WSP per RFC 5322 section 2.2.3) is rejoined into a single logical line. The CRLF + WSP sequence at the fold point is replaced with the unfolded form.
3. Convert all runs of WSP (whitespace, SP or HTAB) to a single space. Multiple consecutive spaces or tabs anywhere in the header value become a single SP character.
4. Delete any WSP before and after the colon that separates the header field name from its value. The colon itself is retained.
5. Strip all trailing WSP from the header value (between the last non-whitespace character and the CRLF terminator).
6. Terminate every signed header with a single CRLF; only the DKIM-Signature header itself, which is hashed last, goes to the hash function without a trailing CRLF (RFC 6376 §3.7).

Use case: Production. The relaxed header canonicalization is the default choice for every modern DKIM deployment. It survives line-length folding, continuation-line re-breaking, whitespace normalisation, and tab-to-space conversion — the four most common in-transit header modifications. Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailgun, Mailchimp, Postmark, SparkPost, Klaviyo, Constant Contact, HubSpot, OpenDKIM, Postfix dkim-milter, and every modern SaaS sender emit c=relaxed/... on outbound mail.

Pitfalls: (1) The header field name lower-casing rule means the verifier must lower-case received header names before lookup — a verifier that compares "Subject:" to "subject:" case-sensitively will fail to find the signed header. (2) The whitespace-run collapsing means a verifier MUST collapse multiple internal spaces; verifiers that preserve them will compute a different hash and reject the signature. (3) The unfolding rule means a verifier MUST unfold continuation lines BEFORE collapsing whitespace; doing the operations in the wrong order produces a different hash. (4) The l= tag interaction (see section 6) applies only to the body, not the headers — there is no header-length truncation.

4. Body canonicalization algorithms

RFC 6376 section 3.4 defines two body canonicalization algorithms. Each transforms the message body into a deterministic byte sequence before hashing. The result is hashed with the algorithm declared in the a= tag (typically rsa-sha256 or ed25519-sha256 per RFC 8463) and the resulting hash is base64-encoded and placed in the bh= tag of the DKIM-Signature header.

4.1 The simple body algorithm (RFC 6376 §3.4.3)

Definition: The simple body canonicalization performs almost no transformation. The body bytes are presented to the hash function exactly as they appear, with the single rule that consecutive trailing empty lines at the very end of the body are collapsed to a single CRLF.

Algorithm: Per RFC 6376 §3.4.3, the simple body canonicalization algorithm applies one transformation:

1. Collapse consecutive trailing empty lines at the very end of the body to a single CRLF. If the body ends with ...content\r\n\r\n\r\n\r\n, the canonicalized form is ...content\r\n (the final CRLF terminator is retained; the extra trailing empty CRLFs are stripped). If the body is empty, the canonicalized form is a single CRLF.

All other body bytes — including internal empty lines, internal whitespace, MIME boundaries, and every byte of every line — are preserved exactly as received.

Use case: Niche. The simple body canonicalization is intended for mail flows where exact-byte body integrity must be preserved — signed contracts, signed transactional receipts where any body byte change must invalidate the signature, end-to-end notarised mail. The RFC default is simple only for backward compatibility.

Pitfalls: (1) Any intermediate MTA that adds a footer to the body (mailing-list subscribe/unsubscribe links, anti-virus banners, DLP modifications) invalidates the signature. (2) Any MTA that re-wraps lines (a transfer-encoding change from quoted-printable to 7bit or vice versa, a MIME re-encoding that adjusts line lengths) invalidates the signature. (3) Trailing-whitespace differences (some MTAs strip trailing spaces from lines; some preserve them) invalidate the signature. (4) The l= tag (see section 6) can mitigate footer-injection but introduces a security weakness where post-cutoff content is unsigned. The cumulative effect is that simple body canonicalization fails to verify on a substantial fraction of real-world mail flows.

4.2 The relaxed body algorithm (RFC 6376 §3.4.4)

Definition: The relaxed body canonicalization applies three normalisations to the body: internal-whitespace-run collapsing, trailing-whitespace stripping, and trailing-empty-line stripping. The combined effect produces a canonical byte sequence that survives the typical in-transit modifications without introducing the l= tag security weakness.

Algorithm: Per RFC 6376 §3.4.4, the relaxed body canonicalization algorithm applies three transformations:

1. Within each body line, reduce all runs of WSP (whitespace, SP or HTAB) to a single space. Multiple consecutive spaces or tabs anywhere in the line become a single SP character.
2. Strip all trailing WSP from each body line (between the last non-whitespace character and the CRLF terminator).
3. Strip all trailing empty lines at the end of the body (including any trailing CRLF that would follow a final empty line). If the body is empty after this transformation, the canonicalized form is the empty string.

Use case: Production. The relaxed body canonicalization is the default for every modern DKIM deployment. It survives whitespace folding within lines, trailing-whitespace differences, and trailing-empty- line variations — the three most common in-transit body modifications. Combined with relaxed header canonicalization, c=relaxed/relaxed is the production standard.

Pitfalls: (1) Even relaxed canonicalization does NOT survive footer injection (mailing-list subscribe/unsubscribe links added to the body) — any byte added to the canonical body changes the hash. The mitigation is From-header munging on the list side, ARC sealing per RFC 8617, or the l= partial-body tag (with its security trade-off). (2) The whitespace-run collapsing applies WITHIN lines but does NOT collapse newlines — a verifier that confuses internal whitespace with line boundaries will compute a different hash. (3) The trailing-empty-line stripping applies at the end of the body but does NOT remove internal empty lines — a verifier that strips ALL empty lines will compute a different hash. (4) MIME boundary lines are body content per the RFC and are subject to the same canonicalization — verifiers that special-case MIME boundaries will compute a different hash.

5. The c= tag: declaring canonicalization in the signature

The c= tag in the DKIM-Signature header (RFC 6376 section 3.5) declares the two canonicalization algorithms the signer used. The verifier MUST apply the same algorithms to reproduce the signers byte sequence and verify the hash.

Syntax: c=<header-canon>/<body-canon> where each value is either simple or relaxed. The four possible values:

• c=simple/simple — exact-byte headers + exact-byte body (with trailing CRLF collapse).
• c=simple/relaxed — exact-byte headers + relaxed body.
• c=relaxed/simple — relaxed headers + exact-byte body.
• c=relaxed/relaxed — relaxed headers + relaxed body. Production standard.

Default: If the c= tag is absent from the DKIM-Signature header, the default value is simple/simple per RFC 6376 section 3.5. This default is widely considered a historical anomaly preserved for backward compatibility with the DomainKeys predecessor (RFC 4870); modern signers should ALWAYS emit an explicit c= tag.

Example DKIM-Signature header with explicit c= tag (the production-standard form):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=k202604;
        h=from:to:subject:date:message-id;
        bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
        b=AuyqDpoCYHKNdvOOO7yvgblHA9zMlqNXBOFv5WGdmZuTLrRyYbWO9JX
         O+ZA7vNRoYZpiTKuBVhFGRMcCxw6lQ4WAEBvfh5KuKjLrhgGPyiK1pdj
         oqUlnxqGQQfqLR3PpO5VC5W4nQzWfRtLwiR3PpO5VC5W4nQzWfRtLwiR=

The c=relaxed/relaxed tag in this example tells the verifier to apply relaxed canonicalization to both the signed headers (the h= list: from, to, subject, date, message-id) and the message body before recomputing the hash. The bh= tag is the base64-encoded body hash; the b= tag is the base64-encoded signature over the canonicalized headers plus the bh= value.

Operator guidance: Audit your outbound DKIM signatures with an Authentication- Results-aware tool (the DMARC Analyzer Email Header Analyzer parses every signed-header tag including c=). Every modern signer should emit c=relaxed/relaxed; if you see c=simple/simple on your own outbound mail, your signer is probably misconfigured or using a legacy default.

6. The l= tag: partial body signing and its risks

The l= tag in the DKIM-Signature header (RFC 6376 section 3.5) is an OPTIONAL signed-body- length declaration. When present, l=N tells the verifier to canonicalize and hash ONLY the first N octets of the canonicalized body, ignoring everything after that.

Intended use case: Allow mailing- list forwarders to append a footer (subscribe/unsubscribe links, list-info banner) without breaking the signature. The signer sets l= to the original canonicalized body length, the list appends a footer, the verifier hashes only the first l octets (which are unchanged), and the signature verifies.

The security weakness: The l= tag creates an asymmetry between what the signature attests and what the recipient sees. An attacker who intercepts a signed message can append arbitrary content after the l= cutoff. The appended content is UNSIGNED but to a casual reader appears to be part of the signed message — and the signature still validates. The canonical attack: an attacker intercepts a signed transactional message confirming a $100 payment, appends "...PS your account has been compromised, please transfer $10000 to acct 1234-5678 immediately", and forwards the message. The signature still validates because the original $100 confirmation bytes are unchanged in the first l octets. The recipient sees a DKIM-verified message that appears to authentically instruct a fraudulent transfer.

Why modern signers omit l=: The security weakness above outweighs the operational benefit. Mailing lists that need to append footers almost always also rewrite the Subject: or From: headers (which break header canonicalization regardless of l=), so the l= tag does not actually rescue the signature. The canonical mitigations for mailing-list breakage are From-header munging (rewrite the From: to the lists own domain and re-sign with the lists DKIM), ARC sealing per RFC 8617 (preserve the original authentication results across modifications), or accepting the DKIM failure and relying on SPF + alignment.

Operator guidance: Do NOT enable the l= tag in your signer unless you have an explicit threat-modelled use case where the asymmetry is acceptable. The default in every modern signer (OpenDKIM, Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailgun, Mailchimp, Postmark, SparkPost) is to omit l= entirely — sign the entire canonicalized body, accept the forwarder breakage when it happens, and rely on the operational mitigations.

7. The seven most common body-hash mismatch causes

Across thousands of DKIM verification failures analysed in DMARC aggregate-report data, the same seven mismatch causes recur. Each cause states the in-path modifier, its detection signature in the Received headers, and the operational mitigation.

7.1 Forwarder whitespace folding

Cause: An intermediate forwarder (an iCloud Mail Drop, a Gmail filter forwarder, a .forward file, an /etc/aliases expansion, a sieve rule) folds long lines at a different column than the signer used. The forwarders SMTP daemon may refold continuation lines at SMTP line-length limits (1000 octets per RFC 5321 section 4.5.3.1.6).

Detection: A Received header from a known forwarding service immediately precedes the dkim=fail Authentication-Results entry.

Mitigation: Use c=relaxed/relaxed (the whitespace folding is normalised away by relaxed). If you must use c=simple, deploy ARC sealing at the forwarder.

7.2 Mailing-list footer injection

Cause: A mailing-list forwarder (Mailman, Discourse, Google Groups, Sympa, GitLab list notifications, GitHub list notifications) appends a footer to the message body with subscribe / unsubscribe links and list-info banner. The appended bytes change the canonicalized body and invalidate the body hash.

Detection: A Received header from a list-server domain (lists.example.com, discuss.example.com, etc.) precedes the dkim=fail Authentication-Results entry. The message body contains a recognisable list footer.

Mitigation: Configure the list to use From-header munging (rewrite From: to the lists own domain and re-sign with the lists DKIM) via Mailmans dmarc_moderation_action setting, Google Groups footer settings, or Discourses moderation rules. Do NOT use the l= tag as the mitigation — see section 6.

7.3 Content-transform middleware (antivirus, DLP, URL-rewriting)

Cause: A content-transform middleware (Microsoft Defender Safe Links rewrites URLs to safelinks.protection.outlook.com proxy URLs; Mimecast / Proofpoint URL Defense rewrites URLs to their proxy domains; antivirus middleware injects scan-result banners; DLP middleware redacts sensitive strings) modifies the message body in transit.

Detection: Received headers from safelinks.protection.outlook.com, urldefense.proofpoint.com, mimecast.com, or a corporate email gateway domain immediately precede the dkim=fail entry. The message body contains rewritten URLs or scan banners.

Mitigation: If you control the middleware, configure URL-rewriting to occur AFTER DKIM verification (so the verifier sees the original body). If you do not control the middleware, accept the DKIM failure and rely on SPF alignment or ARC sealing. Many corporate gateways now emit ARC seals to preserve the pre-rewrite authentication result.

7.4 Transfer-encoding changes

Cause: An intermediate MTA converts the message body Content-Transfer-Encoding from quoted-printable to 7bit, from 7bit to quoted-printable, or from quoted-printable to base64 (or vice versa). The transfer-encoding change re-wraps lines, re-encodes non-ASCII characters, and changes the byte sequence even though the semantic content is unchanged.

Detection: The Content-Transfer-Encoding header value in the received message differs from the value the signer embedded (if Content-Transfer-Encoding was named in the h= list). Received headers show passage through a known transcoding gateway (some Exchange Server versions transcode aggressively).

Mitigation: Include Content-Transfer-Encoding in the h= signed-headers list so the encoding change is detected as a header canonicalization failure (which is easier to diagnose than a silent body-hash mismatch). If transcoding cannot be avoided, deploy ARC sealing at the transcoding gateway.

7.5 MIME re-encoding (boundary rewrites, part reordering)

Cause: An intermediate MTA re-packages a multipart MIME message with different boundary strings, reorders the parts, normalises the Content-Type parameters, or strips attachments (iCloud Mail Drop replaces attachments over 25 MB with a download link). The MIME structure changes even though the semantic content is preserved.

Detection: The MIME boundary strings or part order in the received message differ from typical signer output. Received headers show passage through Apple iCloud Mail or a similar attachment-handling intermediary.

Mitigation: Avoid attachments over the receiver-side size limits where possible. For MIME-rewriting intermediaries you do not control, accept the DKIM failure and rely on SPF alignment or ARC sealing.

7.6 Trailing CRLF normalisation

Cause: An intermediate MTA adds or removes a trailing empty line at the end of the body, or normalises multiple trailing empty lines to a single CRLF (or strips them entirely). The semantic content is unchanged but the byte sequence at the end of the body differs.

Detection: The verifier reports a body hash mismatch and a hex-dump comparison of the signers canonical body vs the verifiers received body shows only differences at the very end of the body.

Mitigation: Use relaxed body canonicalization, that is c=relaxed/relaxed (RFC 6376 §3.4.4 strips trailing empty lines as part of the normalisation, so this class of difference is canonicalized away). c=simple body canonicalization (RFC 6376 §3.4.3) only collapses a run of trailing empty CRLFs to a single CRLF — less tolerant than relaxed.

7.7 Subject-prefix rewriting by mailing lists

Cause: A mailing list rewrites the Subject: header to add a list-name prefix ("[list-name]" or "[LIST] " prepended to the original subject). The Subject: header is almost always in the h= signed-headers list, so any rewrite invalidates the header canonicalization.

Detection: The received Subject: header has a "[...]" prefix that was not in the senders original Subject:. Received headers show passage through a list server.

Mitigation: Configure the list to disable Subject-prefix rewriting (Mailman: subject_prefix = ""; Discourse: disable the email reply suffix), OR configure the list to use From-header munging + re-sign with the lists own DKIM (which makes the list the authentic signer, accepting the lists own Subject-prefix as part of the authenticated signal).

8. Receiver-side detection workflow

When a DKIM verification fails, the verifier records the failure in the Authentication-Results header (RFC 8601). The header contains a dkim= field with the verification verdict and a parenthetical reason string. The five canonical reason strings:

• dkim=pass — verification succeeded.
• dkim=fail (body hash mismatch) — the body was modified in transit; the bh= tag does not match the verifiers computed body hash.
• dkim=fail (signature verification failed) — a signed header was modified in transit; the body hash matched but the b= signature does not verify against the canonicalized headers.
• dkim=neutral — verifier processed the signature but could not reach a definitive verdict.
• dkim=temperror — DNS lookup for the selector record failed transiently; the verifier could not retrieve the public key.

The forensic workflow:

1. Capture the raw message source as the verifier received it. Outlook: File > Properties > Internet headers + Save As to preserve the body. Gmail: three-dot menu > Show original > Download Original. Apple Mail: View > Message > Raw Source. The body must be byte-exact — any UTF-8 conversion or line-ending normalisation by your tooling will distort the diagnosis.
2. Read the DKIM-Signature header. Identify the v=, a=, c=, d=, s=, h=, bh=, and b= tag values. The c= tag tells you which canonicalization algorithms to apply.
3. Read the Authentication-Results header. The receivers verifier verdict is the source of truth for the failure mode. Look for dkim=fail (...) and the parenthetical reason.
4. Apply the declared body canonicalization to the received body. Compute the body hash with the algorithm declared in a= (typically rsa-sha256). Compare to bh=. If they differ, the body was modified in transit — proceed to step 5. If they match, the failure is in header canonicalization or the signature math — proceed to step 6.
5. Walk the Received headers backward to find the first hop where the body was modified. The immediately-preceding hop is the culprit. Common culprits: list servers, content-transform middleware, forwarding services, transcoding gateways.
6. For header-canonicalization failures, apply the declared header canonicalization to each signed header (in the h= order) and recompute the signature. The DMARC Analyzer Email Header Analyzer automates steps 4-6 and surfaces the specific failure mode.

9. Worked byte-level examples

9.1 Header simple canonicalization

Signers original Subject: header (with two-space indent on the continuation line):

Subject: Re: your order
  is ready for pickup

Header simple canonical form (byte-for-byte identical, no transformation):

Subject: Re: your order
  is ready for pickup

If an intermediate MTA refolds the continuation line at a different column, the simple canonical form changes and the signature breaks.

9.2 Header relaxed canonicalization

Same signers original Subject: header:

Subject: Re: your order
  is ready for pickup

Header relaxed canonical form (lower-cased name, continuation unfolded, whitespace runs collapsed, whitespace around the colon and at the end of the value stripped; the value is followed by a single CRLF):

subject:Re: your order is ready for pickup

The relaxed form survives any subsequent refolding, case-change, or whitespace normalisation by an intermediate MTA because the same normalisation is applied at verification time.

9.3 Body simple canonicalization

Signers original body (note the run of three trailing empty lines):

Your order #12345 has shipped.

Thank you for your business.

Body simple canonical form (only the trailing empty-line run is collapsed to a single CRLF; all internal content is byte-for-byte identical):

Your order #12345 has shipped.

Thank you for your business.

Any other byte change to the body invalidates the simple body hash.

9.4 Body relaxed canonicalization

Signers original body (note trailing spaces on the first content line and the run of trailing empty lines):

Your   order   #12345  has  shipped.

Thank you for your business.

Body relaxed canonical form (whitespace runs collapsed to single spaces within each line, trailing whitespace stripped from each line, trailing empty lines stripped from the end):

Your order #12345 has shipped.

Thank you for your business.

Note that the internal empty line is preserved — relaxed canonicalization only strips trailing empty lines at the END of the body, not internal empty lines.

10. Provider canonicalization defaults

Every modern mailbox provider and ESP defaults to c=relaxed/relaxed for outbound DKIM signing. The provider-by-provider breakdown:

Audit your own outbound DKIM: Send a test message to a mailbox you control, capture the raw source, and read the c= tag of the DKIM-Signature header. Every modern signer should emit c=relaxed/relaxed; the DMARC Analyzer Email Header Analyzer parses every DKIM-Signature tag and flags non-production canonicalization choices.

11. FAQ

What is DKIM canonicalization?

DKIM canonicalization is the normalisation step a DKIM signer applies to the message headers and the message body before they are hashed and signed, and the same normalisation a DKIM verifier applies before re-hashing the headers and body to compare against the signature. Defined in RFC 6376 section 3.4, canonicalization exists because mail in transit gets touched: SMTP intermediaries fold long lines at column 78, refold continuation lines at different break points, normalise trailing whitespace, collapse runs of spaces, convert tabs to spaces, add a trailing empty line, strip a trailing empty line, or re-encode the body during MIME repackaging. Without canonicalization, ANY of these benign transformations would invalidate the signature because the hash would not match. With canonicalization, the signer and the verifier agree on a deterministic textual representation of the message that survives the typical mail-in-transit modifications, so the signature stays valid. RFC 6376 section 3.4 defines two algorithms (simple and relaxed) and applies them independently to headers and body, producing four canonicalization combinations declared by the c= tag of the DKIM-Signature header.

What is the difference between simple and relaxed canonicalization?

Simple canonicalization (RFC 6376 sections 3.4.1 for headers and 3.4.3 for body) performs essentially NO normalisation. Header simple keeps headers byte-for-byte exactly as the signer presented them. Body simple keeps body bytes exact, with the single rule that consecutive trailing empty lines at the very end of the body are collapsed to a single CRLF. Relaxed canonicalization (RFC 6376 sections 3.4.2 for headers and 3.4.4 for body) performs substantial normalisation. Header relaxed lower-cases header field names, unfolds folded header continuation lines back into single logical lines, collapses runs of whitespace within the header value to single spaces, strips leading and trailing whitespace from the header value, and removes the trailing whitespace before the CRLF. Body relaxed collapses runs of whitespace within each line to single spaces, removes trailing whitespace at the end of each line, removes trailing empty lines, and (like simple body) collapses consecutive trailing empty lines. The relaxed-vs-simple trade-off is straightforward: relaxed survives more mail-in-transit transformations, simple guarantees exact-byte identity. Production DKIM almost always uses c=relaxed/relaxed.

What does c=relaxed/relaxed mean in a DKIM signature?

The c= tag in the DKIM-Signature header (RFC 6376 section 3.5) declares the two canonicalization algorithms the signer used, in the form c=header-canon/body-canon. c=relaxed/relaxed means the signer used relaxed canonicalization for headers AND relaxed canonicalization for body. The verifier MUST apply the same canonicalization the signer declared; using the wrong canonicalization will produce a different hash and reject the signature. c=relaxed/relaxed is the production default for every modern DKIM deployment because it survives the typical in-transit transformations (whitespace refolding by intermediate MTAs, header continuation-line re-breaking, trailing-line normalisation) that would invalidate a simple canonicalization. The four possible c= values are: c=simple/simple (the RFC default if c= is omitted, fragile and rarely used in production), c=simple/relaxed (mixed, occasionally used for security-critical headers + transit-tolerant body), c=relaxed/simple (mixed, the body bytes are signed exactly), and c=relaxed/relaxed (production standard).

What does it mean when DKIM verification fails with body hash mismatch?

A DKIM body hash mismatch (commonly reported as dkim=fail with the body hash reason, or as bh= mismatch in verifier logs) means the body hash the signer computed and embedded in the DKIM-Signature header (the bh= tag) does NOT match the body hash the verifier computed after applying the same canonicalization (declared by the c= tag) to the received message body. Body hash mismatches are almost always caused by an in-path modification of the message body between the signer and the verifier: a mailing list appended a footer, an antivirus middleware rewrote a URL, a transfer-encoding change re-wrapped lines, a DLP system replaced a sensitive string, an MTA re-encoded a MIME boundary, an iCloud Mail Drop attachment-handler stripped attachments, or a forwarder added or removed trailing empty lines. The fix is to identify the in-path modifier (use the Received headers to trace the message hops and the Authentication-Results header to find where verification first failed), then either configure the modifier to leave the body alone, or accept the change and rely on ARC (RFC 8617) or a downstream re-signing scheme to attest the modified body, or use c=relaxed/relaxed (more transit-tolerant) instead of simple body canonicalization.

Why does my DKIM signature break after the message goes through a forwarder?

Forwarders break DKIM signatures because the forwarder is an intermediate MTA that may modify the message in ways the original signers canonicalization did not anticipate. The four most common forwarder-induced DKIM failures are: (1) header rewriting (the forwarder rewrites the Subject:, To:, or From: header to add a forwarded-from prefix or list-name tag — every signed header that gets rewritten fails verification); (2) body footer injection (mailing-list forwarders append a footer with subscribe / unsubscribe links — every byte added to the signed body breaks the body hash unless the signer used an l= tag with a length shorter than the original body); (3) MIME re-encoding (the forwarder repackages a multipart message with different boundary strings or different Content-Transfer-Encoding choices — every byte change in the MIME structure breaks the body hash); (4) transfer-encoding changes (the forwarder converts a quoted-printable body to 7bit, or vice versa — the line-wrapping changes break the body hash). The canonical mitigations are ARC sealing (RFC 8617) at the forwarder, From-header munging on mailing lists (rewrite the From: to the lists own domain and re-sign with the lists DKIM), or accepting the DKIM failure and relying on SPF + DMARC alignment via DKIM only when the forwarder leaves the body intact.

What is the l= tag in a DKIM signature?

The l= tag in the DKIM-Signature header (RFC 6376 section 3.5) is an OPTIONAL signed-body-length declaration. When present, l= tells the verifier to canonicalize and hash ONLY the first l octets of the canonicalized body, ignoring everything after that. The intended use case is to allow mailing-list forwarders to append a footer to the message without breaking the signature: the signer sets l= to the original body length, the forwarder appends a footer, the verifier hashes only the first l octets (which are unchanged), the body hash matches, and the signature verifies. The l= tag is rarely used in practice for three reasons: (1) it introduces a security weakness where an attacker can inject arbitrary content after the l= cutoff and the signature still validates (the appended content is unsigned but to a casual reader appears to be part of the signed message); (2) most forwarders that append footers also rewrite the From: header (breaking header canonicalization regardless), so the l= tag does not actually help; (3) modern DKIM signers default to omitting l= (signing the entire body) and accept the forwarder breakage, preferring ARC sealing or From-header munging as the operational answer. Use l= only with explicit threat modelling — never as a casual operational workaround.

Why does RFC 6376 default to c=simple/simple if no c= tag is present?

RFC 6376 section 3.5 specifies that if the c= tag is absent from a DKIM-Signature header, the default value is c=simple/simple. This default is widely considered a historical anomaly rather than a sensible production choice. The default exists because the original DomainKeys specification (RFC 4870, DKIMs predecessor) did not have a relaxed canonicalization and simple was the only option; RFC 6376 preserved backward compatibility by keeping simple as the default. In practice, every modern DKIM signer (OpenDKIM, Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailchimp, Postfix dkim-milter, Exim DKIM, Sendmail DKIM, all the SaaS senders) explicitly emits c=relaxed/relaxed, so the c= default rarely fires. Operators inspecting a DKIM-Signature header should ALWAYS see an explicit c= tag in modern mail — the absence of the c= tag is itself a diagnostic signal (likely a legacy signer or a misconfigured custom implementation). When auditing your own signers, verify the c= tag is explicitly set to relaxed/relaxed and not relying on the default.

How do I debug a DKIM body hash mismatch?

The forensic workflow for diagnosing a DKIM body hash mismatch has five steps. Step 1: Capture the raw message source as the verifier received it (Outlook File > Properties > Internet headers; Gmail three-dot menu > Show original; Apple Mail View > Message > Raw Source). The body must be byte-exact — any UTF-8 conversion or line-ending normalisation by your tooling will distort the diagnosis. Step 2: Read the DKIM-Signature header and identify the c= tag (header-canon/body-canon), the bh= tag (the original body hash in base64), the b= tag (the signature), the d= tag (signing domain), and the s= tag (selector). Step 3: Apply the body canonicalization (simple or relaxed per c=) to the received body and compute the hash with the same algorithm declared in the a= tag (typically rsa-sha256). Step 4: Compare your computed body hash to the bh= value. If they differ, the body was modified in transit. If they match, the failure is in header canonicalization or the signature math, not the body. Step 5: Walk the Received headers backward to find the first hop where the body was modified — the immediately-preceding hop is the culprit. The DMARC Analyzer Email Header Analyzer automates steps 2-4 and surfaces the specific failure mode.

Which DKIM canonicalization should I use for production?

Use c=relaxed/relaxed for every production DKIM deployment. Relaxed canonicalization for both headers and body survives the typical in-transit transformations (whitespace folding, continuation-line re-breaking, trailing-whitespace normalisation) that would invalidate a simple canonicalization. Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailgun, Mailchimp, Postmark, SparkPost, Klaviyo, Constant Contact, HubSpot, and every modern SaaS sender default to c=relaxed/relaxed. The handful of legitimate c=simple/simple use cases are niche: notarised email where any byte change must invalidate the signature (legal-discovery archives, transactional notarisation services), some highly-regulated industries that require provably exact signatures, and certain end-to-end signed-mail systems that do not pass through transforming intermediaries. For ordinary notification, transactional, marketing, and corporate mail — c=relaxed/relaxed is the right answer. Configure your signer (OpenDKIM AlwaysSignHeaders, Postfix dkim-milter, Microsoft 365 default, etc.) to emit c=relaxed/relaxed explicitly.

12. Related guides

• DKIM explained — DomainKeys Identified Mail (RFC 6376). The pillar page covering DKIM end-to-end: selectors, signatures, the eight tag-by-tag record reference, key rotation, replay considerations, examples. Read first if you are new to DKIM.
• DMARC reporting pipeline (RFC 7489 §7) — the DKIM-CANONICALIZATION-CHOICE-VERDICT- PROPAGATION-LAYER companion to this DKIM canonicalization reference. Where THIS page documents the four RFC 6376 §3.4 canonical canonicalization algorithm pairs (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) and the per- pair receiver-side header-and-body normalization procedures the receiver applies BEFORE computing the verification hash against the canonicalized byte stream, the DMARC-reporting-pipeline spoke is the VERDICT-PROPAGATION-LAYER REFERENCE documenting the seven-stage pipeline through which the per-message DKIM verification verdict (driven structurally by the canonicalization choice the operator publishes in the DKIM-signer c=<hdr>/<body> tag) propagates into the operator-observable per-receiver-organization evidence stream. The CANONICALIZATION-CHOICE-VS-PIPELINE- OBSERVABILITY cross-reference establishes FOUR structurally-distinct per-pipeline- stage canonicalization-choice-evidence dimensions: (i) Stage 1 per- receiver per-message DKIM verification — the receiver applies the canonicalization pair the signer-tag c= encodes (default simple/simple when omitted per RFC 6376 §3.5) AND computes the verification hash against the canonicalized byte stream; the DMARC-reporting-pipeline spoke documents Stage 1's per-message verdict-emission contract (dkim=pass / dkim=fail / dkim=temperror / dkim=permerror entry in the Authentication-Results header) AND the per-canonicalization-choice failure-mode catalogue — simple/simple records FAIL on any forwarder body-byte modification, relaxed/relaxed survives the canonical forwarder body- modification class (CRLF normalisation, whitespace folding); (ii) Stage 2-3 per-source-IP per-disposition row aggregation surfaces the canonicalization- choice failure-pattern as per-source-IP DKIM-fail row attribution to forwarder infrastructure — when the operator-published canonicalization is simple/simple (the RFC 6376 default), per-source-IP DKIM-fail rows accumulate against forwarder source-IPs (Google forwarder, Outlook.com forwarder, mailing-list MTA, list-server fan-out infrastructure) WHILE the same per- source-IP attribution under a relaxed/relaxed canonicalisation publishes dkim=pass; the DMARC-reporting-pipeline spoke documents the Stage 2 per-source-IP aggregation algorithm AND the Stage 3 XML rua-payload schema operators consume the per- canonicalization-choice failure-rate differential through; (iii) Stage 6 operator-side per-row analysis surfaces the canonicalization-choice migration- decision-evidence — per-receiver- organisation DKIM-pass-rate decomposition by forwarder vs direct-egress vs mailbox-provider-egress source-IP attribution differentiates the legitimate-forwarder body-modification failure class from the unaligned-mailbox- provider failure class; the DMARC-reporting-pipeline spoke documents the Stage 6 operator-analysis discipline operators apply to decide whether to migrate the signer's c=<hdr>/<body> choice from simple/simple to relaxed/relaxed based on the per-forwarder failure-rate evidence the aggregate-report stream surfaces; (iv) Stage 7 per-operator canonicalization-choice migration feedback closes the per-canonicalization- decision loop — the operator-side decision to migrate canonicalization based on the aggregate-report evidence becomes a signer-configuration change at the per- ESP / per-mailbox-provider / per-egress- MTA boundary documenting which canonicalization the operator's signing infrastructure now applies; the DMARC-reporting-pipeline spoke documents the Stage 7 operator-side migration- decision feedback channels AND the per-canonicalization-cycle re-verification steps operators use to confirm the new canonicalization is propagating before retiring the prior canonicalization choice. Pair this page (the DKIM- canonicalization-algorithm reference) with the DMARC-reporting-pipeline spoke (the end-to-end verdict-propagation-layer reference) when designing the per- operator canonicalization-migration runbook — the spoke documents the per- stage payload structure AND the per- source-IP aggregation algorithm receivers apply that surfaces the per-canonicalization- choice failure-rate differential in the operator-observable evidence stream.
• DKIM DNS TXT-record byte syntax — the DKIM-PUBLISHER-KEY-PUBLICATION-BYTE-LAYER companion documenting the precise byte-syntax of the DKIM public-key TXT record published at the <selector>._domainkey.<domain> DNS zone — the v=DKIM1 version tag, the k=rsa / k=ed25519 key-type tag, the p=<base64> public-key material, the h=sha256 hash- algorithm acceptance list, the s=email service-type tag, the t=y testing flag, the n=<note> note tag, and the critical RFC 1035 §3.3.14 byte-string concatenation rule (the 255-byte TXT-string chunk limit and the publisher's obligation to break the p= base64-encoded public key into 255-byte chunks via "chunk1" "chunk2" "chunk3" adjacent-quoted-string DNS-master-file syntax for receivers to byte-concatenate per RFC 6376 §3.6.2.2). Where THIS page documents the four c= CANONICALIZATION algorithm pairs (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) and the byte- level header-and-body NORMALIZATION procedures each algorithm pair applies to the message before the signature is computed over the canonicalized byte stream, the DKIM-DNS-syntax spoke is the PUBLISHER-KEY-MATERIAL-PUBLICATION-BYTE-LAYER companion documenting the BYTE-SYNTAX of the public-key TXT record the receiver MUST retrieve-and-parse correctly before the canonicalized byte stream this page documents can be verified. The four-axis CANONICALIZATION-VS-PUBLISHER-KEY-PUBLICATION comparison exposes the structurally-distinct PROTOCOL-LAYER-INTERACTION roles: (i) the canonicalized byte stream THIS page computes is verified against the p=<base64> public key retrieved from the DKIM TXT record the spoke documents — the canonicalization algorithm and the public-key publication are two halves of the same verification contract; if the publisher correctly canonicalizes but publishes a malformed p= tag (truncated base64, missing quote-string chunk boundary, whitespace-corrupted base64 padding), the receiver retrieves a non-parseable public key and ALL canonicalized-and-signed messages fail DKIM verification regardless of canonicalization correctness; (ii) the canonicalization algorithm published in the DKIM-Signature header's c= tag MUST be one of the four algorithm pairs THIS page documents — the DKIM-DNS-syntax spoke does NOT publish the canonicalization algorithm choice (canonicalization is a per-MESSAGE choice encoded in the per-message DKIM-Signature header, NOT a per-KEY choice encoded in the per-key TXT record); the public- key TXT record's h= tag is the publisher's hash-algorithm acceptance list (h=sha256), NOT a canonicalization-algorithm acceptance list — receivers verify the per-message canonicalization choice without consulting the per-key TXT record; (iii) the DKIM-DNS-syntax spoke documents the k=rsa vs k=ed25519 key-type tag that determines which signature-verification algorithm the receiver applies to the canonicalized byte stream THIS page computes — RSA keys use PKCS#1 v1.5 signature scheme with SHA-256 hash, Ed25519 keys use the EdDSA signature scheme with SHA-512 hash; the canonicalization output bytes are the same regardless of key-type, but the signature- verification algorithm applied to those bytes differs; (iv) the t=y testing-mode flag in the DKIM TXT record instructs receivers to accept canonicalized signatures that fail verification (e.g. during publisher key- rotation overlap windows or initial DKIM deployment) — the testing-mode flag is the PUBLISHER-KEY-PUBLICATION-LAYER toggle that relaxes receiver-side verification of canonicalized signatures THIS page documents the byte-level computation of. Read the DKIM-DNS-syntax spoke when an operator asks "the canonicalized byte stream verifies correctly under c=relaxed/relaxed in my test harness but the receiver rejects the signature — what's going wrong?" — the answer is most often a publisher-side p= base64 chunking error or a missing v=DKIM1 version tag, which the spoke documents as the byte-layer publication-correctness contract this page's canonicalization output depends on.
• DKIM signatures explained — the DKIM-Signature header byte-layout sibling whose c= tag THIS page documents — the DKIM-cluster sibling that documents the full DKIM-Signature header byte-layout in which the c= canonicalization tag this page describes is one of fourteen tags (v, a, b, bh, c, d, h, i, l, q, s, t, x, z). Where THIS page documents the four c= algorithm values (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) and the byte-level header-and-body normalization procedures each algorithm pair applies to the message before the signature is computed over the canonicalized byte stream, the signatures-explained spoke documents the LARGER container the c= tag lives in — the DKIM-Signature header itself, the tag- grammar per RFC 6376 §3.5 that the c= tag obeys (the tag-name = ALPHA *(ALPHA / DIGIT) / tag-value = 0*DKIM-quoted-printable form), the position of c= in the canonical operator-published tag order (v=1; a=...; c=...; d=...; s=...; h=...; bh=...; b=...), and the interaction with the h= signed-headers list (which determines WHICH headers the canonicalization algorithm this page documents is applied to). Read the signatures-explained spoke when an operator asks "where exactly in the DKIM-Signature header does the c= tag live, and what other tags interact with the canonicalization choice" — the spoke is the authoritative DKIM-Signature-header byte-layout sibling of the canonicalization-algorithm deep dive on this page. Closes the DKIM-cluster sibling-orphan parity gap between dkim_canonicalization (the c=-tag-algorithm reference) and dkim_signatures_explained (the DKIM-Signature-header byte-layout reference).
• DKIM cryptography basics — the RSA / Ed25519 signing-math deep dive explaining HOW the canonicalized byte stream produced by this pages algorithms gets signed. Canonicalization produces the input; cryptography_basics covers the signing function that consumes it.
• DKIM selectors explained — the selector address-space deep dive (the s= tag value that names which public key under _domainkey.example.com the receiver fetches to verify the signature). Canonicalization produces the canonicalized bytes; the selector identifies the public key used to verify the signature over those bytes. The eight selector-naming patterns + seven failure modes + eleven provider conventions are the addressing layer that wraps this pages canonicalisation algorithm choice.
• DKIM key rotation — operational rotation playbook (rotation cadence, dual-selector overlap, M3AAWG best practices). Key rotation does not change canonicalization but every rotation is an opportunity to audit the c= tag.
• BIMI VMC certificates — the per-publisher per-domain BIMI VMC cryptographic-trust-anchor companion to this DKIM canonicalization-mode publication- discipline reference. Where THIS page documents the per-publisher per-selector application- layer DKIM canonicalization-mode publication discipline (the RFC 6376 §3.4 c=<header-canon>/<body-canon> tag-vocabulary publication-decision driving per-receiver per-message DKIM-verdict stability), the BIMI VMC trust-anchor companion documents the per-publisher per- organizational-domain Mark-Certificate cryptographic-publication discipline (the per-CA-policy Mark-Certificate-issuance per- trademark-registry validation chain, the per-publisher per-organizational-domain a=<vmc-uri> BIMI TXT-RR trust-anchor URI republish cadence, and the per-publisher per-organizational-domain VMC- renewal pre-expiry cryptographic-publication- overlap-window discipline) whose per-publisher per-organizational-domain VMC-renewal cadence peer-pairs with the per-publisher per-selector DKIM canonicalization-mode publication discipline THIS page documents at FOUR per- publisher per-domain cross-layer cryptographic- publication-discipline coupling dimensions: (i) per-publisher per-domain VMC X.509 Mark-Certificate cryptographic- trust-anchor publication-discipline (the per- CA-policy validated-trademark-registry chain binding the per-publisher per-organizational- domain to a verified brand-indicator SVG asset) as the per-publisher per-domain display-layer cryptographic-trust-anchor peer-pair of the per-publisher per-selector DKIM canonicalization-mode application-layer cryptographic-byte-normalization-discipline THIS page documents — both per-publisher per- domain cryptographic-publication-discipline references are operator-side trust-anchor- publication decisions whose per-publisher per- domain operator-discipline failure modes directly degrade per-receiver per-message brand-indicator display-eligibility and per- receiver per-message DKIM-aligned-pass-rate floor projection respectively; (ii) per-publisher per- organizational-domain VMC-renewal pre-expiry cryptographic-publication-overlap-window discipline (the per-CA-policy ~30-day pre- expiry VMC renewal publication-overlap window the per-publisher per-organizational-domain operator MUST observe to prevent per-receiver BIMI-evaluator cached-trust-anchor cache- eviction-induced display-eligibility loss) structurally parallels the per-publisher per- selector DKIM-key rotation-overlap window canonicalization-mode-preservation discipline (the per-publisher per-selector dual-selector overlap window the per-publisher per-domain operator MUST observe to prevent per-receiver per-message DKIM-verification-cache-eviction- induced per-receiver DKIM-aligned-pass-rate floor collapse) at the per-publisher per- domain joint cryptographic-publication- overlap-window operator-discipline coordination boundary; (iii) per-publisher per-organizational-domain VMC cryptographic-staleness risk class (the per- CA-policy VMC Mark Certificate reaching end- of-validity and the per-receiver BIMI- evaluator cached-trust-anchor cache-eviction- window mis-sizing class) peer-pairs the per- publisher per-selector DKIM canonicalization- mode-publication-cryptographic-byte-grammar- staleness risk class (the per-publisher per- selector c=simple/simple-vs- c=relaxed/relaxed-mode-choice publication-decision producing per-forwarder- class-mutation per-message DKIM-verdict collapse class THIS page enumerates) at the per-publisher per-domain joint cryptographic- publication-staleness operator-discipline coordination boundary; and (iv) per-publisher per- receiver per-day DMARC RUA XML aggregate- report per-row policy_evaluated/dkim attribution evidence stream (the per-publisher per-selector canonicalization-mode-publication- discipline-vs-forwarder-survival evidence- stream THIS page's canonicalization-mode- publication discipline directly produces) as the joint per-publisher per-receiver per-day observability evidence stream whose per- receiver per-day DKIM-aligned-pass-rate aggregate projection feeds both the per- publisher per-domain DMARC-composite-pass- rate floor preservation gate (THIS page's operational rationale) AND the per-publisher per-domain BIMI-display-eligibility- precondition readiness gate (the BIMI VMC trust-anchor companion's operational rationale) at the per-publisher per-domain per-receiver per-day cross-layer evidence- stream composition boundary.
• DKIM for Microsoft 365 — the CANONICALIZATION-PAIR-CHOICE-AS- DETERMINANT-OF-M365-EXCHANGE-ONLINE- POST-SIGNING-BODY-MODIFICATION-PIPELINE- SURVIVAL companion reference. Where THIS page documents the RFC 6376 §3.4 canonicalization-pair semantics (c=simple / c=relaxed for header + body, four combination outcomes with structurally- distinct byte-immutability contracts), the DKIM-for-Microsoft-365 spoke documents the M365-tenant outbound- signing topology that is uniquely sensitive to canonicalization-pair choice because Exchange Online + EOP modify the message body AND headers AFTER M365's DKIM-signing stage. The M365 post-signing body-modification pipeline includes Safe Links rewriting (URL rewriting in body), organisation- wide disclaimer injection (text appending below message body), transport-rule body-modification actions (regex-driven body rewriting), and the hybrid-Exchange connector-relay header re-stamping that composes additional Received: + ARC-Seal headers on top of the DKIM-signed envelope. Each of these post-signing modifications interacts differently with the four canonicalization pairs THIS page documents: c=simple/simple STRICTEST byte-immutability contract produces dkim=fail on EVERY Safe-Links URL rewrite; c=simple/relaxed produces dkim=fail on Safe-Links and disclaimer injection but tolerates header whitespace normalisation; c=relaxed/ simple tolerates header whitespace normalisation but fails on body modifications; c=relaxed/relaxed WEAKEST byte-immutability contract tolerates both header whitespace and body whitespace normalisation but still fails on Safe-Links non-whitespace rewrites. Read the DKIM-for-Microsoft- 365 spoke when planning an M365-DKIM deployment that must survive the EOP post-signing pipeline — the spoke documents the per-tenant Safe Links configuration, the disclaimer-injection operator surface, the transport-rule body-rewrite catalogue, and the hybrid-Exchange topology whose composition with THIS page's canonicalization-pair choice determines whether the M365-outbound DKIM signature survives end-to-end receiver-side verification.
• DKIM for Google Workspace — the WORKSPACE-TENANT-OUTBOUND-DKIM- SIGNATURE-SURVIVAL-VS-CANONICALIZATION- PAIR-CHOICE companion documenting the canonical case where the c= canonicalization- pair choice documented on THIS page determines whether the Workspace-tenant outbound DKIM signature SURVIVES the downstream-receiver-side modification pipeline. Documents FOUR Workspace- parallel canonicalization-survival dimensions (Workspace's default c=relaxed/relaxed canonicalization- pair selection at the google-selector signing pipeline aligns with M3AAWG consensus and survives the most common downstream body-transformation classes — mailing-list footer injection, anti- spam disclaimer prepending, content- transform middleware whitespace normalization — that a c=simple/simple selection WOULD break; Workspace's Inbound Gateway routing pattern composes canonicalization-pair survival with the receiver-side gateway re-signing topology — a Workspace tenant whose domain is configured as an Inbound Gateway target sees inbound DKIM- signed messages traverse the gateway which MAY re-canonicalize and re-sign OR MAY pass-through depending on the per-tenant gateway configuration, affecting which canonicalization-pair choice survives end-to-end; Workspace's per-message gmail.com alias rewriting (when an outbound message uses a gmail.com alias under a Workspace domain) can invalidate the body hash if the per-tenant alias rewriting is applied AFTER DKIM signing — the c=relaxed/relaxed canonicalization choice absorbs the alias-related whitespace normalization that c=simple/simple would not; Workspace tenants whose author- domain ALSO signs via parallel third- party signers must coordinate canonicalization-pair selection across infrastructures — Workspace's google-selector signature using c=relaxed/relaxed and a SaaS-platform signer using c=simple/relaxed on the SAME outbound message produces TWO canonicalization profiles whose downstream survival probabilities diverge per-receiver — the receiver- side reputation model observes the per-author-domain JOINT signature- survival rate across all signing infrastructures and the canonicalization-pair-choice asymmetry produces per-signer divergent survival outcomes the operator must reconcile). Read the Workspace spoke alongside this canonicalization reference when authoring Workspace-tenant DKIM deployments — the spoke covers the per-tenant Admin Console canonicalization- pair selection at DKIM key generation, the per-tenant Inbound Gateway configuration, the per-tenant gmail.com alias rewriting topology, and the per-tenant third-party-signer parallel canonicalization coordination discipline whose composition with THIS page's canonicalization-pair choice determines whether the Workspace- outbound DKIM signature survives end- to-end receiver-side verification.
• DKIM best practices (the 15 deployment rules) — the operational recommendation catalogue whose Rule 5 codifies the canonicalization choice this page documents in depth. Where THIS page is the byte-level algorithmic reference covering the two header algorithms (simple per RFC 6376 §3.4.1, relaxed per §3.4.2), the two body algorithms (simple per §3.4.3, relaxed per §3.4.4), the four c= tag combinations, and the seven body-hash mismatch root causes, best-practices Rule 5 is the operator deliverable: publish c=relaxed/relaxed as the default for all production signing. The relaxed/relaxed combination is the M3AAWG-aligned consensus that maximises survival across forwarders, mailing lists, and content-transform middleware without weakening the cryptographic binding to any operationally-meaningful degree (the relaxed/relaxed surface still detects the body-modification attacks the l=-disabled posture in best-practices Rule 8 hardens further). Best-practices also locks in adjacent canonicalization-touching rules: Rule 6 (header-list signing — which header names go into h=, hence which header bytes get canonicalized + hashed), Rule 8 (NEVER use the l= partial-body-length tag; the l= tag is the most replay-dangerous canonicalization-adjacent knob in the spec — see the deep dive in section 6 of THIS page), Rule 9 (the t=y testing flag's 24–72h burn-in window that exercises every canonicalization edge case before flipping to enforcement), and Rule 11 (multi- signature double-signing that hedges against a forwarder mangling one canonicalization choice while preserving the other). Read best-practices alongside this page when designing the production DKIM signing configuration: this page tells you HOW canonicalization works at the byte level, best-practices tells you WHICH knob settings to ship in production and WHY those choices survive the seven failure modes documented in section 7.
• DKIM replay attacks — the capture-and-rebroadcast attack class and the RFC 9103 x= expiration tag. Replay attacks interact with the l= partial-body tag in relevant ways (see section 6).
• DKIM failures explained — the operational deep dive on the canonical DKIM verification-failure taxonomy. Canonicalization-mismatch IS the dominant body-hash-mismatch failure root cause this page's section 7 enumerates: a sender that publishes c=simple/simple while the message body traverses a forwarder that normalises trailing whitespace, or any sender that publishes c=relaxed/relaxed while a transport-layer 8BITMIME-to-quoted- printable transform re-encodes the body bytes, will see the receiver-recomputed body hash diverge from the signed bh= value documented in this page's section 4 byte-level reference. The failures-explained spoke is the per-failure- class diagnostic next-step: where THIS page documents the ALGORITHM that defines what canonicalized bytes get hashed, failures- explained documents what an operator sees in the auth_results/dkim/comment field of the aggregate-report row when the algorithm output diverges from what the receiver recomputes (the four canonical failure result codes: bodyhash, signature, permerror, temperror). Read failures- explained when decoding a recurring DKIM- fail signal observed in the RUA stream and the cause is not obvious from a single message — the spoke is the authoritative diagnostic-decision reference distinguishing canonicalization-induced failure from selector-key-mismatch, expired-selector, and oversized-signature root causes.
• DKIM troubleshooting — the CANONICALIZATION-MISMATCH-TROUBLESHOOTING-PIVOT companion to this DKIM canonicalization mechanics reference. Where THIS page documents the FOUR CANONICALIZATION OPTIONS the RFC 6376 §3.4 c= tag selects between (c=simple/simple — byte-exact header + body verification with zero in-transit tolerance, c=relaxed/relaxed — header whitespace collapsing + body trailing-empty-line tolerance, c=relaxed/simple — header forgiving but body byte- exact, c=simple/relaxed — rare inverse), the troubleshooting spoke documents the OPERATOR PIVOT from "I observe a canonicalization- related failure" to a concrete remediation. The pivot is STRUCTURALLY-LOAD-BEARING because the operator pivots from UNDERSTANDING (this page) to ACTION (the troubleshooting spoke) at the moment a RUA stream surfaces dkim=fail rows for legitimately-authored messages — the diagnosis-decision-tree the troubleshooting spoke documents determines whether the failure root-cause is (i) mailing- list transit modification (a Subject prefix [list-name] is added + a footer is appended + a List-Unsubscribe header is injected — under c=simple/simple the body hash breaks immediately; the troubleshooting playbook identifies this via the standard Authentication-Results header signature on Mailman / Sympa / Google Groups), (ii) archive- scrubber rewrite (when a legal-archive system rewrites URLs with attribution prefixes, or downgrades HTML-to-plaintext for compliance) — under either canonicalization the body hash breaks; the troubleshooting playbook identifies via the Received: chain signature, (iii) legal- disclaimer-injector modification (Exchange Transport Rules / Mimecast / Proofpoint Compliance Engine appending legal disclaimers at the corporate-relay boundary) — same body-hash break signature but different remediation (sign AFTER the disclaimer injection OR mark the disclaimer-injected boundary as a re-signing point with ARC), (iv) encoding-layer re-encoding (a 7-bit-only gateway re-encoding quoted-printable bodies, or a base64 re-line-wrapping at 76 columns instead of the original 78) — the troubleshooting playbook diagnoses via the body-hash boundary witness. For each cause class the troubleshooting spoke documents the remediation path: switch to c=relaxed/relaxed where the body modification is whitespace-only, sign AFTER the transit-modification boundary (corporate-relay outbound stack signing instead of corporate-MUA- outbound stack signing), adopt ARC (RFC 8617) at the relay boundary to preserve the original-pre-modification verdict, or coordinate with the mailing-list operator to bypass the Subject-prefix / footer-injection modification class. Read the troubleshooting spoke whenever the canonicalization choice this page documents fails to absorb a body modification the operator observes in the RUA stream — the spoke is the load-bearing canonicalization-mismatch remediation reference.
• SPF explained — Sender Policy Framework (RFC 7208). The IP-authorisation layer; complements DKIMs cryptographic signing.
• Why SPF alone is insufficient — the SPF-INSUFFICIENCY-COMPOSITENESS- ARGUMENT-FOUNDATIONAL companion to this DKIM canonicalization reference. Where THIS page documents the RFC 6376 §3.4 per-publisher per-selector canonicalization-algorithm- pair choice (c=relaxed/relaxed / c=simple/simple / mixed), the why-SPF-alone-insufficient spoke is the FOUNDATIONAL why-DMARC-exists reference whose 4-class SPF-insufficiency catalogue is structurally closed by the per-publisher per-selector DKIM cryptographic-signature complement whose forwarder-survival contract materially depends on the canonicalization-algorithm-pair choice THIS page documents at FOUR per-DKIM- canonicalization-vs-SPF-insufficiency- compositeness coupling dimensions: (i) forwarder-rewrite-breaks-SPF dimension ↔ c=relaxed/relaxed body- canonicalization maximises DKIM forward- survival — SPF authentication per RFC 7208 §5 binds the per-message verdict to the connecting-MTA-IP + RFC5321.MailFrom envelope-domain, both of which are rewritten at every forwarder hop (mailing-list-manager / .forward / Office- 365-routed-rule / corporate-gateway-forward rewrites); DKIM cryptographic signatures per RFC 6376 §3 are bound to the MESSAGE content (header + body) and SURVIVE forwarder rewrites THAT DON'T MODIFY SIGNED HEADERS OR BODY; THIS page's c=relaxed/ relaxed body-canonicalization choice is the load-bearing operator-side instrumentation that maximises the per-message DKIM- Signature's survival across the forwarder whitespace/end-of-line/repeated-WSP normalisation rewrites that structurally break the SPF-leg verdict — the canonicalization-algorithm-pair selection THIS page documents IS the operator-side instrumentation closing the forwarder- rewrite-breaks-SPF compositeness gap the spoke enumerates as dim (i); (ii) IP-only-authentication-misses- RFC5322.From-header-spoofing dimension ↔ DKIM d=-domain cryptographic binding to canonicalized message content — SPF authentication produces a verdict against the RFC5321.MailFrom envelope-domain but NEVER against the RFC5322.From header-displayed domain; attackers can publish permissive SPF for their own envelope-domain (v=spf1 +all) and forge a VICTIM-domain in the RFC5322.From header — SPF passes for the attacker's envelope but the displayed identity is the victim; DKIM cryptographic signature per RFC 6376 §3.5 binds the d=-domain to the cryptographically-verified canonicalized message produced under the canonicalization- algorithm-pair THIS page documents, AND DMARC alignment per RFC 7489 §3.1.1 requires the DKIM d=-domain to align with the RFC5322.From-domain for the composite verdict to pass — the per- publisher per-selector canonicalization- algorithm-pair THIS page documents is the upstream cryptographic-binding contract closing the IP-only-authentication-misses- header-spoofing compositeness gap the spoke enumerates as dim (ii); (iii) SPF- 10-DNS-lookup-cap permerror dimension ↔ per-publisher per-selector <selector>._domainkey.< domain> TXT-RR per-message single- lookup contrast — SPF permerror per RFC 7208 §4.6.4 is produced when the per-message receiver- side SPF evaluation breaches the 10-DNS- lookup cap or the 2-void-lookup cap; per-publisher per-selector DKIM signature verification per RFC 6376 §6 requires only a SINGLE per-message DNS lookup of <selector>._domainkey.< domain> TXT-RR whose record- format byte-grammar is the upstream publication discipline producing the per- message canonicalized signature THIS page documents — the per-publisher per-selector single-lookup contract structurally complements the SPF-cascade-recursive- lookup budget the spoke enumerates as dim (iii); (iv) SPF-lacks-alignment-to- RFC5322.From dimension ↔ DKIM-aligned-pass- leg of DMARC composite-verdict disjunction — the spoke's 4th SPF-insufficiency dimension is the STRUCTURAL ABSENCE of any SPF coupling to the RFC5322.From header (SPF binds only to RFC5321.MailFrom envelope); the DKIM- aligned-pass-leg of DMARC composite-verdict disjunction per RFC 7489 §6.6.2 is the SECOND authentication-leg whose alignment criterion (DKIM d=-domain matches RFC5322.From per RFC 7489 §3.1.1) IS THE STRUCTURAL CLOSURE of this gap; the canonicalization-algorithm-pair THIS page documents IS the load-bearing upstream contract producing the per-publisher per- selector cryptographically-bound canonicalized signature whose DMARC- alignment-evaluated d=-domain closes the SPF-lacks-alignment-to- RFC5322.From compositeness gap dim (iv). Read the why-SPF-alone-insufficient spoke when designing the per-publisher per- selector DKIM canonicalization-discipline THIS page documents as the operator-side instrumentation closing the foundational SPF-insufficiency compositeness catalogue whose 4 dimensions the canonicalization- algorithm-pair choice structurally addresses.
• SPF mechanisms explained — the canonical SPF mechanism / qualifier / modifier reference. Sibling to this page in the SPF + DKIM mechanism-vocabulary cluster.
• SPF permerror vs temperror — the CROSS-PROTOCOL-RESULT-CODE- PARALLEL companion to this DKIM canonicalization reference. Where THIS page documents the RFC 6376 §3.4 c=relaxed/simple canonicalization algorithm choice and the receiver-side DKIM result-code catalogue (dkim=pass/fail/neutral/temperror/ permerror/policy/none) produced under canonicalization-divergence failure modes (forwarder rewrite, MLM footer injection, anti-virus body modification), the SPF permerror-vs-temperror spoke is the RFC 7208 §2.6 SPF result-code catalogue companion whose receiver-side parse-vs-evaluation-vs-DNS-error classification discipline mirrors the DKIM result-code discipline THIS page documents. The CROSS-PROTOCOL-RESULT- CODE-PARALLEL cross-reference establishes FOUR structurally-distinct cross-protocol receiver-side parse-failure classification dimensions: (i) permerror result-code parallel — SPF permerror per RFC 7208 §2.6 (publisher-side syntax error, 10-DNS-lookup-budget exceedance, void-lookup cap exceedance) parallels DKIM permerror per RFC 6376 §6.1.1 (publisher-side syntax error in v=DKIM1 sentinel / p=<base64-pubkey> encoding / 255-byte TXT-chunk concatenation bug); both are publisher- side-fixable AND structurally distinct from temporary-DNS issues; THIS page's canonicalization-implementation-bug publisher-side failure class produces dkim=permerror structurally parallel to SPF permerror at the publisher-side- syntax-error layer; (ii) temperror result-code parallel — SPF temperror per RFC 7208 §2.6 (authoritative-nameserver outage, recursive-resolver 5-second timeout, anycast-nameserver consistency drift during DNS publication propagation) parallels DKIM temperror per RFC 6376 §6.1.1 (transient DNS-resolver failure looking up <selector>._domainkey. <domain>); both are retry-friendly AND structurally distinct from permanent-publisher-side errors; receiver-side both surface RFC 1035 DNS-rcode-2 (SERVFAIL) as temperror rather than permerror; (iii) publisher-side-error-vs-receiver-side- evaluation classification parallel — SPF permerror is publisher-side syntax/budget violation (publisher fixes RFC 7208 §4.6.4 budget); SPF fail/softfail/neutral/pass are receiver-side evaluation outcomes (publisher's qualifier choice -all/~all/?all/+all determines which); DKIM permerror is publisher-side syntax/encoding violation; DKIM fail/neutral/pass are receiver-side evaluation outcomes; THIS page's c=relaxed/simple canonicalization choice produces receiver-side dkim=fail/pass outcomes under forwarder-rewrite conditions, NOT publisher-side permerror — the cross-protocol distinction surfaces WHICH-LAYER-FIXES-WHICH-FAILURE-CLASS operator runbook; (iv) DMARC-evaluation-of-permerror-as-fail- AS-CRITICAL-PROTOCOL-BYPASS-AT-RFC-7489- §4.2 parallel — DMARC RFC 7489 §4.2 evaluation algorithm treats SPF permerror AS the "no policy applicable" verdict for the SPF leg (per RFC 7208 §2.6 normative semantics); this opens a STRUCTURAL spoofing bypass where the publisher's INTENDED SPF authentication policy collapses entirely; THIS page's DKIM permerror under canonicalization- implementation-bug class structurally parallels — DMARC's §4.2 evaluator likewise treats DKIM permerror as leg-unavailable, requiring the SPF-or-DKIM OR-conjunction to provide the surviving leg for authentication verdict. Pair this page (the DKIM canonicalization algorithm reference) with the SPF permerror-vs-temperror spoke (the SPF result-code RFC-7208- §2.6 reference) when an operator encounters cross-protocol receiver- side parse-failure verdicts and needs to classify the publisher-side-vs- receiver-side-vs-DNS-transient layer responsible for the failure — both protocols' result-code catalogues share the same classification discipline that underpins receiver-side authentication- verdict attribution.
• Forwarding issues with SPF — the focused operational deep dive on the forwarding scenarios that break SPF (the forwarder-induced DKIM failures documented in section 7 of this page have parallel SPF failure modes covered there).
• DMARC record tags explained — the DMARC tag-by-tag reference (p, sp, np, pct, rua, ruf, adkim, aspf, fo, ri, rf). DMARC alignment binds the DKIM verification result (which depends on canonicalization) to the From: domain.
• DMARC alignment explained — the identifier-alignment deep dive (strict vs relaxed for both adkim and aspf). DKIM alignment requires the signing d= domain to align with the From: header organisational domain — canonicalization does not affect alignment, but a canonicalization failure produces a DKIM result of fail which (combined with non-aligned SPF) produces a DMARC fail.
• DKIM alignment with DMARC — the DKIM-side alignment deep dive (the PROTOCOL-COMPUTATION-FEEDS-ALIGNMENT companion to this canonicalization reference) — the PROTOCOL-COMPUTATION-FEEDS-ALIGNMENT companion documenting the DKIM-side alignment rules whose verdict depends on the canonicalization choices THIS page documents. Where THIS page is the canonicalization deep dive (the c= tag, the four canonicalization combinations simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed, the body-hash bh= computation feeding the signature b= value, the FWS/WSP folding rules, the body length-limit l= trap, the simple-canon forwarder-rewrite breakage), the DKIM-alignment-with-DMARC spoke is the DOWNSTREAM CONSUMER documenting how the canonicalization-dependent DKIM verification result feeds into the identifier-alignment computation that determines the DMARC verdict — the d= tag in the signature header becomes the DKIM-aligned identifier compared against the RFC 5322 From: organisational domain (strict mode: exact match; relaxed mode: PSL-organisational-domain match). The DKIM-DMARC interaction has FIVE canonicalization-mediated failure modes the cross-reference exposes: (i) body-hash mismatch breaks alignment indirectly — a simple body canonicalization plus a trailing-whitespace-rewriting forwarder produces bh= mismatch → DKIM=fail → DMARC requires SPF alignment to pass, which often is also broken at the forwarder hop; (ii) signing-domain (d=) canonicalization is identifier-side — the canonicalization mode does NOT rewrite the d= tag value (canonicalization applies to the body and headers being SIGNED, not the signing-identity declaration), so the DKIM-aligned-identifier comparison uses the raw d= value regardless of canonicalization choice; (iii) relaxed header canonicalization preserves alignment across MIME header rewrites — relaxed header canonicalization is the load-bearing choice that survives mailing-list footer injection AND the From-header-CRLF-rewrite common in legacy MTAs, so a c=relaxed header canon keeps DKIM-alignment passing where c=simple would have broken it; (iv) body length-limit (l=) is an alignment-preservation trade-off — adding l= means a forwarder can append a footer without breaking the body hash, but it also means an attacker can append malicious content while DKIM-aligned, which is the canonical operational tension between alignment preservation and DKIM-replay attack surface; (v) third-party-sender alignment depends on canonicalization-compatible re-signing — when a SaaS sender re-signs with the customer's CNAME-delegated key, the SaaS's canonicalization choice (often relaxed/relaxed by default) is what determines whether the re-signed message survives downstream forwarder hops while maintaining customer-domain alignment. Operators landing here for canonicalization choice need the DKIM-alignment-with-DMARC procedural companion to understand how those choices feed the downstream DMARC verdict.
• ARC explained (RFC 8617 Authenticated Received Chain) — the FORWARDER-RELAY-PRESERVATION-OF- PER-HOP-AUTHENTICATION-VERDICT-VIA-DKIM- FORMAT-AMS-AND-AS-SIGNATURE companion to this DKIM canonicalization-algorithm reference. Where THIS page documents the RFC 6376 §3.4 canonicalization-algorithm pair (c=relaxed/relaxed / c=simple/simple / c=relaxed/simple / c=simple/relaxed) — the publisher-side per-header / per-body canonicalization-choice discipline whose per-pair byte-level normalisation determines DKIM-signature-survival through the multi-hop transit topology — the ARC-explained spoke documents the STRUCTURAL INHERITANCE of those exact canonicalization-algorithm pairs at the per-hop ARC-Message-Signature (AMS) + ARC-Seal (AS) signature publication boundary every forwarder-relay materialises across FOUR canonicalization-algorithm- inheritance dimensions: (i) ARC- Message-Signature (AMS) canonicalization- pair inheritance from DKIM c=-tag mechanics — the per-hop ARC sealer publishes an ARC-Message-Signature header whose c=-tag value uses the IDENTICAL four-pair grammar THIS page documents (c=relaxed/relaxed / c=simple/simple / mixed pairs), with the canonical sealer-side choice being c=relaxed/relaxed for maximum next-hop-forwarder-survival — the per-hop AMS thus inherits the DKIM-style body-hash + header-hash construction THIS page documents at every forwarder-hop in the chain; (ii) ARC-Seal (AS) signature canonicalization-pair always c=relaxed/relaxed per RFC 8617 §5.1.2 constraint — the per-hop ARC-Seal MUST use c=relaxed/relaxed canonicalization (the RFC-mandated sealer-side constraint distinct from the publisher-choice freedom for AMS); the AS signature covers the cumulative chain of prior AMS + AS headers using THIS page's c=relaxed/relaxed byte-normalisation rules — the canonicalization-algorithm chosen at every prior hop's AMS publication directly determines whether the per-hop AS signature reconstructs the verbatim signed-header-set at the receiver-side chain-validation boundary; (iii) per-hop forwarder- body-modification survival under the inherited canonicalization-pair choice — when a forwarder adds a subject-line prefix ([ListName]), injects a footer (mailing-list unsubscribe block), or re-encodes body content from 7BIT to QUOTED-PRINTABLE, the originator's DKIM signature breaks under c=simple/simple body canonicalization but survives the whitespace-normalisation under c=relaxed/relaxed; the per-hop ARC-AMS published by the forwarder preserves the per-hop authentication-results verdict (the cv=pass / cv=fail / cv=none chain-validation outcome RFC 8617 §5.2 enumerates) even when the underlying DKIM signature breaks at the modification point — the canonicalization-pair choice THIS page documents determines BOTH the DKIM-survival outcome AND the per-hop ARC-AMS body-hash-recomputability outcome at the next-hop validator; and (iv) receiver-side chain- validation reconstructs the per-hop canonicalization-pair selection from each AMS c=-tag byte value — the final-hop receiver's ARC-chain validator walks the cumulative ARC-AMS chain in instance-order (i=1 → i=2 → i=n), reading each per-hop AMS c=-tag value to determine the per-hop canonicalization-algorithm the per-hop sealer used at signing time — the per-hop validator then reconstructs the per-hop signed-byte- sequence using THIS page's RFC 6376 §3.4 canonicalization-algorithm bytes-exactly-matching the sealer's signing-time canonicalization output; any per-hop canonicalization-byte divergence between sealing-time and validation-time produces a per-hop cv=fail verdict that downstream consumers (DMARC alignment evaluator, BIMI selector, mailbox- provider trust-signal aggregator) consume. Pair THIS DKIM canonicalization reference with the ARC-explained spoke when scoping the publisher-side canonicalization-pair selection for a DKIM-signed outbound stream that traverses mailing-list mediators or forwarder-relay chains — the per-pair canonicalization choice THIS page documents IS the load-bearing per-hop signature-survival contract the downstream ARC-AMS / ARC-Seal chain the forwarder publishes inherits verbatim at every per-hop publication boundary in the chain.
• DMARC troubleshooting — the seven canonical DMARC failure patterns. DKIM body-hash mismatch is one of the most common patterns and the diagnostic workflow in section 8 of this page is the deep dive on that pattern.
• Email authentication ecosystem — the cluster-intro pillar surveying SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC interlocking.
• Email authentication glossary — the term-of-art reference covering canonicalization, simple, relaxed, c= tag, l= tag, bh=, b=, signature, body hash, FWS, WSP, CRLF, and every other vocabulary item this page uses.
• Email security & privacy glossary — the DKIM-CANONICALIZATION-MECHANISM- RESOLVES-BACK-TO-SECURITY-AND-PRIVACY- VOCABULARY-DEFINITIONS-AT-FOUR-AXES-OF-THE- THREAT-AND-DEFENSE-CATALOGUE companion to this DKIM canonicalization mechanism reference. Where THIS page documents the canonicalization mechanism at the protocol- mechanic byte level (RFC 6376 §3.4: the c=<header-canon>/<body-canon> tag value-grammar with simple/relaxed choice per side, §3.4.1 simple header canonicalization preserving bytes exactly as transmitted, §3.4.2 relaxed header canonicalization with whitespace normalization + FWS replacement + WSP replacement + case-folding, §3.4.3 simple body canonicalization preserving body bytes, §3.4.4 relaxed body canonicalization with trailing-CRLF trimming + multi-blank-line collapse + WSP replacement, and the resulting canonicalized-byte-sequence that the bh= body hash + b= signature commit), the email-security-and- privacy-glossary spoke is the THREAT-AND- DEFENSE-VOCABULARY companion (distinct from the email-authentication-glossary's protocol- mechanic-vocabulary role at line 2039 of this page) documenting the canonical single-sentence definitions for four threat-and-defense terms-of-art whose OPERATIONAL-MEANING the canonicalization mechanism THIS page documents directly engages with: (i) body-modification threat-class — the glossary's canonical definition of body-modification as the adversarial-or-forwarder-induced post-signing change to the message body is what the c=<.>/<body-canon> choice on THIS page determines tolerance of: simple/simple breaks on any byte change; relaxed/relaxed tolerates the bounded MLM-canonical body modifications (trailing-CRLF, blank-line-collapse, WSP normalization); (ii) signature- replay-attack defense — the glossary's canonical definition of DKIM-signature-replay is what the canonicalization-defined-immutable-byte- sequence on THIS page bounds: the b= signature commits the canonicalized header-bytes + canonicalized body-bytes + tag-list-bytes, all of which a replay attacker must reproduce exactly to forward a stolen signed message; (iii) header-tampering threat-class — the glossary's canonical definition of header-tampering as the adversarial-or-forwarder-induced change to a signed header is what the h=<signed-header-set> tag + canonicalization-mechanism on THIS page defends against: only headers enumerated in h= are canonicalized-into-the-signed-bytes; any non-enumerated header can be tampered-with without invalidating b=; any enumerated header that is modified post-signing causes b= verification to fail; (iv) per- hop forwarder-modification threat-class — the glossary's canonical definition of forwarder-modification as the non-adversarial-but-legitimate change a forwarder applies to a message during relay is what the relaxed/relaxed canonicalization-pair on THIS page was specifically designed to TOLERATE without invalidating the signature (whitespace normalization survives MUA whitespace-rewriting; trailing-CRLF trimming survives MTA line-ending normalization; multi-blank-line collapse survives MLM body modifications). Read the email-security-and-privacy-glossary spoke alongside this canonicalization mechanism reference when designing the forensic-investigation workflow that must correlate canonicalization-pair- choice on the publisher-side with the body-modification-vs-replay-vs-tamper-vs- forwarder-modification threat-class attribution at the receiver-side per-message DKIM verdict — the glossary is the canonical security-and-privacy- vocabulary substrate; THIS page is the canonical canonicalization-mechanism protocol-mechanic reference whose configuration determines the per-threat- class defense profile the glossary's vocabulary catalogues.
• MTA-STS for Microsoft 365 — the M365-TENANT-MESSAGE-LAYER-DKIM- CANONICALIZATION-CHOICE-AS-LOAD-BEARING- COMPLEMENT-TO-PER-M365-TENANT-TRANSPORT- LAYER-MTA-STS-POLICY-PUBLICATION-DISCIPLINE companion to this DKIM canonicalization reference. Where THIS page documents the per-publisher per-message RFC 6376 §3.4 simple-vs-relaxed canonicalization- algorithm-pair primitive (the c=simple/simple vs c=relaxed/relaxed publication- choice determining per-message DKIM-signature survival across per-forwarder-class header- and-body modifications), the mta-sts-for- microsoft-365 spoke is the STRUCTURALLY- PARALLEL transport-layer publication- discipline reference whose M365-tenant MTA-STS policy file at mta-sts.<d> HTTPS well-known-path + _mta-sts.<d> TXT-RR publication is the load-bearing transport-layer cert-trust-publication primitive complementary to the message- layer canonicalization-choice publication THIS page documents, at four cross-layer M365-tenant publication-discipline coupling dimensions: (i) Per-M365-tenant per- message message-layer DKIM-Signature-survival via canonicalization-choice + per-M365-tenant per-MX-host transport-layer TLS-handshake- success-via-MTA-STS-policy parallel — the per-publisher per-message c=relaxed/relaxed canonicalization- choice THIS page documents survives the EOP outbound body-modification pipeline (footer- injection, mailing-list-mediator-rewrite, per-recipient-personalisation) at the message-layer authentication-survival boundary; the per-M365-tenant per-MX-host MTA-STS-policy-file-driven STARTTLS-cert- trust-evaluation discipline the mta-sts-for- microsoft-365 spoke documents survives the per-receiver per-MX-host SMTP-handshake at the transport-layer cert-trust boundary; both publication-disciplines are load-bearing for per-publisher per-message complete end-to-end authentication-and-confidentiality survival at the M365-tenant boundary; (ii) Per-M365-tenant per-message canonicalization-choice + per-M365-tenant per-MX-host MTA-STS-policy file-content- publication composition — the per-publisher message-layer c=-tag value emission in the per-message DKIM-Signature header (THIS page) composes with the per-M365-tenant per-domain MTA-STS-policy file content publication (version: STSv1 + mode: enforce + per-MX-host- cert-trust-mode-discipline + max_age: constraint) into the per-M365-tenant per- domain complete-publication-discipline- stack the receiver-side cross-layer authentication-and-cert-trust-evaluation algorithm consumes at every per-message evaluation gate; (iii) Per-M365- tenant cross-layer publication-discipline coordination — message-layer canonicalization-choice vs transport-layer MTA-STS-policy-mode-and-max_age choice — the per-publisher per-message canonicalization-choice publication- discipline THIS page documents (typically c=relaxed/relaxed for per- forwarder-hop survival) is COORDINATED with the per-M365-tenant per-domain MTA-STS policy-mode-choice (testing → enforce stage gates per RFC 8461 §5) and per-domain max_age: publication discipline (24-hour minimum at deployment time, 1-week-to-1-year recommended steady- state) — both publication-disciplines require operator-side per-M365-tenant coordination across the per-domain DNS- zone-management + per-tenant Exchange- Online-signing-configuration surfaces; (iv) Per-M365-tenant per-message cross-layer authentication-and-cert-trust- publication-discipline-stack composition as load-bearing M365-tenant complete- publication-coverage — the per- M365-tenant per-domain complete cross- layer publication-discipline-stack composes message-layer (DKIM-Signature with c=relaxed/relaxed canonicalization-choice THIS page documents + DMARC-disjunction-evaluation-publication) with transport-layer (MTA-STS-policy-file- at-mta-sts.<d>-HTTPS- well-known-path-with-public-CA-cert-trust the mta-sts-for-microsoft-365 spoke documents + TLS-RPT-at-_smtp._tls.<d>- TXT-RR-publication-discipline-with-rua- mailbox-evidence-collection-stream) into the per-M365-tenant per-domain complete- cross-layer-publication-coverage at the per-message-survival-across-forwarder-and- transport-class-and-receiver-class boundaries the per-publisher per-message Bulk Sender Requirements 2024 compliance gate consumes at every per-receiver per- message evaluation. Read the mta-sts-for- microsoft-365 spoke ALONGSIDE this DKIM canonicalization reference whenever the protected domain is hosted on the M365 Exchange Online cloud tenant and the per- publisher per-message message-layer-DKIM- canonicalization-choice this page documents needs an M365-tenant-specific cross-layer publication-discipline-stack composition baseline for end-to-end authentication- and-confidentiality-survival across the per-forwarder-and-transport-class boundaries.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-MESSAGE-LAYER-DKIM- CANONICALIZATION-CHOICE-AS-LOAD-BEARING- COMPLEMENT-TO-PER-WORKSPACE-TENANT-TRANSPORT- LAYER-MTA-STS-POLICY-PUBLICATION-DISCIPLINE companion to this DKIM canonicalization reference. Where THIS page documents the per-publisher per-message RFC 6376 §3.4 simple-vs-relaxed canonicalization- algorithm-pair primitive (the c=simple/simple vs c=relaxed/relaxed publication- choice determining per-message DKIM-signature survival across per-forwarder-class header- and-body modifications), the mta-sts-for- google-workspace spoke is the STRUCTURALLY- PARALLEL transport-layer publication- discipline reference whose Workspace-tenant MTA-STS policy file at mta-sts.<d> HTTPS well-known-path + _mta-sts.<d> TXT-RR publication is the load-bearing transport-layer cert-trust-publication primitive complementary to the message- layer canonicalization-choice publication THIS page documents, at four cross-layer Workspace-tenant publication-discipline coupling dimensions: (i) Per- Workspace-tenant per-message message-layer DKIM-Signature-survival via canonicalization- choice + per-Workspace-tenant per-MX-host transport-layer TLS-handshake-success-via- MTA-STS-policy parallel — the per- publisher per-message c=relaxed/relaxed canonicalization-choice THIS page documents survives the Workspace outbound body- modification pipeline (Groups-mediator- rewrite, alias-rewriting, footer-injection, per-recipient-personalisation) at the message-layer authentication-survival boundary; the per-Workspace-tenant per-MX- host (aspmx.l.google.com + the four altN.aspmx.l.google.com hosts) MTA-STS-policy-file-driven STARTTLS- cert-trust-evaluation discipline the mta- sts-for-google-workspace spoke documents survives the per-receiver per-MX-host SMTP- handshake at the transport-layer cert-trust boundary; both publication-disciplines are load-bearing for per-publisher per-message complete end-to-end authentication-and- confidentiality survival at the Workspace- tenant boundary; (ii) Per-Workspace- tenant per-message canonicalization-choice + per-Workspace-tenant per-MX-host MTA-STS- policy file-content-publication composition — the per-publisher message-layer c=-tag value emission in the per-message DKIM-Signature header (THIS page) composes with the per- Workspace-tenant per-domain MTA-STS-policy file content publication (version: STSv1 + mode: enforce + per-MX-host- cert-trust-mode-discipline + max_age: constraint, with the five aspmx-tier MX hosts as the canonical per-Workspace-tenant per-MX-host enumeration) into the per- Workspace-tenant per-domain complete- publication-discipline-stack the receiver- side cross-layer authentication-and-cert- trust-evaluation algorithm consumes at every per-message evaluation gate; (iii) Per-Workspace-tenant cross-layer publication-discipline coordination — message- layer canonicalization-choice vs transport- layer MTA-STS-policy-mode-and-max_age choice — the per-publisher per- message canonicalization-choice publication- discipline THIS page documents (typically c=relaxed/relaxed for per- forwarder-hop survival) is COORDINATED with the per-Workspace-tenant per-domain MTA-STS policy-mode-choice (testing → enforce stage gates per RFC 8461 §5) and per-domain max_age: publication discipline (24-hour minimum at deployment time, 1-week-to-1-year recommended steady-state) — both publication-disciplines require operator-side per-Workspace-tenant coordination across the per-domain DNS-zone- management + per-tenant Workspace Admin Console-DKIM-signing-configuration surfaces; (iv) Per-Workspace-tenant per- message cross-layer authentication-and-cert- trust-publication-discipline-stack composition as load-bearing Workspace-tenant complete-publication-coverage — the per-Workspace-tenant per-domain complete cross-layer publication-discipline-stack composes message-layer (DKIM-Signature with c=relaxed/relaxed canonicalization- choice THIS page documents at the Workspace google._domainkey.<d> publication primitive + DMARC-disjunction- evaluation-publication) with transport-layer (MTA-STS-policy-file-at-mta-sts.<d>- HTTPS-well-known-path-with-public-CA-cert- trust the mta-sts-for-google-workspace spoke documents + TLS-RPT-at-_smtp._tls.<d>- TXT-RR-publication-discipline-with-rua- mailbox-evidence-collection-stream) into the per-Workspace-tenant per-domain complete- cross-layer-publication-coverage at the per- message-survival-across-forwarder-and- transport-class-and-receiver-class boundaries the per-publisher per-message Bulk Sender Requirements 2024 compliance gate consumes at every per-receiver per-message evaluation. Read the mta-sts-for-google-workspace spoke ALONGSIDE this DKIM canonicalization reference whenever the protected domain is hosted on the Google Workspace cloud tenant and the per-publisher per-message message- layer-DKIM-canonicalization-choice this page documents needs a Workspace-tenant-specific cross-layer publication-discipline-stack composition baseline for end-to-end authentication-and-confidentiality-survival across the per-forwarder-and-transport-class boundaries.
• DMARC for transactional email — the PER-TRANSACTIONAL-ESP-PER-CUSTOMER- STREAM-PER-MESSAGE-BODY-MODIFICATION-VS- CANONICALIZATION-CHOICE-COORDINATION- DISCIPLINE-COMPANION-AT-FOUR-RELAXED-VS- SIMPLE-CANONICALIZATION-VS-PER-ESP-BODY- REWRITE-COORDINATION-DIMENSIONS companion to this DKIM-canonicalization reference. Where THIS page documents the RFC 6376 §3.4 DKIM body-canonicalization-mode choice (relaxed vs simple body canonicalization + relaxed vs simple header canonicalization + the c=<header-canon>/<body- canon> per-message DKIM- Signature tag publication discipline the per-publisher per-selector DKIM- signing pipeline emits), the transactional-email spoke is the canonical per-transactional-ESP-stream per-message body-modification-survival coordination reference whose per-ESP- stream per-customer-stream relay- rewriting boundary IS the LOAD-BEARING upstream operational coupling the per-publisher per-selector canonicalization-mode choice THIS page documents must be coordinated with at four relaxed-vs-simple canonicalization-vs-per-ESP-body- rewrite coordination dimensions: (i) per-transactional-ESP per- customer-stream unsubscribe-link- injection vs per-publisher per- selector body-canonicalization-mode choice coordination — transactional ESPs (SendGrid / Mailgun / Postmark / Amazon SES / SparkPost / Salesforce Marketing Cloud / Customer.io) often inject per-customer per-message unsubscribe- link footers AFTER the publisher's pre-ESP DKIM-Signature is applied at the upstream signing boundary; under c=*/simple body- canonicalization the per-publisher per-message DKIM-Signature fails at the receiver-side bh-tag verification because the unsubscribe- link byte-injection changes the message body the SHA-256 bodyhash was computed over; under c=*/relaxed body- canonicalization the per-publisher per-message DKIM-Signature STILL fails because RFC 6376 §3.4.4 relaxed body-canonicalization normalizes whitespace and trailing empty lines but does NOT remove injected non-whitespace bytes — the per-publisher per-selector signature must be applied AFTER the per-ESP body-rewriting boundary, OR the per-ESP-stream must re-sign with its own per-ESP-selector after the body- rewriting boundary; (ii) per- transactional-ESP per-customer-stream tracking-pixel-injection vs per- publisher per-selector body- canonicalization coordination — per-ESP-stream open-rate-tracking and click-tracking instrumentation injects per-message per-recipient unique <img src="<tracking- pixel-url>"> HTML and per-link <a href="<tracking- redirect-url>"> wrapper bytes per-recipient at message- enqueue time AFTER the per-publisher per-selector DKIM-Signature would be applied at the upstream signing boundary; per-recipient body- modification is fundamentally incompatible with per-publisher per- message DKIM-Signature THIS page documents the canonicalization-mode choice for — the per-transactional- ESP-stream per-message DKIM- Signature MUST be re-applied per- recipient at the per-ESP-egress boundary AFTER the per-recipient body-modification boundary; (iii) per-transactional-ESP per- customer-stream relaxed-vs-simple body-canonicalization tag publication- discipline floor coordination — per-transactional-ESPs typically default to per-ESP-egress per-message publication of c=relaxed/relaxed at the per-ESP-stream DKIM-Signature header emission boundary (per the RFC 6376 §3.4 recommendation for relay- survivability) — the per- transactional-ESP-stream per-message canonicalization-mode publication- discipline floor IS the operational discipline this canonicalization page documents the canonicalization-mode- choice rationale for; (iv) per-transactional-ESP per- customer-stream l=<body-length>-tag- vs-per-publisher-per-selector body- length-bounding signature scope coordination — per- transactional-ESP per-customer-stream per-message DKIM-Signature publications occasionally bound the per-message bodyhash scope via the RFC 6376 §3.5 l=<body- length>-tag (signing only the first l= bytes of body material) to allow per-ESP- stream body-append-only modifications (e.g. appending unsubscribe-link footer AFTER signing) without breaking the per-message bodyhash verification — the per-transactional- ESP-stream l=-tag publication-discipline rationale IS the operational discipline this canonicalization page documents the signature-scope-bounding rationale for. Read the transactional-email spoke ALONGSIDE this DKIM- canonicalization reference whenever a per-transactional-ESP-stream per- customer-stream body-modification- survival coordination question emerges — THIS page gives the per- publisher per-selector canonicalization-mode choice algorithm, the transactional-email spoke gives the per-transactional- ESP-stream per-customer-stream operational-discipline reference the per-publisher per-selector canonicalization-mode-choice ladder bottoms out on at the per- transactional-ESP per-customer- stream per-message body-modification- survival boundary.
• Email deliverability — the c=ALGORITHM-PAIR-CHOICE-AS-LOAD- BEARING-UPSTREAM-INPUT-INTO-PER-MAILBOX- PROVIDER-DKIM-PASS-SURVIVAL-RATE companion to this DKIM canonicalization reference. Where THIS page documents the RFC 6376 §3.4 simple-vs-relaxed header/ body canonicalization-algorithm-choice discipline (per-publisher per-selector c=header/body-tag publication + per-canonicalization-mode per-forwarder- hop body-modification-survival-rate coordination + per-mode l=-tag body-length- bounding-signature-scope-vs-forwarder- rewrite-survival trade-off), the email- deliverability spoke is the per-publisher per-domain BUSINESS-OUTCOME reference whose per-publisher per-domain inbox- placement verdict at every major mailbox provider IS the downstream-consumer of the per-publisher canonicalization-choice discipline at four canonicalization-to- deliverability coupling dimensions: (i) relaxed/relaxed canonicalization as per-mail-stream per-forwarder-hop DKIM-Signature-survival-rate input into Gmail/Outlook/Yahoo/Apple/Comcast receiver-side DKIM=pass rate — every per-publisher per-mail-stream through a body-modifying forwarder (mailing-list rewrite-footer / quoted- printable-re-encoding / line-ending normalisation) survives DKIM-Signature verification ONLY when the publisher signs with relaxed/relaxed canonicalization; the per-publisher per-domain receiver- side DKIM=pass-rate THIS page's canonicalization-choice algorithm drives IS the load-bearing input into the per-publisher per-domain DMARC-aligned- pass-rate verdict the email-deliverability framework's Section 2 (authentication- verdict at receiver) consumes; (ii) simple/simple canonicalization as per-mail-stream per-message body- byte-exact-survival-rate ceiling constraint feeding deliverability degradation at body-modifying forwarder hops — when a per-publisher per-mail-stream publishes with simple/simple canonicalization but routes through body-modifying forwarders, the per- message body-byte-exact-survival-rate ceiling produces a per-publisher per- domain DKIM=fail elevation that the per-receiver reputation model registers as per-publisher authentication-posture- degradation evidence at the per-message verdict boundary — the per-publisher per- domain inbox-placement-rate-vs-spam- folder-rate impact the email- deliverability framework's Section 6 (engagement metrics) and Section 8 (SMTP-bounce-taxonomy) document; (iii) l=-tag body-length-bounding- signature-scope-vs-forwarder-rewrite- survival trade-off as load-bearing per-publisher per-stream deliverability- risk-management primitive — the per-publisher per-stream l=- tag scoping discipline (sign only first N bytes vs sign full body) THIS page documents IS the per-publisher per- stream deliverability-risk-management primitive that simultaneously optimizes for forwarder-rewrite-survival-rate (the Section 6 engagement-metrics floor) and body-tampering-attack-detection-rate (the Section 12 BEC-and-spoofing-class-evidence floor) the email-deliverability framework's cross-section deliverability composition operates on; (iv) per-publisher per-selector canonicalization-mode- uniformity-across-mail-streams as load- bearing per-domain DKIM=pass-rate-floor- establishment for Bulk Sender Requirements 2024 compliance — Gmail/Yahoo Feb 2024 Bulk Sender Requirements thresholds require per-publisher per-domain DKIM=pass- rate floors; per-publisher per-selector canonicalization-mode-uniformity-across- mail-streams (consistent relaxed/relaxed adoption across staff / marketing / SaaS / transactional-ESP per-customer-stream egress) IS the per-publisher per-domain DKIM=pass-rate-floor establishment that the email-deliverability framework's Section 13 (Bulk Sender Requirements deliverability floor) cross-references. Read the email-deliverability spoke ALONGSIDE this DKIM canonicalization reference whenever a per-publisher per- selector canonicalization-choice-to- per-receiver-deliverability attribution question emerges — THIS page gives the per-publisher per-selector c=-tag publication-choice algorithm, the email- deliverability spoke gives the per- publisher per-domain inbox-placement BUSINESS-OUTCOME framework that canonicalization-choice ultimately feeds at the receiver-side reputation- model verdict boundary.
• Email Header Analyzer — the DMARC Analyzer tool that parses a raw message and surfaces every DKIM-Signature tag (c=, a=, d=, s=, h=, bh=, b=, l=) plus the Authentication-Results verdict, automating steps 2-4 of the forensic workflow.
• Domain Security Checker — verifies the DKIM selector DNS record (which publishes the public key the verifier uses to check the b= signature) plus the full SPF / DMARC / BIMI / MTA-STS / TLS-RPT / CAA stack.
• DNS Record Generator — the DKIM record-generator wizard (Enterprise plan). Generates a syntactically-correct selector record with the public key in the canonical p= format.
• DMARC forensic reports (RUF / AFRF) — the PER-MESSAGE-CANONICALIZATION-CHOICE- AS-PER-AFRF-EVIDENCE-DECODE companion to this DKIM-canonicalization reference. Where THIS page documents the RFC 6376 §3.4 c=simple/simple vs relaxed/ simple vs simple/relaxed vs relaxed/relaxed canonicalization- mode catalogue and the per-mode whitespace / header-folding / case-folding / header- reordering rules the receiver-side verifier applies during bh= body-hash and b= signature-hash recomputation, the DMARC-forensic-reports spoke is the per- message AFRF / IODEF evidence-stream reference documenting the RFC 6591 forensic-report channel whose per-message message/rfc822 embedded-part preservation is the FORENSIC- GRAIN artefact the operator's incident- response team uses to attribute a per-message dkim=fail verdict to the specific canonicalization-mode-vs-intermediary root cause. The PER-MESSAGE-CANONICALIZATION- CHOICE-VS-AFRF-EVIDENCE-DECODE cross-reference establishes FOUR structurally-distinct canonicalization-mode-vs-AFRF-evidence-row dimensions: (i) per-message c=simple/simple-mode bh= body-hash mismatch AFRF evidence — the per- AFRF embedded message/rfc822 part preserves the byte-exact body the intermediary delivered, against which the receiver recomputed bh= using the strictest mode — under simple/simple a single trailing whitespace insertion, a CRLF → LF conversion, or any MIME re-encoding by an intermediary produces a bh= divergence; the per-AFRF embedded part lets the SIRT diff the signed-body byte-stream (reconstructed from the per-publisher canonical body) against the as-delivered body to attribute the per-message failure to the specific intermediary transformation — a forensic evidence channel the receiver-side aggregate dkim=fail verdict alone does NOT surface; (ii) per-message c=relaxed/relaxed-mode header- canonicalization mismatch AFRF evidence — the per-AFRF embedded part preserves the byte-exact From: / Subject: / Date: / per- h=-enumerated header set the receiver canonicalized into the b= recomputation — under relaxed header-canonicalization an intermediary Subject: prefix injection (e.g. [EXTERNAL] tags added by per-tenant Microsoft 365 transport rules) or a per-mailing-list-MTA Subject: rewrite produces a b=-hash divergence; the per-AFRF embedded-part header-byte-preservation lets the SIRT identify which per-h=- enumerated header the intermediary rewrote and attribute the per-message failure to the per-intermediary-policy transformation; (iii) per-message canonicalization-mode- mismatch AFRF evidence — the per-AFRF embedded part preserves the byte-exact DKIM-Signature header containing the c=<mode-pair> tag the publisher declared, which the receiver applied during recomputation — a per-AFRF stream showing a sudden shift in the c= tag distribution mid- rotation-cycle is the canonical evidence that the publisher's outbound DKIM-signer configuration was changed (intentionally or through a per-tenant Office 365 / Google Workspace config drift) without coordinated receiver-side cache invalidation; the DMARC-forensic-reports spoke documents the per-AFRF per-message c= tag byte-preservation enabling this per- rotation-cycle canonicalization-mode shift attribution; (iv) per-message l= body-length-tag canonicalization boundary AFRF evidence — the per-AFRF embedded part preserves the byte-exact body below and above the l=<octets> signing-boundary the per-RFC 6376 §3.5 publisher declared — the l= tag is a per-message signing-boundary that lets per-mailing-list- MTA footer-appending intermediaries legitimately append content past the signed boundary without invalidating bh=; a per-AFRF stream showing l=- boundary-overshoot bh=-mismatch evidence per-message identifies intermediaries that rewrite body content INSIDE the per-l=-tag signed boundary — a forensic-grain root cause attribution the receiver-side dkim=fail aggregate verdict alone does NOT surface. Read the DMARC-forensic-reports spoke alongside THIS DKIM-canonicalization-mode reference whenever the operator authors the per-DKIM-fail- incident SIRT playbook — the per-message AFRF / IODEF evidence stream is the SOLE per-message-byte-fidelity per-canonicalization- mode-vs-intermediary-transformation root- cause attribution channel the receiver-side aggregate dkim=fail verdict granularity does NOT preserve.
• MTA-STS explained — the per-publisher per-policy-domain transport-layer MTA-STS policy-publication- discipline companion to this DKIM- canonicalization-mode reference. Where THIS page documents the RFC 6376 §3.4 per- message per-signature c=simple/simple vs c=relaxed/relaxed body-and- header byte-normalization grammar at the application-layer DKIM-signature verification 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 message-integrity publication discipline parallel to transport-layer hop-confidentiality publication discipline at distinct protocol layers — both the per- publisher per-selector DKIM- canonicalization-mode publication discipline THIS page documents (the application-layer per-message message- integrity-and-authenticity primitive) and the per-publisher per-policy-domain MTA-STS-policy publication discipline the spoke documents (the transport-layer per-hop confidentiality-and-MITM- resistance primitive) are per-publisher per-domain publication-discipline 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 DNS-TXT-RR-byte-grammar-publication discipline parallel at distinct DNS- scope coordinates — both the per-publisher per-selector selector._domainkey.<d> TXT-RR (carrying the public-key material the per-message DKIM-Signature canonicalization-mode-aware verification consumes) and the per-publisher per- policy-domain _mta-sts.<d> TXT-RR (carrying the policy-ID version pointer the per-receiver MTA-STS-policy discovery consumes) are per-publisher per-domain DNS-TXT-RR-byte-grammar publication primitives at distinct per-publisher per-domain DNS-scope coordinates; (iii) per-publisher per-domain signed-bytes-vs-encrypted-bytes integrity-domain parallel at distinct protocol layers — the per- publisher per-selector DKIM- canonicalization-mode publication discipline THIS page documents commits the per-publisher per-selector signed- bytes integrity-domain at the application layer (which bytes of the per-message header + body the per- publisher per-selector DKIM-Signature binds to) and the per-publisher per- policy-domain MTA-STS-policy publication discipline the spoke documents commits the per-publisher per-policy-domain encrypted-bytes confidentiality-domain at the transport layer (which per-hop SMTP-session bytes the per-publisher per-policy-domain MTA-STS-policy 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 canonicalization-mode-aware 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- selector DKIM-canonicalization-mode application-layer 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-canonicalization- mode publication discipline THIS page documents.
• TLS-RPT record syntax — the per-publisher per-policy-domain UNDERSCORE-PREFIXED-TXT-RR-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- PEER-PUBLICATION-DISCIPLINE-COUSIN companion to this RFC 6376 §3.4 DKIM-canonicalization- mode reference. Where THIS page documents the per-publisher per-selector c=simple/simple vs c=relaxed/relaxed body-and- header byte-normalization grammar at the application-layer DKIM-signature verification boundary, 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- publication discipline boundary. Three CROSS-LAYER-PUBLICATION-DISCIPLINE coupling dimensions the TLS-RPT-record-syntax spoke documents at the per-publisher per-domain underscore-prefixed-TXT-RR publication tier the DKIM-canonicalization application-layer publication discipline parallels at distinct protocol layers: (i) per-publisher per-domain DNS-TXT-RR-byte-grammar- publication discipline parallel at distinct DNS-scope coordinates per RFC 8552 (DNS Scoped Data via Underscore-Prefixed Labels) underscore-prefixed-label family — both the per-publisher per-selector selector._domainkey.<d> DKIM TXT-RR (carrying the per-selector public-key + algorithm-identifier byte- grammar the per-message DKIM-canonicalization- mode-aware verification consumes) and the per-publisher per-policy-domain _smtp._tls.<d> TLS-RPT TXT-RR (carrying the per-publisher per- policy-domain reporting-URI list the per- receiver per-domain TLS-failure aggregator consumes) are per-publisher per-domain DNS- TXT-RR-byte-grammar publication primitives at distinct per-publisher per-domain DNS- scope coordinates inside the SAME RFC 8552 underscore-prefixed-label family discipline; (ii) per-publisher per-domain application-layer message-integrity publication discipline parallel to transport- layer reporting-channel publication discipline at distinct protocol layers — both the per-publisher per-selector DKIM- canonicalization-mode publication discipline THIS page documents (the application-layer per-message message-integrity-and- authenticity publication primitive) and the per-publisher per-policy-domain TLS-RPT- reporting-URI publication discipline the spoke documents (the transport-layer per- domain TLS-failure-observability publication primitive) are per-publisher per-domain publication-discipline primitives at distinct protocol layers that COMPOSE at the per- publisher per-domain complete-stack authentication-plus-reporting deliverability- observability posture boundary; (iii) per-publisher per-domain signed-bytes-vs-reported-failures granularity boundary at distinct verdict-stream attribution tiers — the per-message per-canonicalization-mode DKIM-Signature verification verdict THIS page documents commits the per-publisher per-selector per-message message-integrity verdict at the application layer (which per-message header + body bytes the per-publisher per-selector DKIM-Signature binds to) and the per- receiver per-day per-publisher per-policy- domain TLS-RPT aggregate report the spoke documents commits the per-receiver per-day per-publisher per-policy-domain SMTP- session-level STARTTLS-failure observability verdict at the transport layer (which per- receiver per-publisher per-policy-domain per-day SMTP sessions failed transport-layer encryption-or-policy-enforcement). Read the TLS-RPT-record-syntax spoke ALONGSIDE this DKIM-canonicalization reference whenever the per-publisher per-domain operator AUTHORS the per-publisher per-domain underscore-prefixed- TXT-RR publication portfolio — the per- publisher per-selector DKIM-canonicalization- mode publication discipline THIS page documents is the per-publisher per-selector APPLICATION-LAYER publication primitive; the per-publisher per-policy-domain TLS-RPT- record-syntax spoke is the per-publisher per-policy-domain TRANSPORT-LAYER-REPORTING- PUBLICATION primitive that closes the per- publisher per-domain underscore-prefixed- TXT-RR publication portfolio at the per- publisher per-domain authoring tier.
• DMARC for Office 365 hybrid — the LOAD-BEARING per-hybrid-Exchange- tenant HYBRID-EXCHANGE-DUAL-EGRESS-DKIM- CANONICALIZATION-MODE-COORDINATION-AS- CROSS-EGRESS-LEG-PER-MESSAGE-HEADER-AND- BODY-CANONICALIZATION-MODE-COHERENCE- DISCIPLINE companion documenting the per- hybrid-Exchange-tenant DMARC + SPF + DKIM publication tutorial (the apex-zone DMARC TXT publication at _dmarc.<d>, the apex-zone SPF TXT publication authorising both the Exchange Online cloud- egress IP pool via include:spf.protection.outlook.com AND the on-prem Edge Transport / Mailbox server outbound IPs via operator-managed ip4: literals, the per- selector DKIM-CNAME publication for the Exchange-Online-egress leg, and the per- selector DKIM-TXT publication for the on- prem-egress leg). Where THIS page documents the RFC 6376 §3.4 per-message DKIM header and body canonicalization mode publication (the simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed c=-tag combinations, the header field name lowercasing and whitespace-folding semantics in relaxed header canonicalization, the trailing empty-line stripping and intra-line WSP collapse semantics in relaxed body canonicalization, the verbatim octet preservation in simple canonicalization), the DMARC-for-O365-hybrid spoke documents the per-hybrid-tenant DUAL-EGRESS DKIM- CANONICALIZATION-MODE COORDINATION DISCIPLINE — the per-tenant operator-side coordination challenge of ensuring the Exchange-Online-leg DKIM signing service (which canonicalizes per Microsoft-managed EOP defaults) and the on-prem-leg Exchange Server DKIM signing component (typically a third-party agent like Exchange-DKIM- Signer with its own per-config canonicalization-mode setting) PRODUCE per-message DKIM-Signature headers whose per-message canonicalization-mode declaration AGREES with the per-egress- leg signing-time canonicalization applied — otherwise the receiver-side verification fails because the per- message canonicalized hash this page documents would not match the per- message original hash the per-egress-leg signing service produced. Read THIS page when AUTHORING the per-message DKIM canonicalization-mode declaration; read the DMARC-for-O365-hybrid spoke when COORDINATING the per-tenant per-egress- leg DKIM canonicalization-mode CONSISTENCY across the dual-egress Exchange topology the per-tenant operator publishes.
• DMARC attacker bypass techniques — the ATTACKER-SIDE PER-MESSAGE DKIM- CANONICALIZATION-CHOICE-AS-BODY-HASH- SPOOFING-ATTACK-SURFACE threat-model companion to THIS page's per-message DKIM canonicalization-mode byte-grammar reference. Where THIS page documents the per-message c=relaxed/relaxed, c=relaxed/simple, c=simple/relaxed, and c=simple/simple header-and-body canonicalization-mode declarations and the per-message body-hash computation discipline (RFC 6376 §3.4) the per-publisher per- domain signing service applies before signing, the DMARC-attacker-bypass spoke documents the per-message body-hash- spoofing attack surface a per-publisher per- domain canonicalization-mode choice exposes to per-attacker cryptanalysis. Two concrete canonicalization-vs-attacker-bypass coupling axes the attacker-bypass spoke documents: (i) per-message c=relaxed/relaxed body- canonicalization tolerates more downstream- forwarder body modifications — which is BOTH the per-publisher-side deliverability win (relaxed canonicalization survives Google-Workspace forwarder footer- injection, Outlook.com forwarder Content- Type re-encoding, mailing-list footer append) AND the per-attacker-side body- hash-replay surface (an attacker who captures a per-message DKIM-signed payload can re-emit it with more aggressive body- modifications before the verifier's canonicalization re-collapses the differences to the captured body hash); (ii) per-message c=simple/simple body- canonicalization PRESERVES the per-message body-byte-stream verbatim — which eliminates the body-hash-replay attack surface BUT breaks the forwarder- deliverability surface, so the per-publisher per-domain canonicalization-mode choice the operator publishes is a per-publisher per- domain DELIVERABILITY-VS-BODY-HASH-REPLAY- RESISTANCE trade-off the per-publisher per- domain DMARC enforcement posture must evaluate at the signing-service publication boundary. Read THIS page when AUTHORING the per-publisher per-domain DKIM canonicalization-mode declaration; read the DMARC-attacker-bypass spoke when MODELING the per-message body-hash-spoofing attack surface the per-publisher per-domain canonicalization-mode choice exposes the per-publisher per-domain DMARC enforcement posture to.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the per-publisher per-domain DMARC policy-tier publication-discipline canonical reference (the p=none monitoring-mode tier, the p=quarantine spam-folder-disposition tier, the p=reject SMTP-time- rejection tier; the per-organisational- domain vs per-subdomain sp=-tag override discipline; the pct=-tag percentage-gradual-enforcement ramp discipline) whose per-publisher per- domain DMARC-policy-tier TIGHTENING decision IS GATED by the per-receiver per-day per-publisher per-domain DKIM- aligned-pass-rate floor — and that floor IS structurally determined by the per-publisher per-selector DKIM canonicalization-mode choice THIS page documents. The composition operates through FOUR per-publisher per-domain canonicalization-mode-choice-vs-DMARC- policy-tier-ramp coupling dimensions every per-publisher per-domain operator must reason about jointly: (i) per-publisher per-selector c=simple/simple mode choice as PER-PUBLISHER-PER-DOMAIN- STRICTEST-BODY-HASH-RESILIENCE-VS- WORST-INTERMEDIARY-SURVIVAL-RATE trade-off — per-publisher per-selector c=simple/simple choice provides the per-message body-hash- replay-resistance ceiling AT THE COST OF per-receiver per-day per- publisher per-domain DKIM-aligned- pass-rate floor regressions on every per-message MUNGING-VIA-MAILING-LIST, per-message HEADER-FOLDING-REWRITE, per-message UNICODE-NORMALIZATION- EXPANSION transformation; per- publisher per-domain operators targeting p=quarantine / p=reject ramp MUST verify per-publisher per-day per- receiver-source DKIM-aligned-pass- rate floor sustainability BEFORE proposing the policy-tier tightening commit; (ii) per-publisher per- selector c=relaxed/relaxed mode choice as PER-PUBLISHER-PER-DOMAIN- BEST-INTERMEDIARY-SURVIVAL-RATE-VS- DEGRADED-BODY-HASH-RESILIENCE trade- off — per-publisher per-selector c=relaxed/relaxed choice provides the per-receiver per-day per-publisher per-domain DKIM-aligned-pass-rate floor stability ceiling AT THE COST OF per-message body-hash-replay-resistance degradation under per-message canonicalization-mode-mismatch attacker bypass; per-publisher per- domain operators targeting p=reject ramp under per-message mailing-list-traffic- coverage requirements SHOULD prefer c=relaxed/relaxed as the per-publisher per-day DKIM- aligned-pass-rate floor stability primitive; (iii) per-publisher per- selector c=simple/relaxed + c=relaxed/simple hybrid mode choices as per-publisher per- domain INTERMEDIATE TRADE-OFF primitives — per-publisher per- selector hybrid-mode choices balance per-message body-hash-resilience against per-receiver per-day DKIM- aligned-pass-rate floor stability on a per-publisher per-domain per- selector dimensions tuned to the per-publisher per-domain per- receiver-source per-message intermediary-transformation profile; per-publisher per-domain operators executing per-publisher per-domain pct=10 → 25 → 50 → 100 stepwise DMARC enforcement- percentage ramp progression SHOULD evaluate the per-publisher per-day per-receiver-source per-step DKIM- aligned-pass-rate measurement at each pct=-step BEFORE advancing; (iv) per-publisher per- domain joint per-selector canonicalization-mode-choice + per-domain DMARC-policy-tier publication as the per-publisher per-domain JOINT per-selector- publication-discipline-and-per- domain-DMARC-publication-discipline coordination — per-publisher per- domain operators MUST treat per- selector canonicalization-mode- choice publication AND per-domain DMARC-policy-tier publication as the SAME per-publisher per-domain DNS-zone-editor commit cadence because per-receiver per-day per- publisher per-day per-receiver- source DKIM-aligned-pass-rate floor sustainability IS the precondition for per-publisher per-domain DMARC- policy-tier ramp advancement. Read THIS page when AUTHORING the per- publisher per-selector DKIM canonicalization-mode declaration; read the DMARC-policy-modes spoke when SELECTING the per-publisher per-domain DMARC-policy-tier publication discipline AND understanding the per-publisher per-domain per-selector canonicalization-mode-choice publication IS the load-bearing per-receiver per-day per-publisher per-day DKIM-aligned-pass-rate floor stability primitive every per-publisher per-domain DMARC- policy-tier ramp progression materially depends on.
• DMARC myths and misconceptions — the CANONICALIZATION-INDUCED- MYTH-DEBUNK-COMPANION to this canonicalization-mode reference. Where THIS page documents the per-publisher per-selector per-message DKIM canonicalization-mode-choice mechanics (the per-message header-canonicalization mode simple vs relaxed and the per-message body-canonicalization mode simple vs relaxed declared in the DKIM-Signature c= tag per RFC 6376 §3.4 that determine per-receiver per-message body-hash-vs-signature verification stability under per-relay- hop header-folding / whitespace-collapse / line-ending normalisation), the myths- and-misconceptions spoke is the MISCONCEPTION-CATALOGUE companion documenting FOUR canonicalization- induced myth classes whose per-publisher per-domain DMARC-deployment mental-model REBUTTAL is the PREREQUISITE the per- publisher per-domain operator MUST INTERNALISE before reading the per- receiver per-message DMARC-aligned-fail verdict whose canonicalization-induced per-message DKIM-aligned-fail this page diagnoses: (i) myth 3 — "I have SPF and DKIM so I do not need DMARC" — the per-publisher per- domain operator-side misconception that per-publisher per-selector DKIM-signing- publication-discipline ALONE produces the per-receiver per-message DKIM- aligned-pass verdict the per-receiver per-message DMARC alignment per RFC 7489 §3.1.1 organizational-domain-match materially depends on — when the per- publisher per-selector per-message DKIM- body-hash stability THIS page documents (canonicalization-mode c= choice per RFC 6376 §3.4) is the LOAD- BEARING per-message DKIM-verification primitive whose c=simple/simple misconfiguration produces per-relay-hop per-message body-hash corruption-induced per-message DKIM-aligned-FAIL verdicts the per-publisher per-domain DMARC verdict surfaces as "DMARC is failing for legitimate mail" when the LITERAL protocol root cause is per-publisher per-selector canonicalization-mode choice; (ii) myth 15 — "DMARC failures always mean an attacker" — the per-publisher per-domain operator- side misconception that every per- receiver per-message DMARC-aligned-fail verdict in the per-publisher per-domain RUA aggregate report points at a per- publisher per-domain phishing attacker — when the per-relay-hop per-message body-canonicalization simple- mode whitespace-normalisation non-tolerance THIS page documents emits per-relay-hop per-message body-hash corruption-induced per-message DKIM- aligned-FAIL verdicts that the per- publisher per-domain DMARC verdict surfaces as the LITERAL most common false-positive misattribution class in the per-publisher per-domain RUA stream; (iii) myth 11 — "Deploying DMARC will break my mailing lists" — the per-publisher per-domain operator- side misconception that DMARC enforcement is the proximate cause of forwarded mailing-list message rejection — when the per-mailing-list-forwarder per-relay- hop per-message body-modification (subject prefix injection, footer appending, MIME re-encoding) per-relay- hop body-hash corruption-non-tolerance of c=simple/simple canonicalization THIS page documents is the LITERAL per-relay-hop body- modification surface whose c=relaxed/relaxed mode- choice is the per-message DKIM-aligned- pass survival mechanism the mailing- list forwarder hop produces; and (iv) myth 7 — "Going straight to p=reject is fine if my records look right" — the per-publisher per-domain operator-side misconception that per-publisher per-domain DMARC- record SYNTACTIC-CORRECTNESS ALONE is sufficient to declare per-publisher per- domain enforcement readiness — when the per-publisher per-selector canonicalization-mode publication SEMANTIC-CORRECTNESS THIS page documents (per-relay-hop body-hash-survival observability across the per-publisher per-domain per-relay-hop traffic footprint) is the LOAD-BEARING per- message DKIM-aligned-pass-rate floor sustainability primitive the per- publisher per-domain DMARC-policy-tier ramp advancement materially depends on. Pair this canonicalization reference with the myths-and-misconceptions spoke when explaining the per-publisher per- domain canonicalization-induced per- receiver per-message DMARC-aligned-fail verdict class to a stakeholder who has internalised one or more of the four myth classes above — the myths-page documents the PER-MISCONCEPTION-CLASS REBUTTAL-DISCIPLINE the per-publisher per-domain operator MUST DEPLOY at the stakeholder-conversation boundary, and THIS page documents the PER-SELECTOR PROTOCOL-LEVEL ROOT-CAUSE the per- misconception-class rebuttal-discipline materially attributes against.
• Business email compromise (BEC) defender catalogue — the BEC variant + defender-side enforcement-primitive reference covering CEO-fraud / vendor-impersonation / payroll-redirection / cousin-domain- lookalike / compromised-account-replay / thread-hijack-after-account-takeover attack-pattern catalogue and the per- publisher per-domain SPF + DKIM + DMARC + ARC + MTA-STS + BIMI defender-side enforcement-primitive stack against per- attack-variant impersonation. THIS page documents the per-publisher per-domain DKIM-Signature canonicalization-mode byte- grammar (RFC 6376 §3.4 c=relaxed/ relaxed vs c=simple/simple per-message header-canonicalization + body-canonicalization choice at the per- selector signing-time per-message boundary as the canonical CRYPTOGRAPHIC-INTEGRITY- SCOPE-ANCHOR every per-message DKIM-verify- pass verdict consumes); the BEC-defender- catalogue spoke is the per-attack-variant defender-side enforcement peer documenting how the per-publisher per-domain DKIM canonicalization-mode choice this page documents structurally affects the per- attack-variant BEC-defender-side per- message DKIM-pass evidence stream — (i) per-publisher per-domain c=relaxed/ relaxed canonicalization survives per-receiver-side benign per-MTA whitespace rewrite preserving the per-message DKIM- pass verdict per-attack-variant BEC-defender attribution depends on; (ii) per-publisher per-domain c=simple/simple canonicalization fails on benign per-MTA rewrite producing per-receiver-side per- message DKIM-fail evidence indistinguishable from BEC-attacker-content-manipulation evidence, eroding per-publisher per-domain DKIM-pass-rate as load-bearing BEC-defender- side per-attack-variant indicator-of- compromise; (iii) per-attacker per-message body-manipulation attack-variant (the cryptographic-integrity-attack class the BEC-vendor-impersonation per-thread-hijack variant exploits) FAILS DKIM-verify regardless of canonicalization-mode-choice — the per-publisher per-domain canonicalization-mode choice is per-attack- variant BEC-defender-side IRRELEVANT for cryptographic-integrity-attack defense but is LOAD-BEARING for benign-rewrite-induced DKIM-fail-noise minimization; (iv) per- publisher per-domain l= body- length-limit tag MUST NOT BE PUBLISHED in BEC-defender-side DKIM-signing because the per-message attacker-controlled-body-suffix attack-variant exploits per-publisher per- domain l=-truncated body-hash scope to inject attacker-controlled content per-attack-variant BEC-defenders must catalogue as per-publication mistake. Read the BEC-defender-catalogue spoke alongside this DKIM-canonicalization reference when scoping the per-publisher per-domain BEC-defender-side per-attack- variant DKIM-signing-discipline that structurally minimises benign-rewrite- induced DKIM-fail-noise interfering with the per-publisher per-domain BEC-defender- side per-attack-variant indicator-of- compromise evidence stream.
• DMARC deployment checklist — the PRE-FLIGHT-CHECKLIST-ITEM-DKIM- CANONICALIZATION-MODE-ENGAGED companion to this DKIM canonicalization reference. Where THIS page documents the per-publisher per- signing-MTA-fleet-node DKIM canonicalization- mode choice (RFC 6376 §3.4 `c=simple/simple` vs `c=simple/relaxed` vs `c=relaxed/simple` vs `c=relaxed/relaxed` header-and-body canonicalization mode taxonomy + the per- message body-hash-stability primitive each choice produces), the DMARC-deployment- checklist spoke is the per-publisher per- domain DMARC deployment process-reference whose pre-flight checklist-items the per- publisher per-signing-MTA-fleet canonicalization-mode reference THIS page documents structurally enables. FOUR per- publisher per-domain deployment-checklist- vs-DKIM-canonicalization coupling dimensions: (i) per-publisher per-domain Pre- flight checklist-item: per-publisher per- signing-MTA-fleet `c=relaxed/relaxed` canonicalization-mode engagement verified via test-message DKIM-Signature header `c=` tag inspection as load-bearing per- publisher per-domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per- signing-MTA-fleet `c=relaxed/relaxed` canonicalization-mode pre-flight engagement verification step (per-publisher per- signing-MTA-fleet test-message round-trip through receiver-side DKIM-verifier with DKIM-Signature header `c=` tag inspection confirming `c=relaxed/relaxed`) the per- publisher per-domain DMARC deployment operator MUST execute BEFORE advancing past `p=none` to `p=quarantine`; the per- canonicalization-mode reference THIS page documents is the LITERAL pre-flight verification reference the deployment- checklist operator consults at the per- publisher per-signing-MTA-fleet canonicalization-mode engagement verification step; (ii) per-publisher per-domain Pre- flight checklist-item: per-publisher per- signing-MTA-fleet canonicalization-mode consistency floor across multi-node fleet as load-bearing per-publisher per-domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per-signing-MTA-fleet canonicalization-mode consistency floor verification step (per-publisher per- signing-MTA-fleet multi-node round-trip test confirming EVERY node emits identical `c=relaxed/relaxed` DKIM-Signature headers, no per-node canonicalization-mode drift) the per-publisher per-domain DMARC deployment operator MUST execute; the per- canonicalization-mode reference THIS page documents is the LITERAL per-signing-MTA- fleet canonicalization-mode consistency reference the deployment-checklist operator consults at the per-fleet consistency verification step; (iii) per-publisher per-domain Ramp-phase checklist-item: per-publisher per-receiver `dkim=fail` body-hash-mismatch RUA-row evidence rate floor cross-checked during `p=quarantine pct=10/25/50 → p=reject pct=100` ramp advancement as load-bearing per-publisher per-domain canonicalization- regression-detection gate — the deployment-checklist spoke documents the per-publisher per-domain per-receiver `dkim=fail` body-hash-mismatch RUA-row evidence rate floor the per-publisher per- domain DMARC deployment operator MUST audit DURING per-phase ramp advancement (per-publisher per-domain `dkim=fail` body- hash-mismatch rate above the per-receiver floor indicates per-signing-MTA-fleet canonicalization-mode regression requiring rollback to `c=relaxed/relaxed` before ramp advancement); the per-canonicalization- mode reference THIS page documents is the LITERAL per-signing-MTA-fleet canonicalization-mode regression-diagnosis reference the deployment-checklist operator consults at the per-phase RUA-evidence-rate audit step; (iv) per-publisher per-domain Post-flight checklist-item: per-publisher per-domain per-receiver per-mailing-list- forwarder `dkim=pass + aligned=true` evidence rate cross-checked in the per- receiver aggregate-report RUA stream as load-bearing per-publisher per-domain forwarder-survivability-floor empirical- observability primitive — the deployment-checklist spoke documents the per-publisher per-domain per-receiver per- mailing-list-forwarder `dkim=pass + aligned=true` evidence rate the per- publisher per-domain DMARC deployment operator MUST verify in the per-receiver RUA evidence stream BEFORE advancing to terminal `p=reject pct=100` (per-publisher per-domain `c=relaxed/relaxed` canonicalization-mode is the LOAD-BEARING per-message body-hash-stability primitive producing forwarder-survivable DKIM-pass verdicts at receivers); the per- canonicalization-mode reference THIS page documents is the LITERAL per-message body- hash-stability primitive the per-receiver per-mailing-list-forwarder `dkim=pass + aligned=true` evidence rate empirically observes. Read the DMARC-deployment-checklist spoke alongside this DKIM canonicalization reference when AUTHORING the per-publisher per-domain DMARC deployment pre-flight checklist whose `c=relaxed/relaxed` canonicalization-mode engagement is the load-bearing pre-flight gate, when PLANNING the per-publisher per-domain DMARC ramp- progression calendar with explicit per- signing-MTA-fleet canonicalization-mode consistency-floor checklist items, or when VALIDATING the per-publisher per-domain DMARC terminal-state `p=reject pct=100` ramp-readiness against the post-flight per-receiver per-mailing-list-forwarder `dkim=pass + aligned=true` forwarder- survivability-floor checklist gate.
• DNS propagation timelines — the TTL-bounded publish-and-verify-cycle primitive whose four DNS-propagation-vs- canonicalization-mode-stability coupling dimensions THIS canonicalization reference materially depends on: (i) post- publish propagation tail when the per- publisher per-selector DKIM TXT-record is republished with a new public key co- committed with the c=relaxed/relaxed canonicalization-mode flip — per- receiver per-resolver caches still serve the prior selector's public key until the prior TTL elapses, producing dkim=permerror on cryptographically- legitimate mail signed by the new public key with the new canonicalization mode for the full TTL window the canonicalization-mode-flip publish-and- verify cycle structurally consumes; (ii) dual-selector overlap-window publication discipline gating canonicalization-mode-flip safety — the per-publisher per-selector overlap- window coexistence period MUST exceed the previous selector's published TTL before the prior selector is retired, otherwise post-cutover per-receiver per-message dkim=fail verdicts surface on mail signed by the retired selector that has not yet evicted from per-resolver caches WHILE the new canonicalization mode is already in production; (iii) RFC 2308 negative-cache window magnifying revocation-via-empty- p= canonicalization-mode- rollback latency — if the operator publishes a canonicalization-mode flip that breaks a per-forwarder body-hash- stability invariant and attempts emergency rollback via empty-p= on the affected selector, per-receiver per-resolver negative-cache TTL governs the rollback- propagation-window the operator's incident- response runbook must wait through before per-receiver caches expire the revoked public-key record and resume verifying against the rolled-back canonicalization mode; (iv) CNAME-delegated DKIM publication doubling the TTL-bounded propagation window — when the per- publisher per-selector DKIM TXT-record is delegated via CNAME to an ESP-managed canonical name (the ESP applies its platform-default canonicalization mode on the publisher's behalf), per-receiver verification MUST resolve the CNAME alias chain BEFORE retrieving the TXT record, doubling the TTL-bounded propagation tail the canonicalization-mode publish-and- verify cycle structurally consumes and widening the per-receiver per-message dkim=permerror window during post-publish CNAME-alias TTL convergence. Read the DNS-propagation timelines spoke alongside this DKIM-canonicalization reference when planning a per-publisher per-selector key-rotation cadence that co-commits a canonicalization-mode flip, when authoring the per-publisher per- domain rollback runbook for a canonicalization- mode regression emergency, or when investigating per-receiver per-message dkim=permerror/dkim=fail verdicts that surface DURING the post- publish TTL-bounded propagation tail of a canonicalization-mode-flip publication.
• DMARC for Microsoft 365 — the M365-TENANT-PER-CUSTOM-DOMAIN-DUAL- SELECTOR-DKIM-EGRESS-WITH-RELAXED-RELAXED- CANONICALIZATION companion to this DKIM- canonicalization byte-grammar reference. Where THIS page documents the four DKIM canonicalization mode-pairs (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) per RFC 6376 §3.4 and the per-mode header-and-body byte- rewriting algorithm operator-side decisions (whitespace folding, header-name case-folding, trailing CRLF normalisation, per-mode forwarder-survival robustness), the M365-tenant spoke documents the per- M365-tenant per-custom-domain Exchange Online DKIM signer's canonicalization-mode emission policy (Exchange Online uses c=relaxed/relaxed for both per-tenant selector1 and selector2 CNAME-delegated DKIM-Signature emissions). The per-M365- tenant per-custom-domain dual-selector DKIM-Signature emission IS the per-tenant per-custom-domain canonical consumer of the DKIM canonicalization-mode discipline THIS page architectures at four M365- tenant-DKIM-egress-vs-DKIM-canonicalization- mode-selection coupling dimensions: (i) per-M365-tenant per-custom-domain c=relaxed/relaxed default as Exchange Online forwarder-survival canonical baseline — the per-M365-tenant per-custom-domain Exchange Online DKIM signer's c=relaxed/relaxed canonicalization-mode selection IS the per- tenant per-custom-domain forwarder- survival canonical baseline that defends the per-M365-tenant per-custom-domain DKIM-aligned-pass-rate floor through mailing-list / forwarder hops; (ii) per- M365-tenant per-custom-domain dual- selector selector1 + selector2 emission as zero-downtime DKIM-key-rotation cadence — the per-M365-tenant per-custom-domain dual-selector DKIM emission topology consumes the per-selector-pair overlap- window canonicalization-stability discipline THIS page documents at the per-tenant per-custom-domain DKIM-key- rotation boundary; (iii) per-M365-tenant per-custom-domain relaxed/relaxed canonical- header-byte-rewriting as Exchange Online per-message Subject/From/To/Date/ Message-ID + List-Unsubscribe header- canonicalization discipline — the per- M365-tenant per-custom-domain Exchange Online egress's per-message header-list canonicalization-mode-rewriting algorithm THIS page documents IS the per-tenant per- custom-domain canonical per-message header-byte-grammar emission rewriting discipline; and (iv) per-M365-tenant per- custom-domain ARC-rescue ARC-signature canonicalization-mode-consistency discipline — the per-M365-tenant per- custom-domain Exchange Online ARC- canonical signer emits ARC-Signature headers with the SAME c=relaxed/relaxed canonicalization mode-pair as the per- tenant DKIM signer, the canonicalization- mode-consistency discipline THIS page documents enables across the per-M365- tenant per-custom-domain DKIM + ARC cross-protocol signature-emission boundary. Read THIS page when AUTHORING the per-publisher per-domain DKIM canonicalization-mode selection at the canonical signer-side reference layer; read the M365-tenant DMARC deployment spoke when AUDITING the per-M365-tenant per-custom-domain DKIM-Signature canonicalization-mode-consistency against the per-M365-tenant per-custom-domain Exchange Online DKIM-signer-egress contract at the per-M365-tenant per- custom-domain DKIM emission boundary.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the per-receiver per-publisher per-day RFC 8460 §4 TLS-RPT JSON-aggregate-report byte-grammar reference companion to this DKIM canonicalization byte-grammar reference. Where THIS page documents the application-layer per-message RFC 6376 §3.4 DKIM canonicalization four-algorithm- pair (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) byte- rewriting discipline whose c=relaxed/relaxed emission baseline IS the per-publisher per-domain DKIM-aligned-pass-rate forwarder-survival primitive, the TLS-RPT report-format spoke documents the structurally parallel transport-layer per-receiver per-day per- domain JSON-aggregate-report byte-grammar whose result-type enum (starttls-not- supported, certificate-host-mismatch, certificate-expired, certificate-not- trusted, validation-failure, sts-policy- fetch-error) IS the per-publisher per- domain transport-layer STARTTLS-handshake- survival observability primitive. Four per-protocol-layer byte-grammar-vs- observability-feed coupling dimensions matter at the per-publisher per-domain composite authentication-and-transport- layer discipline boundary: (i) per-message application-layer DKIM-Signature byte- integrity across the per-hop STARTTLS leg — DKIM cryptographic-binding SURVIVES cleartext-fallback transport (the signature remains valid on a TLS- downgraded hop) but loses transport-layer confidentiality the TLS-RPT report-format spoke surfaces as STARTTLS-not-supported failure-events; (ii) per-publisher per- domain dual-publication discipline at the DNS TXT-RR layer — DKIM v=DKIM1 per-selector TXT-RR publication coexists with TLS-RPT v=TLSRPTv1 per-domain _smtp._tls TXT-RR publication at the per-publisher per-domain shared DNS-publication-cadence boundary; (iii) per-receiver per-day evidence-feed complementarity — per-publisher per-domain DMARC RUA aggregate reports feed back the per-message DKIM-canonicalization-verdict evidence stream THIS page documents diagnostic procedure for, and TLS-RPT per-publisher per-domain JSON aggregate reports feed back the per-day STARTTLS- handshake-failure evidence stream the report-format spoke documents byte- grammar for, with both feeds composing the per-publisher per-domain composite authentication-and-transport-layer observability discipline; (iv) per- publisher per-domain RFC-grammar-floor coordination — the per-message DKIM- Signature canonicalization-mode emission contract per RFC 6376 §3.4 THIS page documents IS structurally parallel to the per-publisher per-day TLS-RPT JSON- aggregate-report-emission contract per RFC 8460 §4 the report-format spoke documents, both as load-bearing per- publisher per-domain byte-grammar-floor publication-discipline references the per- publisher per-domain composite authentication-and-transport-layer publication discipline depends on. Read THIS page when AUTHORING the per-publisher per-domain DKIM canonicalization-mode selection at the per-message application- layer byte-grammar reference; read the TLS-RPT report-format spoke when EVALUATING the per-publisher per-day per-receiver STARTTLS-handshake-failure evidence stream that surfaces transport- layer egress fragility the per-publisher per-domain DKIM-canonicalization- independent transport-layer observability discipline depends on for per-publisher per-domain composite authentication-and- transport-layer observability coordination floor.
• DANE explained — the per-publisher per-MX DANE TLSA transport-layer cryptographic- binding companion at four cross-layer cryptographic-discipline coupling dimensions.
• SPF qualifiers explained
• DMARC aggregate (RUA) reports
• DMARC for cPanel hosting — the PER-CPANEL-TENANT-PER-CUSTOM-DOMAIN-DKIM-SIGNATURE-CANONICALIZATION-MODE-PUBLICATION-DECISION-AS-LOAD-BEARING-PER-TENANT-PER-CUSTOM-DOMAIN-PER-MESSAGE-DKIM-VERDICT-STABILITY-DRIVER-AT-SHARED-EXIM-MTA-EGRESS companion at four DKIM-canonicalization-mode-vs-cPanel-shared-hosting-DMARC-deployment coupling dimensions: (1) per-cPanel-tenant per-custom-domain DKIM-Signature c= canonicalization-mode publication-decision per RFC 6376 §3.4 drives per-tenant per-custom-domain per-message DKIM-verdict stability under per-forwarder-class envelope-rewriting cascade at shared-Exim-MTA cluster egress — per-cPanel-tenant per-custom-domain DKIM-Signature c=relaxed/relaxed canonicalization-mode tolerates per-forwarder-class whitespace-and-header-folding mutation surface that shared-MX-cluster intermediate-relay rewrite-pipelines apply to per-tenant per-message body-and-header normalization; (2) per-cPanel-tenant per-custom-domain DKIM-Signature c=simple/simple canonicalization-mode publication-decision IS the strictest per-tenant per-message authentication-leg verdict-stability ceiling whose per-receiver per-day DMARC RUA aggregate-report policy_evaluated/dkim=fail attribution surfaces in per-cPanel-tenant per-custom-domain operator-actionable evidence-stream the per-cPanel hosting page documents per-tenant per-custom-domain SPF + DKIM + DMARC publication discipline of; (3) per-cPanel-tenant per-custom-domain DKIM-Signature canonicalization-mode publication-decision drives per-tenant per-custom-domain DKIM-aligned-pass-rate floor stability against per-forwarder-induced verdict-collapse at shared-IP-pool egress — per-cPanel-tenant per-custom-domain DMARC composite-aligned-pass-rate floor preservation across shared-MX-cluster cross-tenant verdict-noise REQUIRES per-tenant per-custom-domain canonicalization-mode-publication-discipline as the per-tenant identity-attribution leg-stability primitive; (4) per-cPanel-tenant per-custom-domain DKIM-Signature canonicalization-mode publication-decision IS structurally upstream cause whose per-receiver per-day DMARC RUA aggregate-report per-row policy_evaluated/dkim attribution stream IS the per-cPanel-tenant per-custom-domain operator-actionable per-day per-source-IP per-receiver downstream-impact-attribution evidence-stream gating per-cPanel-tenant per-custom-domain DKIM-aligned-pass-rate floor ramp-readiness decision feeding per-cPanel-tenant per-custom-domain DMARC p=none → p=quarantine → p=reject enforcement-mode-publication-discipline coordination THIS DKIM-canonicalization-mode-vocabulary page documents the per-publisher per-selector application-layer publication-discipline of structurally cascades into the per-cPanel hosting page’s per-tenant per-custom-domain shared-hosting-deployment composite envelope-and-application-layer publication-discipline coordination boundary.
• DMARC monitoring
• TLS-RPT explained — the per-publisher per-domain transport-layer aggregate-observability primer companion at four per-publisher per-selector DKIM-canonicalization-mode-vs-TLS-RPT-transport-layer-observability coupling dimensions: (i) per-publisher per-selector DKIM-Signature c=simple/simple vs c=relaxed/relaxed canonicalization-mode byte-normalization per RFC 6376 §3.4 THIS page documents the per-publisher per-selector application-layer byte-normalization-discipline of IS structurally parallel application-layer per-message byte-grammar-preservation primitive to per-publisher per-domain MTA-STS-enforce per-message STARTTLS-handshake transport-integrity byte-preservation per RFC 8461 §5 whose per-message transport-integrity-degradation failure surfaces in per-publisher per-policy-domain TLS-RPT JSON-aggregate-report failure-details per-event-type attribution per RFC 8460 §4.3 — both per-publisher per-domain byte-preservation-discipline references coordinate at the per-publisher per-domain composite application-and-transport-layer per-message byte-preservation coordination boundary; (ii) per-publisher per-selector DKIM canonicalization-mode publication-discipline drives per-receiver per-day DMARC RUA aggregate-XML policy_evaluated/dkim + auth_results/dkim attribution-row evidence stream IS structurally parallel application-layer aggregate-observability primitive to per-publisher per-policy-domain TLS-RPT JSON-aggregate-report policy + summary + failure-details per-day per-MX-host evidence-row attribution stream — both per-publisher per-domain per-leg evidence-row streams coordinate at the per-publisher per-domain composite application-and-transport-layer aggregate-observability coordination boundary; (iii) per-publisher per-selector DKIM c=relaxed/relaxed canonicalization-mode-publication-decision preserves per-receiver per-message DKIM-aligned-pass under per-forwarder-class whitespace-and-header-folding mutation cascade IS structurally parallel per-forwarder-survival primitive to per-publisher per-domain MTA-STS-enforce transport-layer STARTTLS-handshake survival under per-forwarder-class MITM-downgrade attack-class cascade surfacing in per-publisher per-policy-domain TLS-RPT failure-type: starttls-not-supported attribution per RFC 8460 §4.3; (iv) per-publisher per-selector DKIM canonicalization-mode-publication-discipline drift surfaces in per-receiver per-day DMARC RUA per-source-IP per-day per-leg-verdict drift-evidence stream IS structurally parallel publication-discipline-drift class to per-publisher per-domain MTA-STS publication-discipline drift surfacing in per-publisher per-policy-domain TLS-RPT sts-policy-fetch-error/sts-policy-invalid attribution + DANE publication-discipline drift surfacing in dane-mismatch/dnssec-invalid attribution — both per-publisher per-domain per-leg drift-evidence streams coordinate at the per-publisher per-domain composite application-and-transport-layer per-leg drift-evidence stream coordination boundary the per-publisher per-domain TLS-RPT transport-layer aggregate-observability primer THIS spoke documents the per-publisher per-domain transport-layer per-failure-class catalogue of structurally surfaces.
• MTA-STS policy file syntax — the PER-PUBLISHER-PER-POLICY-DOMAIN-MTA-STS-POLICY-FILE-BYTE-GRAMMAR-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-BYTE-GRAMMAR-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-CANONICALIZATION-MODE-APPLICATION-LAYER-BYTE-NORMALIZATION-PUBLICATION-DECISION companion at four per-publisher per-domain MTA-STS-policy-file-byte-grammar-vs-DKIM-canonicalization-byte-normalization coupling dimensions: (i) per-publisher per-policy-domain MTA-STS policy-file byte-grammar publication-discipline per RFC 8461 §3.2 (version: STSv1 mandatory-prefix + mode:/mx:/max_age: tag-vocabulary + no-BOM + no-comment rules) IS structurally parallel transport-layer byte-grammar publication-discipline to per-publisher per-selector DKIM c=relaxed/relaxed vs c=simple/simple canonicalization-mode publication-decision per RFC 6376 §3.4 (relaxed-header lower-case + unfold-WSP + collapse-WSP + strip-trailing-WSP; simple-header byte-preserving) — both per-publisher per-domain byte-grammar publication-discipline references are per-publisher per-domain operator-side byte-stream-production primitives the per-receiver-side per-message cryptographic-and-transport-policy verification consumes; (ii) per-publisher per-policy-domain MTA-STS policy-file mode: enforce transport-layer enforcement-mode publication-decision per RFC 8461 §5 IS the load-bearing per-receiver per-MX-host STARTTLS-required-or-fail enforcement-floor preserving per-message envelope-byte-stream-integrity baseline against active MITM downgrade-attack-class — per-publisher per-selector DKIM canonicalization-produced bh= body-hash byte-stream integrity per RFC 6376 §3.4 THIS page documents the per-publisher per-selector application-layer byte-normalization-discipline of materially depends on per-receiver-side per-message body-bytes arriving unmodified through transit which the per-publisher per-policy-domain MTA-STS-enforced transport-layer policy-file publication-discipline structurally underpins; (iii) per-publisher per-policy-domain MTA-STS policy-file max_age: cache-lifetime publication-decision per RFC 8461 §3.2 IS the load-bearing per-publisher per-policy-domain operator-side policy-cache-stability publication-discipline whose per-receiver-side policy-cache-coherence cadence IS structurally parallel to per-publisher per-selector DKIM canonicalization-mode publication-stability cadence — both per-publisher per-domain publication-cadence references are per-publisher per-domain operator-side per-day per-receiver verdict-stability publication-discipline primitives; (iv) per-publisher per-policy-domain MTA-STS policy-file byte-grammar publication-discipline drift (BOM-prefix mis-publication / inline-comment mis-publication / wildcard-label crossing single-label-budget / max_age: exceeding 31557600-second ceiling / Content-Type mis-publication) directly opens per-publisher per-policy-domain TLS-RPT JSON-aggregate-report failure-type: sts-policy-invalid attribution per RFC 8460 §4.3 IS structurally parallel publication-discipline-drift class to per-publisher per-selector DKIM canonicalization-mode publication-discipline drift (premature c=simple/simple publication-decision under MIME re-encoding / transfer-encoding-change middleware surfacing as per-receiver per-day DMARC RUA aggregate-report policy_evaluated/dkim=fail attribution per RFC 7489 §6.6.1) — both per-publisher per-domain per-day per-receiver per-leg aggregate-evidence-channel byte-grammar-publication-discipline-drift references jointly underpin per-publisher per-domain operator-actionable per-day per-leg drift-closure observability at the per-publisher per-domain composite cross-protocol cross-layer per-day per-receiver byte-grammar-publication-discipline coordination boundary.
• DMARC for shared-hosting — the PER-SHARED-HOSTING-TENANT-PER-CUSTOM-DOMAIN-DKIM-SIGNATURE-CANONICALIZATION-MODE-PUBLICATION-DECISION-AS-LOAD-BEARING-PER-TENANT-PER-MESSAGE-DKIM-VERDICT-STABILITY-DRIVER-AT-SHARED-MX-CLUSTER-EGRESS companion at four DKIM-canonicalization-mode-vs-shared-hosting-DMARC-deployment coupling dimensions: (i) per-shared-hosting-tenant per-custom-domain DKIM-Signature c=relaxed/relaxed canonicalization-mode publication-decision per RFC 6376 §3.4 tolerates per-forwarder-class whitespace-and-header-folding mutation that shared-MX-cluster intermediate-relay rewrite-pipelines apply to per-tenant per-message body-and-header normalization across the shared-IP-pool egress IS the load-bearing per-tenant per-custom-domain DKIM-verdict-stability discipline whose per-receiver per-message dkim=pass verdict-rate floor preservation the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of structurally depends on; (ii) per-shared-hosting-tenant per-custom-domain DKIM-Signature c=simple/simple canonicalization-mode publication-decision IS the strictest per-tenant per-message authentication-leg verdict-stability ceiling whose per-receiver per-day DMARC RUA aggregate-report policy_evaluated/dkim=fail attribution per RFC 7489 §6.6.1 surfaces in per-shared-hosting-tenant per-custom-domain operator-actionable evidence-stream the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC publication discipline of as the per-tenant operationally-untenable canonicalization-mode-publication-decision under shared-MX-cluster intermediate-relay rewrite-pipeline cascade; (iii) per-shared-hosting-tenant per-custom-domain DKIM-Signature canonicalization-mode publication-decision drives per-tenant per-custom-domain DKIM-aligned-pass-rate floor stability against per-forwarder-induced verdict-collapse at shared-IP-pool egress — per-shared-hosting-tenant per-custom-domain DMARC composite-aligned-pass-rate floor preservation across shared-MX-cluster cross-tenant verdict-noise REQUIRES per-tenant per-custom-domain canonicalization-mode-publication-discipline as the per-tenant identity-attribution leg-stability primitive the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain ramp-readiness publication-discipline of structurally depends on; (iv) per-shared-hosting-tenant per-custom-domain DKIM-Signature canonicalization-mode publication-decision IS structurally upstream cause whose per-receiver per-day DMARC RUA aggregate-report per-row policy_evaluated/dkim attribution stream IS the per-shared-hosting-tenant per-custom-domain operator-actionable per-day per-source-IP per-receiver downstream-impact-attribution evidence-stream gating per-shared-hosting-tenant per-custom-domain DKIM-aligned-pass-rate floor ramp-readiness decision feeding per-shared-hosting-tenant per-custom-domain DMARC p=none → p=quarantine → p=reject enforcement-mode-publication-discipline coordination THIS DKIM-canonicalization-mode-vocabulary page documents the per-publisher per-selector application-layer publication-discipline of structurally cascades into the shared-hosting DMARC-deployment page's per-tenant per-custom-domain shared-MX-cluster-deployment composite envelope-and-application-layer publication-discipline coordination boundary.
• BIMI logo SVG requirements — the canonicalization-mode choice this page documents is upstream of BIMI display. A BIMI logo only paints once the domain holds DMARC enforcement (p=quarantine/p=reject) with a sustained aligned-pass, and c=relaxed/relaxed is what keeps the DKIM-Signature surviving forwarder whitespace-and-header-folding rewrites so the DKIM-aligned-pass leg stays stable enough to hold that enforcement. Make the logo asset itself conformant to the SVG Tiny PS constraints there, but the canonicalization discipline here is the precondition that lets it ever render in the inbox.
• 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.

13. Verify your DKIM canonicalization now

The fastest way to confirm your outbound DKIM is emitting c=relaxed/relaxed and the signature is verifying end-to-end:

1. Send a test message to a mailbox you control (a personal Gmail account, a seed-list address, the DMARC Analyzer mailbox you ingest reports through).
2. Capture the raw source — Gmail three-dot menu > Show original > Download Original; Outlook File > Properties > Internet headers; Apple Mail View > Message > Raw Source.
3. Paste the headers into the Email Header Analyzer. The DKIM-Signature panel shows every tag, including the c= value.
4. Verify the Domain Security Checker confirms your DKIM selector publishes a valid public key.