DMARC Analyzer

TL;DR

• First step: open the failing message in the Email Header Analyzer and read the Authentication-Results header. Modern receivers annotate every dkim= verdict with a reason="..." phrase — that phrase narrows the symptom to one of the eight branches below.
• Most-common verdicts in practice: dkim=fail with body-hash mismatch (forwarder, mailing list, or content-scanning gateway rewrote the body) — about 80% of all dkim=fail traffic. dkim=pass with DMARC still failing (the M365 onmicrosoft.com and Workspace gappssmtp.com alignment gotchas) — the most-overlooked misconfiguration class.
• dkim=pass does NOT mean DMARC passes. The cryptography succeeded; ALIGNMENT may still have failed. DMARC compares d= in the DKIM-Signature header to the From: header domain per RFC 7489 §3.1.1 — full algorithm in help_dkim_alignment_with_dmarc.php.
• dkim=temperror is transient; receivers MAY retry. Small percentage = normal background. Sustained large percentage = your authoritative name servers are unreachable, rate-limited, or your TXT record is truncated at the UDP boundary.
• dkim=permerror is structural: the selector TXT does not resolve, the TXT is malformed (missing v=DKIM1, truncated p=), or the DKIM-Signature header itself is broken (missing required tag, invalid base64).
• dkim=policy means too weak: most commonly rsa-sha1 (deprecated by RFC 8301) or a 1024-bit RSA key (some receivers refuse anything under 2048 bits).
• Cryptography fails ≠ configuration fails. A dkim=fail caused by a forwarder is NOT a configuration bug at your end — your only realistic options are SPF alignment via SRS, an ARC seal across the forwarding boundary, or accepting the per-flow failure when DMARC alignment can still pass via SPF. The verdict catalogue distinguishes operator- actionable from third-party-induced failures.
• Tools you need: the Email Header Analyzer (parse a failing Authentication-Results), the Domain Security Checker (verify the selector TXT publishes correctly), and the DMARC Analyzer dashboard (drill down on the per-source-IP failure pattern).

How to use this page

DKIM (RFC 6376) failures present as one of eight verdict strings in the Authentication-Results header per RFC 8601 §2.7.1: dkim=none, dkim=neutral, dkim=pass, dkim=fail, dkim=policy, dkim=temperror, dkim=permerror, and the rarely-emitted dkim=softfail (which most receivers fold into dkim=fail for DMARC purposes). When the DMARC Analyzer dashboard surfaces a dkim=fail row in an aggregate report, the operator's first job is to map the verdict back to one of these symptoms — at which point the cause and the remediation become deterministic.

This page is the symptom-first decision tree. Pick the verdict you saw, follow the branch, and the next-step is at the bottom of each section. The companion pages serve different purposes:

• help_dkim_failures_explained.php — verdict catalogue (what each verdict STRING means in normative terms per RFC 6376 §3.9 and RFC 8601 §2.7.1).
• help_dkim_signatures_explained.php — tag anatomy (what each tag in the DKIM-Signature header carries: v= a= c= d= s= h= bh= b= i= q= l= t= x= z=).
• help_dkim_alignment_with_dmarc.php — DMARC alignment algorithm from the DKIM angle (the d=-tag-as-alignment-anchor rule, adkim=r vs adkim=s, organizational-domain matching).
• help_dkim_explained.php — protocol primer (the high-level signing and verification pipeline).
• THIS page — symptom → cause → next-step decision tree.

If you have a specific failing message in hand, start at the Decision tree. If you have an aggregate-report row showing repeated failures from one source, start at the matching symptom section directly. If you are not yet sure which verdict you are troubleshooting, paste the Authentication-Results header into the Email Header Analyzer and the parsed output will name the verdict.

Decision tree

The verdict in the Authentication-Results header determines the branch. The reason="..." annotation (when present) narrows further. Receivers like Google and Microsoft emit this annotation aggressively; smaller receivers may omit it, in which case the Received-DKIM: header (if the receiver added one) or the Authentication-Results-Original: header carries the diagnostic detail.

Authentication-Results header
       │
       ├─► dkim=none           ───► Section "dkim=none"            (signer missing)
       │
       ├─► dkim=neutral        ───► Section "dkim=neutral"         (structural anomaly)
       │
       ├─► dkim=pass + DMARC=fail ► Section "dkim=pass + DMARC fail" (alignment gotcha)
       │
       ├─► dkim=fail           ───┬─► reason=body hash ────► Section "fail (body-hash)"
       │                          ├─► reason=signature ────► Section "fail (signature)"
       │                          └─► (no reason given) ───► Inspect both branches
       │
       ├─► dkim=temperror      ───► Section "dkim=temperror"       (DNS transient)
       │
       ├─► dkim=permerror      ───► Section "dkim=permerror"       (record / header malformed)
       │
       └─► dkim=policy         ───► Section "dkim=policy"          (algorithm too weak)

The eight branches below cover every operator- encountered verdict. After diagnosing your specific message, check the multi-signature scenarios section if more than one DKIM-Signature was present, then the provider-specific quick references if the failing source is a cloud sender, and finally the operator decision matrix for the at-a-glance cause-to-fix summary.

Symptom: dkim=none

What it means: the message had no DKIM-Signature header at all. The verifier did not even attempt cryptography; there was nothing to verify.

Likely causes

• The sender does not sign — plain SMTP traffic from a non-DKIM-deploying sender. This is expected for any From: domain that has not configured DKIM. For DMARC to pass via DKIM the sender must sign; otherwise DMARC alignment must come from SPF.
• The signing step in your outbound path failed silently. The signer (mail server, ESP, gateway) processed the message without emitting a DKIM-Signature header. Common causes: private key missing on the signer host, signer service down, signer configured for a different domain than the From: header carries, signer bypassed by an outbound relay that intercepted before the signing hop.
• The signing happened but a downstream hop stripped the signature. Some legacy gateways (notably old Exchange Edge Transport configurations) actively remove DKIM-Signature headers they did not generate themselves. See help_dmarc_for_office_365_hybrid.php for the Hybrid Exchange Default Frontend Connector DKIM-strip pitfall.
• The signing happened but on a sub-domain that does not match the From:. The signer used a well-formed but UNRELATED d= (a third-party platform's signing domain). The dkim=none here is more accurately a no-aligned-signature outcome — receivers may emit dkim=none, dkim=fail, or omit the entry entirely depending on implementation.

Next steps

1. Confirm your domain is supposed to be signing. If the From: header is example.com and you have not deployed DKIM at example.com, dkim=none is the expected verdict — deploy DKIM via help_dkim_explained.php for the protocol primer and help_dkim_for_microsoft_365.php or help_dkim_for_google_workspace.php for the cloud-specific recipe.
2. If DKIM IS deployed, inspect your outbound path. Send a test message to a known verifier (e.g., a Gmail mailbox you own) and inspect the received message: does it carry a DKIM-Signature header? If yes, the signer works — investigate the specific path that produced dkim=none in the aggregate report. If no, the signer itself is broken.
3. Check the DMARC aggregate report for the source IP that produced the dkim=none — the source-IP row tells you which outbound path is unsigned. Drill down in the DMARC Analyzer dashboard at source_ip_detail.php for the per-IP failure profile.

Symptom: dkim=neutral

What it means: the verifier found a signature and was able to fetch the public-key TXT, but the structural shape of the signature is something the verifier cannot classify as a clean pass or fail. The verifier is explicitly declining to render a verdict. Per RFC 6376 §3.9 this is the catch-all bucket for structural anomalies that are not strictly malformed (which would be permerror) and not transient (which would be temperror).

Likely causes

• An unrecognized but tolerable tag in the DKIM-Signature header — a forward-compatibility scenario where a future extension added a tag the current verifier does not understand.
• An experimental or rare algorithm in a=. Anything outside rsa-sha256 (RFC 6376 §3.3.1) and ed25519-sha256 (RFC 8463) may produce dkim=neutral at receivers that recognize the algorithm string but have not implemented it.
• A policy-required header missing from h= at a receiver with a local policy mandating that header be signed. Some receivers will degrade to dkim=neutral (rather than dkim=policy) when the gap is structural rather than algorithmic.
• Multiple DKIM-Signature headers where one is well-formed and one is malformed — a non-deterministic verifier might emit dkim=neutral as the compromise verdict. RFC 6376 §3.9 leaves this case implementation-defined.

Next steps

1. Open the failing message in the Email Header Analyzer. The parsed DKIM-Signature will surface any unrecognized tag or algorithm — that is almost always the cause.
2. If the cause is an unusual algorithm in a=, switch your signer to a=rsa-sha256 (the universally supported modern default per RFC 8301). Ed25519 (a=ed25519-sha256) from RFC 8463 is the only other widely-supported choice.
3. If the cause is a policy-required header, review your signer's h= configuration — modern signers should cover From, Subject, Date, To, Message-ID, Reply-To, Sender, MIME-Version at minimum (RFC 6376 Appendix C reference set). The tag anatomy guide documents the canonical signed-header set.

Symptom: dkim=pass but DMARC still fails

What it means: the cryptographic verification succeeded — the body hash matched, the signature verified, the verifier is confident the message was signed by whoever published the key at s= under d=. But DMARC requires more than cryptography: DMARC requires ALIGNMENT between the signing domain d= and the From: header per RFC 7489 §3.1.1. Cryptography passed; alignment failed.

Likely causes (the two big ones)

• Microsoft 365 tenant-default signing. M365 signs all outbound mail with d=tenantname.onmicrosoft.com unless a custom-domain DKIM key is explicitly enabled. The From: header carries the custom domain (user@example.com), but the DKIM-Signature carries d=tenantname.onmicrosoft.com. onmicrosoft.com is on the Public Suffix List, so relaxed alignment also fails. Fix per help_dkim_for_microsoft_365.php: enable custom-domain DKIM via Defender for Office 365, publish the two selector CNAMEs, and the signer switches to d=example.com.
• Google Workspace gappssmtp.com signing. Workspace signs all outbound mail with d=tenantname.gappssmtp.com unless a custom-domain DKIM key is explicitly enabled. gappssmtp.com is on the Public Suffix List, so relaxed alignment also fails. Fix per help_dkim_for_google_workspace.php: generate a custom DKIM key in the Admin Console, publish the TXT record, and start authentication.
• SaaS marketing platform without custom-domain DKIM. SaaS senders (Mailchimp, SendGrid, Mailgun, HubSpot, Klaviyo) sign with their own platform domain by default. Until you configure your custom-domain DKIM on the platform (a per-vendor recipe), every message they send appears as dkim=pass-but-DMARC-fail for messages with your From: domain.
• Subdomain mismatch with adkim=s. If you set adkim=s (strict) in your DMARC record, the d= tag must be byte-identical to the From: domain. A signer using a subdomain (e.g., d=marketing.example.com with From: user@example.com) will fail strict alignment even though relaxed alignment would have passed. Switch to adkim=r (relaxed, the default) unless you have a specific reason for strict.

Next steps

1. Inspect the failing message in the Email Header Analyzer. Read the d= tag in the DKIM-Signature header. Compare to the From: header domain. If they differ (different org domains per PSL), you have the alignment gotcha.
2. Identify the signer from the d= value. Is it your M365 tenant (onmicrosoft.com), your Workspace tenant (gappssmtp.com), or a SaaS platform domain? The fix is platform- specific.
3. For full alignment-algorithm coverage including subdomain semantics, the PSL organizational-domain matching algorithm, and the multiple-signature "any aligns wins" rule, see help_dkim_alignment_with_dmarc.php.

Symptom: dkim=fail (body-hash mismatch)

What it means: the cryptographic body hash computed by the verifier does not equal the bh= value in the DKIM-Signature header. The body was modified between signing and verification. The reason="body hash did not verify" annotation makes this verdict unambiguous at Google and Microsoft receivers.

This is the single most common dkim=fail in practice — about 80% of dkim=fail traffic.

Likely causes

• Forwarder rewrote the body. A user mailbox that forwards to another address inherits the body but may strip attachments, normalize whitespace, or inject a forwarding annotation. Once the body changes a single byte, the body hash differs and dkim=fail follows. See help_spf_forwarding_issues.php for the same problem viewed through the SPF lens.
• Mailing list rewrote the body. Mailman, Listserv, Discourse, and Google Groups inject a footer ("To unsubscribe...") and often a Subject prefix. The footer changes the body; dkim=fail follows. ARC-sealing at the list boundary (RFC 8617) is the modern fix.
• Content-scanning gateway rewrote the body. Anti-spam / anti-phishing gateways frequently insert a "[EXTERNAL]" banner, a warning footer, or a tracking pixel. Each insertion modifies the body.
• SaaS platform rewrote URLs. Click-tracking systems rewrite every link in the body to a per-recipient redirect URL. If the rewriting happens AFTER signing, the body hash fails.
• MIME re-encoding by an intermediary. A gateway that canonicalizes content-transfer-encoding (e.g., switching base64 to quoted-printable or vice-versa) changes the body's byte-level representation even when the rendered content is unchanged.
• Trailing CRLF normalization. RFC 6376 §3.4.4 relaxed body canonicalization ignores empty lines at the end of the body — most signers and verifiers use relaxed. With simple body canonicalization (c=*/simple), an intermediary's whitespace edit at the body tail breaks the hash.

Next steps

1. Open the failing message in the Email Header Analyzer. Read the Received: header chain bottom-to-top. The signer is the last hop before the first non-aligned line in the chain. Any intermediary that appears between the signer and the verifier is a candidate body-rewriter.
2. If the failing source is a mailing list or known forwarder, accept the per-flow failure and rely on the SPF path: configure SRS rewriting on the forwarder so SPF aligns, or get the list operator to apply ARC sealing (RFC 8617) so DMARC trusts the original DKIM result.
3. If the failing source is your own outbound gateway (content scanning, tracking-link rewriting), reorder the pipeline so signing happens AFTER all content transformations — or switch the body canonicalization to c=relaxed/relaxed (the modern default, more forgiving of whitespace edits). See help_dkim_canonicalization.php for the full canonicalization trade-off.
4. If the failing source is a SaaS platform you control, check the platform's "DKIM signing of redirected links" support setting — most modern platforms (Mailgun, SendGrid) sign AFTER URL rewriting precisely to avoid this failure.

Symptom: dkim=fail (signature mismatch)

What it means: the body hash matched (bh= verified correctly), but the cryptographic signature over the signed-header set did not verify against the public key. Either the signed-header set changed since signing, or the wrong public key was used. The reason="signature did not verify" annotation makes this verdict unambiguous.

Likely causes

• A header named in h= was modified after signing. The most common culprit is a Subject prefix added by an anti-spoof gateway ("[External]", "*** SPAM ***", "[CAUTION]") or list-prefix injection ("[announce-list] ...").
• A signed header was re-ordered or de-duplicated by an intermediary. Some MTAs rewrite the order of headers or collapse duplicates. With simple header canonicalization (c=simple/*), this breaks the signature.
• The verifier fetched the wrong public key. The s= selector resolves to a TXT record but the key in DNS no longer matches the key used at signing time — typically a rotation gone wrong (see the provider- specific section) or a misconfigured selector publishing an old test key.
• The signer emitted an invalid signature. Rare but seen: a signing host with a corrupt private key, a signing library bug, or a clock-skewed signer using a signature scheme that includes time-dependent randomness.

Next steps

1. Inspect the Authentication-Results and the full headers in the Email Header Analyzer. Look for a Subject prefix that was clearly added by an intermediary (the original Subject line is recoverable from the z= tag if the signer emitted it).
2. If the cause is a Subject-prefix rewrite, remove Subject from h= (NOT recommended — Subject is a critical identity-bearing header) OR talk to the rewriting gateway operator about disabling the prefix injection for legitimate authenticated mail. Many enterprise security suites offer a "do not rewrite if DKIM signed" mode.
3. If the cause is a key-rotation regression, republish the previous selector record (most providers retain it for 30 days exactly for rollback) and validate caches via dig @resolver selector._domainkey.example.com TXT from multiple geographic resolvers before re-rotating with a longer overlap window.

Symptom: dkim=temperror

What it means: the verifier could not retrieve the public- key TXT at verification time but classifies the failure as transient. Per RFC 6376 §6.1.2 the receiver MAY retry — the verdict is not a permanent failure. In practice receivers do retry a small number of times before falling back to dkim=fail or dkim=permerror.

Likely causes

• Transient DNS failure on the verifier's recursive resolver — packet loss, upstream rate-limiting, or an authoritative name server briefly unreachable.
• UDP truncation without EDNS0 fallback. 2048-bit RSA public-key TXTs are large enough that the DNS response exceeds the legacy 512-byte UDP limit. Modern resolvers and authoritative servers negotiate EDNS0 to accept larger responses (per RFC 6891), but a misconfigured firewall or NAT can strip EDNS0, leaving the verifier with a truncated response.
• Sustained authoritative name-server overload — your DNS provider is rate-limiting queries from the verifier's resolver subnet, or your DNS infrastructure is genuinely overwhelmed (a small DNS provider getting hit by query-volume from a large cloud receiver's IP block).
• RFC 1035 §3.3.14 TXT chunking violated. A single-string TXT must be at most 255 bytes; longer payloads must be split into multiple consecutive 255-byte strings. A signer-provided record that exceeds 255 bytes as a single string is malformed at the DNS layer and many resolvers refuse to return it.

Next steps

1. Quantify the percentage. dkim=temperror on under 1% of traffic is normal internet background noise — ignore. dkim=temperror on a sustained large percentage is a real problem.
2. Run dig @8.8.8.8 selector._domainkey.example.com TXT from multiple resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9). Confirm consistent successful resolution with a sane response payload.
3. Validate the TXT record size and chunking with dig +short selector._domainkey.example.com TXT | wc -c. If the payload is large (over ~300 bytes), confirm it is split into multiple quoted strings (each at most 255 bytes long).
4. If the failing receiver is one specific cloud (e.g., always Microsoft, never Google), the issue may be that receiver's resolver infrastructure rate-limiting your authoritative servers — contact your DNS provider about scaling the authoritative tier.

Symptom: dkim=permerror

What it means: the verifier classified the failure as permanent — retrying would not help. Something structural is malformed: the selector record does not exist, the record is broken, or the DKIM-Signature header itself is structurally invalid.

Likely causes

• Selector TXT does not exist (NXDOMAIN response). The signer is emitting a selector name that was never published, or was published under a different name. The most common cause is a signer-side typo (publishing selector1 but signing with s=default) or a DNS publication that never propagated.
• TXT exists but contains no v=DKIM1. RFC 6376 §3.6.1 requires the record to begin with v=DKIM1 (or implicitly for backward-compat). A record that begins with k=rsa; p=... alone will be rejected by strict verifiers.
• TXT contains malformed key data — truncated p= (the public-key base64 was clipped during DNS publication, often because the provider's web UI imposed a character limit), embedded whitespace inside the base64 (the publisher inserted line-breaks for readability and forgot to strip them), or the public key in a non-PEM format the verifier cannot parse.
• DKIM-Signature header is malformed — missing v=1, missing required tag, base64 in b= or bh= contains non-base64 characters, h= tag has unbalanced colons, or the entire header is concatenated on a single line in a way that violates RFC 5322 line-length rules.
• Unsupported algorithm in a=. Most modern receivers reject rsa-sha1 (deprecated per RFC 8301). A record using a=rsa-sha1 may emit dkim=permerror at receivers that have removed SHA-1 support.

Next steps

1. Run dig +short selector._domainkey.example.com TXT. If you get NXDOMAIN, the record is not published — publish it per your provider's recipe (help_dkim_for_microsoft_365.php, help_dkim_for_google_workspace.php, etc.).
2. If the record exists, paste the full response into the Domain Security Checker — it validates the record structurally (v=DKIM1 prefix, p= base64 well-formed, no truncation).
3. If the record validates, inspect the failing DKIM-Signature header in the Email Header Analyzer — the parser will flag the specific malformed tag.
4. If the algorithm is rsa-sha1, switch your signer to a=rsa-sha256 per RFC 8301. This requires a new key pair and a new selector record because the algorithm is baked into the key derivation.

Symptom: dkim=policy

What it means: the cryptographic verification would have succeeded, but the verifier rejects the signature on local-policy grounds — the algorithm is too weak, the key is too short, a required header was not signed, or some other policy gate failed. dkim=policy is the explicit "I refuse to validate this even though it is well-formed" verdict.

Likely causes

• Algorithm too weak. Most modern receivers refuse rsa-sha1 signatures (RFC 8301 deprecates SHA-1 for DKIM). Switching to a=rsa-sha256 is the fix; this requires a new key pair and selector.
• Key length too short. Some receivers refuse RSA keys under 1024 bits (clearly too short by 2026), and increasingly many refuse keys under 2048 bits. M365 auto-upgraded all tenant keys to 2048-bit in 2022-2023; Workspace and most cloud providers now default to 2048-bit. See help_dkim_key_rotation.php for the rotation discipline.
• From: not in h=. RFC 6376 §5.4 MANDATES From signing. Receivers that enforce §5.4 strictly emit dkim=policy when h= omits From.
• Local-policy required header missing. Some receivers require additional headers in h= beyond From — typically Date, Message-ID, and Subject. The modern best-practice signer covers a much larger set than the minimum.
• Signature timestamp anomaly. If t= is in the future (clock-skewed signer) or x= is in the past (expired signature), some receivers emit dkim=policy.

Next steps

1. Identify the policy failure mode from the Authentication-Results reason="..." annotation. Modern receivers say "algorithm not supported", "key too short", "from not signed", etc.
2. If the cause is rsa-sha1, generate a new key pair using rsa-sha256, publish under a new selector, and switch the signer. Per RFC 8301 this is the modern default and the only future-proof choice besides ed25519-sha256 (RFC 8463).
3. If the cause is key length, generate a 2048-bit RSA key (or Ed25519, much shorter records). Most cloud providers automate this; for self-hosted signers see help_dkim_cryptography_basics.php.
4. If the cause is a missing signed header, expand the signer's h= configuration. The canonical modern set covers From, Subject, Date, To, Cc, Reply-To, Sender, Message-ID, MIME-Version, Content-Type, Content-Transfer-Encoding, List-Unsubscribe, In-Reply-To, References, Auto-Submitted.

Multi-signature scenarios

A message MAY carry more than one DKIM-Signature header. The verifier evaluates each independently per RFC 6376 §6.1 and emits one dkim= entry per signature in the Authentication-Results header. For DMARC purposes, the rule per RFC 7489 §3.1.1 is "any aligns wins": if ANY of the dkim=pass results has a d= aligned with the From: header, DMARC alignment is satisfied.

Common scenarios

• Sender signs once, marketing platform signs again. When you send through a SaaS platform (Mailchimp, SendGrid), the platform signs with its own selector under its own d=, and if you have configured custom-domain DKIM the platform also signs with your domain's selector. The result is two DKIM-Signature headers — one with the platform's d= (will not align for DMARC) and one with yours (will align if configured correctly).
• On-prem signs, M365 re-signs after hybrid relay. In hybrid Exchange topology (on-prem + Exchange Online), if both sides sign, two DKIM-Signatures appear. The receiver picks the one with the aligned d=. The non-deterministic behavior is the "dual-signer DKIM problem" documented in help_dmarc_for_office_365_hybrid.php.
• Forwarder adds an ARC-Seal but not a new DKIM-Signature. ARC (RFC 8617) is a layered authentication chain, not a DKIM extension. A forwarder that ARC-seals does NOT add a second DKIM-Signature; instead it adds an ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results. The original DKIM-Signature may still fail at the receiver, but the ARC chain carries forward the forwarder's earlier cv=pass verdict — receivers that trust the forwarder (Defender Trusted ARC Sealers, Google's ARC trust list) accept the message on the ARC-attested earlier DKIM result.
• Multiple signatures with conflicting results. Two DKIM-Signature headers: one dkim=pass, one dkim=fail. The receiver emits both verdicts in Authentication-Results. For DMARC alignment the dkim=pass with the aligned d= wins. For operator diagnosis the dkim=fail is still worth understanding — it may indicate a layered-signing pipeline where one stage works and another is broken.

Diagnosis

Open the message in the Email Header Analyzer. It surfaces all DKIM-Signature instances and pairs each with the corresponding Authentication-Results dkim= entry. For each instance read the d= value and the resulting verdict; identify which signature would have aligned with the From: header, and whether that aligning signature passed cryptographically. If the answer is "no aligning signature passes", you have an alignment configuration gap — see the alignment-gotcha section.

Provider-specific quick references

The big cloud senders have well-known failure modes that map cleanly to the symptom branches above. Use this section as a quick reference when the failing source IP belongs to one of the major providers.

Microsoft 365 (Exchange Online)

• Default behavior: signs with d=tenantname.onmicrosoft.com and selectors selector1 / selector2 hosted at selector1-tenantname.onmicrosoft.com.
• Most common regression: dkim=pass + DMARC fail because the tenant signs with the onmicrosoft.com identity rather than the custom domain. Fix: enable custom-domain DKIM in Defender for Office 365, publish the two CNAMEs at selector1._domainkey.example.com and selector2._domainkey.example.com, then enable signing. Recipe: help_dkim_for_microsoft_365.php.
• Dashed-domain transformation gotcha: hyphenated domains (example-uk.com) require the CNAME target to use a double-dash transformation (example--uk-com). Hand-constructing the target is a common failure source — use Microsoft's portal-provided values verbatim.
• Rotation: M365 rotates automatically every 6 months between selector1 and selector2 with no operator action required. If you see dkim=fail spikes every 6 months the rotation is working but propagation is slow — usually a 4-hour TTL window per published CNAME.

Google Workspace

• Default behavior: signs with d=tenantname.gappssmtp.com if no custom-domain key is configured. gappssmtp.com is on the Public Suffix List, so relaxed alignment also fails.
• Most common regression: dkim=pass + DMARC fail because of the gappssmtp.com signing identity. Fix: generate a custom-domain 2048-bit DKIM key in the Workspace Admin Console (Apps → Google Workspace → Gmail → Authenticate email), publish the TXT record to google._domainkey.example.com verbatim from the Admin Console (the value is a single long string with embedded v=DKIM1; k=rsa; p=...), wait for DNS propagation, then click "Start authentication". Recipe: help_dkim_for_google_workspace.php.
• 255-byte TXT chunking rule: the 2048-bit DKIM TXT record from Workspace is over 255 bytes long, requiring RFC 1035 §3.3.14 multi-string splitting. Most modern DNS providers handle this automatically but legacy panels may force you to chunk by hand using quoted strings.
• Rotation: Workspace requires manual rotation — no automatic rotation like M365. Generate a new selector record in the Admin Console, publish, wait for propagation (1 week recommended), then click "Switch to new key".

SendGrid / Mailgun / Mailchimp / SaaS senders

• Default behavior: sign with the platform's own domain (d=sendgrid.net, d=mailgun.org, d=mailchimp.com). Receivers see dkim=pass but DMARC alignment fails against your custom From: domain.
• Most common regression: dkim=pass + DMARC fail because you have not configured custom-domain DKIM on the platform. Fix: every SaaS sender has a "domain authentication" or "sender identity" workflow — find your platform's recipe, publish the per-platform selector CNAMEs, and the signer switches to a custom-domain identity.
• Click-tracking rewriting interferes: platforms that rewrite URLs for click tracking may break body hashes if rewriting happens after signing. Modern platforms sign AFTER URL rewriting precisely to avoid this — confirm in the platform's settings that the signing pipeline order is correct.

Amazon SES / Postmark / SparkPost / cloud relays

• Default behavior: all major transactional ESPs support custom-domain DKIM as first-class configuration. Selectors and TXT records are provided in the platform console.
• Most common regression: the provided TXT was published with embedded line-breaks or truncated by the DNS provider UI. dkim=permerror follows. Fix: republish from the platform console verbatim, preserving any quote marks or chunked structure.

Self-hosted signers (Postfix, OpenDKIM, Exim, Sendmail)

• Default behavior: you choose the selector, algorithm, and key size. Modern best-practice: a=rsa-sha256 (per RFC 8301), c=relaxed/relaxed, 2048-bit RSA, selector identifier including the rotation date (e.g., 20260522).
• Common regression: clock skew on the signer host (NTP not synchronized) produces signatures with t= values that receivers reject as clock-anomalous. Ensure chrony or ntpd is running and stratum-2 or better.
• Common regression: the signing milter is not in the outbound path for all message flows — only some messages get signed. Validate with the Email Header Analyzer on test sends from each outbound flow.

Tools for diagnosis

The DMARC Analyzer toolchain provides the primary diagnostic surfaces for every symptom on this page. External tools listed underneath are recommended second-opinion checks.

Email Header Analyzer (header_analyzer.php)

Paste any raw email source or just the headers. The parser surfaces:

• Every DKIM-Signature instance, tag-by-tag, with the tag-anatomy reference applied to each value.
• The Authentication-Results verdict pairs (dkim=X plus any reason= annotation).
• The Received: header chain annotated with the signing hop (last aligned line) and subsequent intermediaries (potential body-rewriters).
• Any malformed-tag detection per the tag-anatomy reference's structural rules.

Domain Security Checker (domain_checker.php)

Validates the public-key TXT side of DKIM. Paste your domain and selector; the checker:

• Resolves selector._domainkey.example.com from multiple geographic resolvers and reports the TXT response.
• Validates the record begins with v=DKIM1 and contains a structurally valid p= public key.
• Checks for the 255-byte chunking rule (RFC 1035 §3.3.14) and warns if chunking looks wrong.
• Surfaces the underlying DNS error class when resolution fails (NXDOMAIN, SERVFAIL, timeout).

DMARC Analyzer Dashboard (index.php)

The dashboard surfaces aggregate- report rows by reporter and by source IP. Drill down on a failing row to see the per-IP failure profile — source_ip_detail.php shows every aggregate-reported failure attributed to that IP over the chosen time window with the DKIM and SPF auth results inline.

External diagnostic helpers

• dig +short selector._domainkey.example.com TXT — the canonical command-line DNS lookup. Use from multiple geographic resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9).
• opendkim-testkey — validates a published TXT matches a local private key. Useful for self-hosted signers verifying their key pair publication.
• mxtoolbox.com, dkimvalidator.com — second-opinion validators for the published TXT and for sample messages.

Operator decision matrix

At-a-glance summary: pick the symptom row to find the most likely cause and the highest- leverage next step.

FAQ

My DMARC aggregate report shows dkim=fail. What is the first thing to check?

Start by determining whether the failure is a body-hash mismatch (bh=) or a signature mismatch (b=). Open the affected message in the Email Header Analyzer and read the Authentication-Results header — receivers like Google and Microsoft now annotate dkim=fail with the specific reason (e.g., "dkim=fail reason="signature did not verify"" vs "dkim=fail reason="body hash did not verify""). About 80% of dkim=fail in practice is a body-hash mismatch caused by a forwarder, mailing list, or content-scanning gateway rewriting the body after signing. The other 20% is a signature mismatch caused by a header being added or modified after signing (most commonly a Subject prefix added by an anti-spoof gateway). Once you know which hash failed, follow the symptom branch on this page: body-hash mismatch → forwarder/list/gateway investigation; signature mismatch → header-rewrite investigation.

Authentication-Results says dkim=pass but DMARC still fails. Why?

dkim=pass means the cryptographic verification succeeded — the body hash matched and the signature verified against the public key in DNS. It does NOT mean DMARC passed. DMARC additionally requires ALIGNMENT: the d= tag in the DKIM-Signature header must match the From: header domain (relaxed) or be byte-identical to it (strict). The two most common sources of dkim=pass + DMARC=fail are: (a) Microsoft 365 tenants where the cloud signs with d=tenantname.onmicrosoft.com instead of the custom domain (tenant-default signing — fix by publishing the two selector CNAMEs from Defender for Office 365), and (b) Google Workspace tenants where the cloud signs with d=tenantname.gappssmtp.com instead of the custom domain (gappssmtp.com is on the Public Suffix List, so the relaxed organizational-domain match also fails — fix by generating a custom-domain DKIM key in the Workspace Admin Console). The full alignment evaluation algorithm is documented in help_dkim_alignment_with_dmarc.php.

I see dkim=temperror in my logs. Is this a problem?

dkim=temperror means the verifier could not retrieve the public-key TXT record at verification time but the failure is transient (DNS timeout, intermittent resolver issue, recursive name server outage). RFC 6376 §6.1.2 mandates that receivers MAY retry temperror-classified messages. dkim=temperror on a small percentage (under 1%) of your traffic is normal background noise from internet routing turbulence. dkim=temperror on a sustained large percentage of your traffic is a sign of a real problem: your authoritative name servers are overloaded or unreachable, or your TXT record is too large for UDP (over 512 bytes without EDNS0) and is being truncated. Diagnose with: (a) dig @8.8.8.8 selector._domainkey.example.com TXT from multiple resolvers to confirm consistent successful resolution, (b) check the size of the TXT response — 2048-bit RSA keys often need EDNS0 or chunked TXT splitting per RFC 1035 §3.3.14, (c) check authoritative name server logs for query-volume spikes that could be triggering rate limits.

How do I tell if a body-hash mismatch was caused by a forwarder or by a content-scanning gateway?

The Received: header chain reveals which intermediaries handled the message. Open the failing message in the Email Header Analyzer and read the Received: headers from bottom to top (oldest hop first). The signer is the last hop before the first non-aligned Received: line — anything that handled the message AFTER signing and BEFORE the verifier could have rewritten the body. Common culprits identified by Received: signatures: forwarders show ".forwarder." or "mailman.example.com" lines; mailing lists show "list-id:" headers and "List-Unsubscribe:" footer injection; content-scanning gateways show "antispam-" or "scanned by" annotations; SaaS marketing platforms show "x-original-sender:" or "x-mailer:" branding. Once identified, the fix is either (a) switch the upstream to relaxed body canonicalization which tolerates whitespace edits, (b) get an ARC seal across the boundary so DMARC trusts the original DKIM result, or (c) accept the dkim=fail and rely on SPF alignment via the forwarder (only works if SRS rewriting is in place).

What does dkim=permerror mean and how do I fix it?

dkim=permerror is the verifier saying "the signature is malformed at a structural level — retrying would not help". The most common causes: (a) the selector._domainkey TXT record does not exist (NXDOMAIN) — you forgot to publish it, or you published it under the wrong selector name; (b) the TXT record exists but contains malformed key data (truncated p= value, accidental whitespace inside the base64-encoded key, wrong v=DKIM1 prefix); (c) the DKIM-Signature header itself is malformed (missing v=1, missing required tag, b= or bh= not valid base64, h= tag with unbalanced colons); (d) the algorithm in a= is not supported by the verifier (most receivers now reject rsa-sha1 per RFC 8301). Fix by: (1) dig +short selector._domainkey.example.com TXT to confirm the record resolves and the response looks sane (single line, v=DKIM1, p=<long base64>), (2) paste the DKIM-Signature header into the Email Header Analyzer to see which tag the parser flagged, (3) re-publish the record using the operator-provided DNS records from your provider (Microsoft 365 / Google Workspace / etc.) — do not hand-edit.

My provider rotated keys and now everything fails. What happened?

DKIM key rotation requires dual-selector overlap — the new selector must be published in DNS and verified to resolve from multiple geographic resolvers BEFORE the signer is switched over. If the new selector was not published, or if the TTL on the old selector record was so short that caches missed the rotation window, in-flight messages will be signed with selector N but receivers will look up selector N+1 (or vice versa) — every dkim=fail until the lookup catches up. Fix in the immediate term: republish the old selector record exactly as it was (your provider almost always keeps it for 30 days post-rotation specifically for rollback). Then wait for caches to drain (look at the original record TTL — usually 1 hour for cloud providers). Long-term fix: enforce a minimum 7-day overlap between old and new selectors when rotating. Microsoft 365 handles this automatically via the alternating selector1/selector2 design; Google Workspace requires manual rotation discipline per help_dkim_for_google_workspace.php.

How do I troubleshoot multiple DKIM signatures on a single message?

A message MAY carry more than one DKIM-Signature header — a sender can add multiple signatures (one per sub-brand) and an intermediary like a marketing platform may add its own signature on top. Per RFC 6376 §6.1 the verifier evaluates each signature independently and produces one Authentication-Results entry per signature. For DMARC purposes, the alignment rule per RFC 7489 §3.1.1 is "any aligns wins" — if ANY of the dkim=pass results has a d= tag aligned with the From: header, DMARC alignment is satisfied. Troubleshooting steps: (1) read the Authentication-Results header — every dkim= entry corresponds to one DKIM-Signature header; (2) identify which signature has the aligned d= (matches your From: domain); (3) if NO signature has an aligned d=, you have an alignment-not-cryptography failure — fix by publishing your own custom-domain DKIM key with the signer (the cloud-default tenant-domain signing is not enough); (4) if MULTIPLE signatures have aligned d= but at least one fails, the failures are usually a layered-signing artifact (an outer ARC sealer also re-signed) and not actionable — focus on the aligned passing signature.

What is the difference between dkim=neutral and dkim=none?

dkim=none means the message had NO DKIM-Signature header at all — the sender never signed it. This is the verdict for plain SMTP traffic from non-signing senders, and from any path where the sender did not deploy DKIM. dkim=neutral is rare and means "I found a signature and a key but I am unable to render a decisive verdict" — most commonly when the verifier encountered a structural anomaly that is not strictly malformed (an unrecognized but tolerable tag, an experimental algorithm, a policy-required header that is missing). Operationally: dkim=none is fine for a domain that has not deployed DKIM (deploy DKIM if you want DMARC to pass via DKIM); dkim=none on a domain that HAS deployed DKIM means the signing step in your outbound path is failing (check upstream signer logs). dkim=neutral on a domain that has deployed DKIM means a configuration anomaly worth investigating in the Email Header Analyzer.

Related guides

• DKIM failures explained (verdict catalogue) — the canonical receiver-side verdict reference (dkim=none / neutral / pass / fail / policy / temperror / permerror) with RFC 6376 §3.9 normative definitions. This page is the symptom-driven counterpart; the catalogue is the verdict-string reference.
• SPF PermError vs TempError — the SISTER-AUTHENTICATION-MECHANISM-DKIM- VS-SPF-FAILURE-MODE-CONTRASTING- TROUBLESHOOTING-LADDER companion to this DKIM troubleshooting guide. Where THIS page documents the symptom-driven diagnostic ladder for DKIM-component failures (selector publication errors, signing-key rotation regressions, body-modification canonical- ization breakage, header-set h= tag drift, third-party-signer alignment ambiguity), the SPF permerror-vs-temperror spoke is the STRUCTURAL PEER on the SPF-mechanism side — the two pages together form the complete per-component auth_results diagnostic catalogue every operator needs when an aggregate RUA row's dmarc=fail verdict's root cause is ambiguous between DKIM-component failure and SPF-component failure. Four per-auth-results-component- interpretation dimensions: (i) RFC-7208-§2.6 SPF-RESULT-CODE-VS-RFC-6376-§3.9 DKIM- RESULT-CODE structural pairing (the SPF result-code catalogue none / neutral / pass / fail / softfail / temperror / permerror and the DKIM verdict catalogue none / neutral / pass / fail / policy / temperror / permerror share the permerror-temperror axis — the SPF spoke documents the per-cause root-cause attribution and remediation playbook this DKIM troubleshooting guide already documents on the DKIM-mechanism side), (ii) AUTHENTICATION-RESULTS HEADER FIELD CANONICAL-DECODING-DISCIPLINE (RFC 8601 §2.7 canonical Authentication-Results header field encodes per-component result codes the receiver feeds into DMARC evaluation — the operator's mental model for decoding the spf=permerror / spf=temperror tokens MUST be structurally symmetric to the dkim=permerror / dkim=temperror decoding this DKIM troubleshooting guide documents), (iii) PER-RECEIVER-INTERPRETATION-VARIANCE symmetric pattern (Gmail and Microsoft 365 BOTH fail-OPEN on TempError for BOTH SPF and DKIM to avoid legitimate-mail delivery loss but treat PermError as a hard fail feeding DMARC evaluation — the per-receiver- interpretation variance pattern is uniform across the two authentication mechanisms), (iv) PER-MESSAGE-DMARC-FAIL-COMPONENT- ATTRIBUTION discipline (when an aggregate RUA row reports dmarc=fail the operator MUST attribute the failure to either the SPF component or the DKIM component — the symmetric per-code troubleshooting ladders are the canonical reference for that attribution: if the row reports spf=permerror and dkim=pass the SPF spoke is the next-step diagnostic reference, if the row reports spf=pass and dkim=fail THIS DKIM troubleshooting guide is the next-step diagnostic reference, if BOTH components report failures the operator runs the SPF-component diagnostic ladder and the DKIM-component diagnostic ladder in parallel). Critical when this DKIM troubleshooting guide's per-component diagnostic ladder reaches an auth_results row whose DKIM-component verdict is pass but whose DMARC verdict is still fail — the SPF-component diagnostic ladder in the permerror-vs-temperror spoke is the canonical next step in distinguishing the residual DMARC-fail root cause.
• DKIM-Signature header explained (tag anatomy) — byte-by-byte reference for every tag in the DKIM-Signature header per RFC 6376 §3.5. Use when the symptom branch points at a malformed or anomalous tag.
• DKIM alignment with DMARC — the full alignment algorithm from the DKIM angle per RFC 7489 §3.1.1. Use when the symptom is dkim=pass + DMARC fail.
• DKIM canonicalization — the c= tag deep dive. Use when the symptom is dkim=fail body-hash mismatch and you suspect whitespace folding by an intermediary.
• DKIM selectors explained — the s= tag deep dive. Use when the symptom is dkim=permerror NXDOMAIN.
• DKIM DNS record syntax (TXT-record byte reference) — the byte-by-byte reference for the TXT record at <selector>._domainkey.<d-domain> operators consult during the dkim=permerror / dkim=fail diagnosis path this page documents. Where this troubleshooting page documents the symptom-to-action sequence (run dig TXT <selector>._domainkey.<d-domain> from multiple geographic resolvers, compare the returned record bytes against what the receiver actually fetched, identify which key the signer used at message-sign time), the DNS- syntax page documents the byte-level rules the returned record must satisfy to be accepted as a valid DKIM public- key record: the v=DKIM1 version-tag floor (omitted records are treated as DKIM1-implicit per RFC 6376 §3.6.1, but explicit publication protects against future version ambiguity), the k=rsa / k=ed25519 algorithm tag, the p=<base64-public-key> tag carrying the DER-encoded SubjectPublicKeyInfo (the p= empty value is the official key-revocation signal — a deliberate-revocation-vs-accidental- deletion diagnostic split your troubleshooting must distinguish), the 2048-bit-floor encoding constraint with the split-string TXT-record concatenation rule (Cloudflare auto- splits, GoDaddy requires manual 255- byte chunking, BIND requires the ("..." "...") concatenation form — the #1 silent- rejection cause when a registrar UI truncates the public key at the 255-byte boundary without splitting), and the optional t=y/t=s/ h=/n=/ g=/s=* tag family. Read this page when a dig TXT returns a record that LOOKS published but produces a dkim=permerror or dkim=fail verdict at the receiver — the byte-level constraints documented here surface every silent-rejection cause that does not produce a NXDOMAIN signal.
• DKIM key rotation — the rotation cadence and dual-selector overlap guide. Use when the symptom is a post-rotation regression.
• DKIM replay attacks — the threat-model deep dive. Use when diagnosing the l= tag, t=/x= timestamps, or the RFC 9103 replay-mitigation material.
• DKIM cryptography basics — the algorithm and key-size primer. Use when the symptom is dkim=policy algorithm-too-weak or key-too-short.
• DKIM explained (protocol primer) — the high-level signing and verification pipeline. Use as the foundational reference if you are new to DKIM.
• DKIM best practices — the preventive complement to this symptom-driven troubleshooting guide. Where this page documents how to diagnose a failing DKIM verdict, the best-practices page documents the deployment defaults that would have prevented the failure class in the first place: the 2048-bit RSA / Ed25519 algorithm floor (preempts dkim=policy algorithm-too-weak), the c=relaxed/relaxed canonicalisation default (preempts most forwarder body-hash mismatches), the 90-day rotation cadence (bounds the replay window), the l= tag avoidance (preempts body-extension attacks), the RFC 9103 x= expiration tag (bounds captured-signature lifetimes), the dual-selector overlap pattern (preempts post-rotation regressions referenced earlier in this list), and the alignment prerequisites (preempts dkim=pass + DMARC=fail). Read once you have diagnosed the current incident on this page and want to harden the deployment so the same class does not recur.
• DKIM for Microsoft 365 — the M365-specific deployment recipe. Use when the failing source is the M365 cloud.
• DKIM for Google Workspace — the Workspace-specific deployment recipe. Use when the failing source is the Workspace cloud.
• SPF for Google Workspace — the WORKSPACE-TENANT-CANONICAL- include:_spf.google.com-CASCADE-AS-DMARC- COMPOSITE-VERDICT-ALIGNMENT-INPUT-WHEN-PER- MESSAGE-DKIM-VERDICT-IS-DOWNGRADED companion to this DKIM symptom-driven diagnostic ladder. Where THIS page documents the operator-side per-verdict DKIM diagnostic decision tree (the seven verdict-keyword symptoms + the body-hash-mismatch / signature-mismatch subclasses + multi- signature scenarios + the provider-specific quick references), the SPF-for-Workspace spoke is the ALIGNMENT-FALLBACK COMPANION documenting the per-Workspace-tenant SPF publication discipline that becomes the load-bearing DMARC composite-verdict alignment input when the per-message DKIM verdict diagnosed on THIS page is downgraded to fail / none / permerror / temperror. FOUR per- Workspace-tenant DKIM-troubleshooting-vs- SPF-fallback coupling dimensions: (i) per-Workspace-tenant single- selector google._domainkey DKIM-failure-mode fallback to per-tenant SPF alignment-pass — when the single-selector DKIM verdict on a Workspace-tenant outbound message downgrades (per-tenant p=-tag misconfiguration, per-selector key-rotation drift, per- forwarder body-hash-mismatch from MLM modifications), the per-tenant SPF verdict from include:_spf.google.com becomes the SOLE DMARC composite-pass path; (ii) per-Workspace-tenant receiver-side spf= aligned-pass floor — the SPF-for-Workspace spoke documents the per-Workspace-tenant canonical include:_spf.google.com baseline whose per-receiver-side aspf=relaxed / aspf=strict alignment evaluation produces the DMARC SPF-aligned-pass floor that backs up the DKIM-troubleshooting ladder ON THIS PAGE; (iii) per-Workspace-tenant joint SPF + DKIM operator-hygiene coordination — the per-Workspace- tenant joint deployment requires both operator-published google._domainkey TXT (DKIM, this page's diagnostic subject) AND operator-published v=spf1 include:_spf.google.com -all TXT (SPF, the spoke's diagnostic subject) at the customer-vanity-domain DNS zone; both records co-publish or both co-misconfigure, so the operator- side troubleshooting workflow MUST cross-reference the per-Workspace-tenant SPF publication record alongside the per-selector DKIM key publication; (iv) per-Workspace-tenant spf.protection.outlook.com- equivalent-as-NOT-applicable contrast — Workspace tenants publish include:_spf.google.com directly at the customer-vanity-domain, whereas M365 tenants publish include:spf.protection.outlook.com; the SPF-for-Workspace spoke documents the per-Workspace-tenant-specific cascade topology (the _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com recursive expansion) the per-tenant operator must understand when coordinating per-tenant SPF budget vs the per-tenant joint DKIM verdict diagnosed on THIS page.
• DMARC alignment (DMARC engine view) — the symmetric SPF + DKIM alignment reference from the DMARC-engine angle.
• ARC explained — the layered-authentication chain that rescues DKIM verdicts across forwarders and mailing lists.
• DMARC for Hybrid Exchange — the dual-signer DKIM problem in on-prem + cloud topology.
• DMARC troubleshooting — the DMARC-side companion to this page. Use for SPF, alignment, and reporting- pipeline symptoms.
• DMARC deployment checklist — the DKIM-VERDICT-DIAGNOSTIC-FEEDS-PHASE-2- TRIAGE-ALIGNMENT-FIX-BACKLOG-AND-PHASE-EXIT- CRITERIA-DKIM-FAIL-RATE-FLOOR-CONTRACT companion to this DKIM symptom-driven diagnostic ladder. Where THIS page documents the operator-side per-verdict DKIM diagnostic decision tree (the seven verdict-keyword symptoms dkim=none / neutral / pass / fail / policy / temperror / permerror + the body-hash-mismatch / signature-mismatch subclasses + multi-signature scenarios + provider-specific quick references + the operator decision matrix), the deployment- checklist page documents the FOUR-PHASE operator-side rollout where every Phase 2 alignment-fix backlog entry and every Phase 3 / Phase 4 ramp-step exit criterion STRUCTURALLY CONSUMES the per-verdict DKIM diagnostic ladder THIS page documents as the operator-side per-failure-mode remediation- of-record. Four DKIM-VERDICT-VS-DEPLOYMENT- PHASE feedback-loop axes the deployment- checklist documents: (i) Phase 1 Discovery (p=none) as the PER-VERDICT-DKIM-FAIL-RATE-BASELINE- MEASUREMENT-PHASE — the deployment- checklist Phase 1 gates require the publisher to ingest 30 days of aggregate reports and classify the per-source-IP DKIM verdict distribution; the per-verdict diagnostic ladder THIS page documents is the operator- side translation reference that converts each Phase 1-collected per-source-IP dkim=fail / dkim=permerror aggregate row into a concrete root-cause diagnosis (body-hash mismatch, signature- mismatch, multi-signature collision, key- rotation gap, selector-misconfiguration, canonicalisation choice, third-party signer misalignment); (ii) Phase 2 Triage (alignment-fixing) as the PER-VERDICT-DKIM- FIX-BACKLOG-EXECUTION-PHASE — the deployment-checklist Phase 2 backlog is the concrete fix-ladder built from the Phase 1-collected per-source-IP DKIM verdicts; each backlog entry resolves to one of the per-verdict remediation paths THIS page documents (re-publish DKIM TXT record with correct public-key tag, enrol a per-customer DKIM CNAME selector, align canonicalisation choice across signer / verifier, rotate compromised keys, fix multi-signature ordering); the Phase 2 exit criteria require the per-source-IP DKIM-fail rate to fall below the alignment-rate floor for every legitimate sender before advancing to Phase 3; (iii) Phase 3 Quarantine (p=quarantine pct=N) as the PER-VERDICT-DKIM-FAIL-RATE-PER-PERCENTAGE- RAMP-EXIT-CRITERIA-PHASE — the deployment-checklist Phase 3 ladder (pct=10 -> pct=25 -> pct=50 -> pct=100 on a per-week cadence) STRUCTURALLY DEPENDS on the per-verdict DKIM diagnostic ladder THIS page documents to convert each per-week aggregate-report- observed dkim=fail / dkim=permerror row spike into a concrete root-cause classification (is this a NEW misalignment / a rotation-gap / a third-party signer collision / a canonicalisation regression?) — without the per-verdict ladder, the per-percentage ramp would be a blind gamble; (iv) Phase 4 Enforcement (p=reject) as the PER-VERDICT-DKIM-FAIL-RATE-ROLLBACK- DECISION-TRIGGER-PHASE — the deployment-checklist Phase 4 rollback procedure (lower p=reject back to p=quarantine on the same TTL cycle when a false-positive dmarc=reject disposition surfaces on legitimate mail) is triggered by the per-verdict DKIM diagnostic ladder THIS page documents to confirm the Phase 4-observed dkim=fail spike on legitimate-source IPs is a genuine misalignment regression rather than an attacker-driven baseline shift; the rollback procedure STRUCTURALLY DEPENDS on this page's diagnostic ladder to make the rollback-vs-hold decision within the 60-minute TTL window before the cached p=reject disposition propagates further. Pair this DKIM troubleshooting page (the per- verdict diagnostic-and-remediation ladder) with the deployment-checklist page (the four-phase operator rollout that consumes the diagnostic ladder at every Phase 2 backlog entry and every Phase 3 / Phase 4 exit-criteria gate) for the complete DKIM-verdict-diagnostic-AND-DMARC- deployment-execution-discipline posture every operator needs to ramp DMARC from p=none to p=reject with concrete per-verdict-driven Phase 2 backlog fix-ladder execution and Phase 3 / Phase 4 per-percentage-ramp / rollback decisions instead of blind aggregate- report-row-count gambling.
• Business Email Compromise (BEC) — the FINANCIAL-FRAUD-INCIDENT-RESPONSE- FORENSIC-CONSUMER companion to THIS DKIM troubleshooting reference. Where THIS page documents the symptom-driven debugging decision tree keyed off the seven DKIM verdicts (dkim=none / neutral / pass / fail / policy / temperror / permerror) and the per-symptom diagnose-and-fix sequence (DNS lookups, header inspection, provider-side configuration checks, third-party validator consultation), the business_email_compromise spoke documents the FINANCIAL-FRAUD- INCIDENT-RESPONSE PATHWAY whose first triage step is the per-message DKIM-verdict diagnostic THIS page operationally provides. Four structurally-distinct DKIM-troubleshooting-as-BEC-incident-response operational classes the spoke covers that THIS troubleshooting reference intentionally elides: (i) per-BEC-variant the canonical DKIM-symptom signature — each of the six BEC variants (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, VEC) has a canonical DKIM-symptom signature on the forensic envelope (direct-domain From-header forgery produces dkim=none when attacker cannot sign; lookalike-domain attacks produce dkim=pass on the WRONG d= domain; hijacked-legitimate-sender attacks produce dkim=pass on the CORRECT d= — the latter is the diagnostically-hardest BEC variant the spoke catalogues); (ii) FBI Financial Fraud Kill Chain triage-from- DKIM-verdict pathway — the FBI IC3 incident-response playbook documented on the BEC spoke INTERSECTS with THIS page's diagnostic methodology — the first forensic-evidence preservation step is to capture the raw email source (including the Authentication-Results header and any DKIM-Signature headers) BEFORE the DKIM-verdict diagnostic THIS page documents is consumed; (iii) BEC defense-in-depth six-layer stack vs DKIM-troubleshooting reactive diagnosis — the BEC spoke documents a SIX-LAYER PROACTIVE defense stack (DMARC p=reject, secure-email gateway, content filtering, user training, financial-process out-of- band confirmation, incident-response playbook) of which the DKIM-verdict-driven diagnostic THIS page provides is the REACTIVE forensic-investigation layer once defense-in-depth is breached; (iv) BEC executive-sponsorship-via- cost-statistics framing — the BEC spoke catalogues BEC-vs-ransomware cost statistics that justify the executive sponsorship needed to fund the systematic DKIM deployment THIS troubleshooting reference presupposes; without executive sponsorship for the underlying DKIM deployment, the troubleshooting decision tree on this page has no signing infrastructure to debug. Required reading once an operator using this troubleshooting page identifies a dkim=fail / dkim=none verdict on a suspected fraudulent message and needs to cross-reference the per-BEC-variant attacker-technique signature catalogue for incident-response classification.
• Email spoofing explained — the DKIM-VERDICT-DIAGNOSTIC-LADDER- AS-PER-SPOOFING-TECHNIQUE-ATTRIBUTION- CLASSIFIER companion to this DKIM troubleshooting runbook. Where THIS page documents the symptom-driven debugging decision tree keyed off the seven DKIM verdicts (dkim=none / neutral / pass / fail / policy / temperror / permerror), the email-spoofing spoke documents the ADVERSARY-SIDE seven-spoofing-technique catalogue whose per-technique attack-vector produces a DISTINCT DKIM-verdict signature THIS troubleshooting page's diagnostic ladder must classify. Concretely, the spoke documents FOUR DKIM-verdict-to-spoofing-technique- attribution dimensions: (i) dkim=none on the From:-aligned domain attributes to spoofing Technique #1 (exact-domain From-header forgery) — the attacker cannot sign because the attacker does NOT possess the protected domain's DKIM private key, producing a dkim=none verdict that the diagnostic ladder THIS page documents classifies as the canonical direct-domain spoofing signature requiring immediate p=quarantine / p=reject policy enforcement at the receiver; (ii) dkim=pass on the WRONG d= domain (the signing domain in the DKIM-Signature header is the attacker's example-corp.com cousin-domain instead of the protected example.com org-domain) attributes to spoofing Technique #5 (cousin/lookalike domain registration with Punycode- confusable IDN homograph) — the DKIM verdict structurally PASSES because the attacker properly signs with the cousin-domain's own DKIM key, but DMARC ALIGNMENT against the protected domain fails; the diagnostic ladder THIS page documents classifies this signature as the canonical lookalike-attack-campaign signature requiring escalation to the portfolio-wide cousin-domain protective-registration discipline; (iii) dkim=pass on the CORRECT d= domain BUT on a message the operator did NOT send attributes to spoofing Technique #7 (compromised-account VEC — Vendor Email Compromise) — the DKIM verdict structurally PASSES because the attacker is using the legitimate sender's infrastructure (with valid DKIM signing) AND the From: header is the protected domain, producing the DIAGNOSTICALLY-HARDEST DKIM verdict the seven-verdict catalogue contains; the only structural detection primitive is the per-source-IP per-recipient-pattern baseline drift detection requiring cross-reference with the monitoring-discipline observability infrastructure (THIS page's diagnostic ladder STRUCTURALLY CANNOT detect this class from the DKIM verdict alone); and (iv) dkim=temperror on the From:-aligned domain attributes to a CONFOUND class that can MASK spoofing Technique #1 attacks via false negative (the receiver-side DNS resolver outage causes a legitimate-sender's DKIM signature to register as dkim=temperror instead of the dkim=none the attacker's unsigned message would produce, so an operator interpreting a dkim=temperror trend spike as a transient-DNS-outage incident may MISS a coincident spoofing campaign hiding inside the verdict-noise) — the diagnostic ladder THIS page documents instructs operators to ALWAYS verify per-source-IP attribution on dkim=temperror rows BEFORE concluding the verdict is purely transient. Read the email-spoofing spoke alongside THIS troubleshooting page when a dkim=none / dkim=pass on wrong-d= / dkim=pass on correct-d=-but-not-sent verdict surfaces in the diagnostic decision-tree and the operator needs the AUTHORITATIVE spoofing-technique attribution classification for incident- response routing.
• Email security glossary — the DKIM-DIAGNOSTIC-LADDER-VOCABULARY- RESOLVES-TO-EMAIL-SECURITY-VOCABULARY- DICTIONARY companion to this DKIM troubleshooting runbook. Where THIS page introduces the per-symptom DKIM-verdict diagnostic ladder (dkim=fail-bh body-hash mismatch / dkim=fail-b signature mismatch / dkim=temperror transient DNS lookup failure / dkim=permerror permanent DNS or syntax failure / dkim=neutral signing- domain bypass / dkim=none unsigned message / dkim=policy receiver-side policy rejection) plus the per-symptom canonical fix-runbook for each verdict, the Email security glossary spoke is the canonical email-security term-dictionary whose entries resolve THIS page's DKIM-failure- mode vocabulary into cross-cluster failure-attribution vocabulary used uniformly across the rest of the help cluster. The DKIM-FAILURE-MODE-RESOLVES- TO-GLOSSARY-VOCABULARY cross-reference establishes FOUR structurally-distinct DKIM-failure-mode term-resolution dimensions: (i) dkim=fail body- hash mismatch vocabulary resolves to glossary forwarder-rewrite / MLM-footer- injection / anti-virus-body-modification dictionary entries — the canonical attribution classes for dkim=fail-bh (forwarder rewrite, mailing-list-manager footer injection, anti-virus banner insertion, content-filter rewrite, MTA-managed encoding change) that THIS page documents as the per-class fix-runbook have glossary entries documenting the canonical cross-cluster vocabulary used uniformly across forwarding-issues / mailing-list / hybrid-topology pages; (ii) dkim=permerror DNS-lookup / DNS-syntax failure vocabulary resolves to glossary <selector>._domainkey. <domain> dictionary entries — the per-class attribution (missing TXT record at selector owner-name, malformed v=DKIM1 sentinel, malformed p=<base64-pubkey> bytes, 255-byte TXT-chunk concatenation bug, key-revocation via p=-empty) that THIS page documents as the per-class fix-runbook have glossary entries resolving to the cross-protocol parallels (parallel DNS-published-PKI publication patterns at SPF / DMARC / MTA-STS / TLS-RPT / DANE-TLSA records); (iii) dkim=temperror transient-DNS-failure vocabulary resolves to glossary DNS-propagation / DNS-resolver-cache / TTL-discipline dictionary entries — the per-class attribution (authoritative nameserver outage, RFC 1035 5-second DNS-resolver timeout, RFC 2308 negative- cache TTL window during selector rollover, anycast nameserver consistency drift) that THIS page documents as the per-class fix-runbook have glossary entries documenting the cross-cluster vocabulary used uniformly across DNS-propagation / DMARC-deployment- checklist / DKIM-key-rotation pages; (iv) dkim=neutral / dkim=policy / dkim=none signing-bypass vocabulary resolves to glossary t=y-testing-flag / receiver-side-policy / unsigned-message dictionary entries — the per- class attribution (publisher's t=y testing-flag in DNS record producing dkim=neutral verdict, receiver-side policy rejection producing dkim=policy verdict, complete-absence-of-DKIM-Signature header producing dkim=none verdict) that THIS page documents as the per-class fix-runbook have glossary entries resolving the cross-cluster publisher-side-vs-receiver-side vocabulary used uniformly across DKIM- best-practices / DKIM-failures-explained / DMARC-records-explained pages. Pair this page (the DKIM troubleshooting diagnostic-ladder runbook) with the Email security glossary spoke (the canonical email-security vocabulary dictionary) when an operator new to DKIM-debugging encounters one of the per-symptom verdicts THIS page documents — the glossary's term-dictionary provides the cross-cluster vocabulary that THIS page's per-verdict diagnostic ladder composes into the broader email-authentication / forwarding / DNS-publication terminology landscape.
• Email deliverability fundamentals — the DKIM-FAILURE-VERDICT-AS- DELIVERABILITY-KPI-CAUSAL-DRIVER companion to this DKIM troubleshooting ladder. The deliverability spoke is the business-outcome quantification layer that connects every per-tag DKIM-verdict diagnostic outcome THIS page documents to the downstream deliverability-KPI degradation cascade at FOUR DKIM-failure-verdict- vs-deliverability-KPI causal-driver dimensions: (i) dkim=fail (body-hash mismatch — most common forwarder-modification failure class) → receiver-side Authentication-Results header emits the dkim=fail verdict the publisher's reputation engines observe as a NEGATIVE sender- reputation signal → inbox- placement-rate decays across the N-day reputation-decay window for the affected sender stream — the deliverability spoke documents how the dkim=fail body- hash verdict THIS page's tag-level diagnostic ladder localises to a per-message canonicalization- modification root cause causes the receiver-side reputation engines (Gmail per-sender reputation score, SmartScreen, M3AAWG-published heuristics) to observe the publisher's outbound mail stream as a load-bearing NEGATIVE sender-reputation signal, which decays the publisher's inbox-placement- rate over the N-day reputation- decay window (14-30 days typical at Gmail / Outlook); the deliverability spoke provides the BUSINESS-OUTCOME complement to THIS page's TECHNICAL-FIX runbook for forwarder-aware DKIM signing canonicalization choice (c=relaxed/relaxed vs c=simple/simple) and the l=-tag length limit-vs- replay-attack trade-off the troubleshooting page documents as the canonical body-hash- mismatch-remediation choices; (ii) dkim=permerror (DNS lookup failure or malformed selector record) → receiver treats verdict as publisher-side mis-deployment signal → bounce-rate and spam-folder-routing spike for the affected sender stream — the deliverability spoke documents how the dkim=permerror verdict THIS page's tag-level diagnostic ladder localises to a publisher-side selector- DNS-publication or key- rotation root cause causes the receiver-side deliverability engines to observe the publisher as a mis-deployed sender, which compounds DMARC-fail at p=quarantine / p=reject into quarantine-folder or outright-bounce routing for the affected sender stream during the permerror window; the deliverability spoke provides the BUSINESS- OUTCOME priority signal for emergency selector- republication / key- rotation pipeline-fix scheduling over routine- maintenance work; (iii) dkim=temperror (transient DNS resolution failure) → receiver-side retry-window behaviour → deferral-rate spike for the affected sender stream → SLA-sensitive transactional-email delivery breach risk — the deliverability spoke documents how the dkim=temperror verdict THIS page's tag-level diagnostic ladder localises to an upstream DNS-resolution flakiness (selector subdomain resolver issues, authoritative-nameserver timeouts, anycast-cluster partial outages) causes the receiver-side deliverability engines to defer the message into their retry-window (typically 1-72 hours at Gmail / Outlook); this produces a SLA-sensitive delivery-delay risk for the publisher's transactional-email pipeline (password-reset codes expire in 5-15 minutes; 2FA codes expire in 30-60 seconds; order-confirmation delivery within 60 seconds is a customer- experience baseline) — the deliverability spoke provides the BUSINESS- OUTCOME consequence chain that justifies investment in DNS resolver redundancy and authoritative- nameserver SLA hygiene upstream of the DKIM- publication pipeline; (iv) dkim=pass + aligned=true post- triage → publisher recovers steady-state inbox-placement-rate and DKIM-aligned positive-sender- reputation-signal- contribution to the DMARC-pass deliverability ceiling — the deliverability spoke documents how the dkim=pass + aligned=true recovery state THIS page's troubleshooting ladder is the operator- side restoration target of materialises at the receiver-side reputation engines as the LOAD-BEARING positive sender- reputation signal that produces the steady- state inbox-placement- rate ceiling for the publisher's outbound mail stream — closing the technical-fix-to- business-outcome feedback loop from THIS page's diagnostic ladder to the publisher's deliverability dashboard. Read the deliverability spoke WITH this DKIM troubleshooting page when scheduling the DKIM-failure incident- response playbook OR when building the executive case for proactive DKIM- publication hygiene — THIS page is the protocol-level tag- diagnostic-and- remediation reference; the deliverability spoke is the business-outcome consequence-chain reference that prioritises the per-verdict remediation work against the publisher's SLA-sensitive sender- stream criticality.
• SPF forwarding issues — the SPF-side view of the same forwarding/mailing-list class that breaks DKIM body hashes.
• TLS-RPT explained — the DKIM-DEBUG-PIPELINE-TRANSPORT-LAYER- DOWNGRADE-EVIDENCE-STREAM-AS-PER-RECEIVER- PER-DAY-AGGREGATE-CONFOUND-EXCLUSION companion reference. Where THIS page documents the symptom-driven DKIM-failure diagnostic ladder (NXDOMAIN selector lookup, TXT-syntax errors, body-hash mismatches, signed-header drift, ESP selector-rotation cutover, canonicalization algorithm choice regressions), the TLS- RPT-explained spoke is the TRANSPORT- LAYER-OBSERVABILITY-PROTOCOL-CHARTER reference documenting the RFC 8460 per-receiver per-day aggregate evidence stream a DKIM-troubleshooting operator structurally consumes to EXCLUDE one major confound class — transport-layer TLS-downgrade as the root cause of an APPARENT DKIM-body-hash mismatch when the actual root cause is a transport- intermediary content-tampering at the cleartext-SMTP boundary. FOUR structurally- distinct DKIM-TROUBLESHOOTING-TLS-RPT- PROTOCOL-CONSUMER dimensions the TLS-RPT charter defines that this DKIM-debug page structurally consumes: (i) per-receiver per-day TLS-pass- rate baseline AS THE CONFOUND-EXCLUSION PRIMITIVE for DKIM body-hash mismatch root-cause analysis — when per-receiver per-day DKIM-fail rate spikes (e.g. 3pp DKIM-fail spike at one receiver only), the DKIM-troubleshooting ladder must EXCLUDE the transport-layer- content-tampering hypothesis before concluding a DKIM-signer-side root cause; the TLS-RPT per-day per-receiver TLS- pass-rate baseline is the canonical confound-exclusion evidence (a TLS-pass- rate stable at 99.9% co-occurring with a 3pp DKIM-fail spike rules OUT the StripTLS-body-tampering hypothesis and focuses the diagnostic ladder on signer- side or canonicalization root causes documented on THIS page); (ii) per-receiver per-day TLS-pass- rate co-degradation AS THE DKIM-FAIL- ROOT-CAUSE-CONFIRMATION SIGNAL for transport-intermediary content-tampering attacks — the converse case: if the per-receiver per-day TLS-pass- rate co-degrades alongside the DKIM-fail rate spike (TLS-pass drops from 99.9% to 92%, DKIM-fail spikes to 3pp at the SAME receiver on the SAME day), the TLS-RPT charter's per-receiver aggregation provides the diagnostic signal that the DKIM-failure root cause is transport-layer — at which point the DKIM-troubleshooting ladder on THIS page is the WRONG diagnostic surface (no canonicalization, selector-rotation, or body-hash root cause exists on the signer side); the operator must instead consult the MTA-STS / DANE / TLS-RPT attacker-defense cluster; (iii) per-day per-receiver certificate-not-trusted / certificate-host-mismatch result-type rows AS THE CANONICALIZATION- DRIFT-VS-MITM-INTERMEDIARY DISTINGUISHER in the DKIM-troubleshooting ladder — the protocol-overview spoke documents the per-receiver result-type vocabulary the TLS-RPT JSON aggregate emits; a DKIM-troubleshooting operator who sees body-hash failures at one specific receiver consults the per-day TLS-RPT result-type rows to distinguish a canonicalization-algorithm-choice drift (relaxed-vs-simple body canonicalization documented on THIS page) from a transport-intermediary MITM with forged CA certificate (canonical signal: certificate-not-trusted or certificate-host-mismatch rows in the per-day TLS-RPT aggregate); the absence of these rows is the operator-side evidence the DKIM-fail root cause is on the signer side and the canonicalization-algorithm-choice diagnostic ladder on THIS page applies; (iv) per-day-per-domain aggregate-cardinality boundary AS THE COMPLIANCE-SAFE OBSERVABILITY- CHANNEL whose privacy guarantees enable DKIM-debug evidence-collection without per-message PII exposure — the protocol-overview spoke documents the RFC 8460 §5 privacy-by-design protocol invariant: TLS-RPT aggregates exclude per-message envelope-sender, message- id, recipient (in contrast to RFC 7489 §7.3 DMARC forensic reports, which embed per-message envelope evidence); for the DKIM-troubleshooting operator operating in a privacy-regulated organisation (GDPR, HIPAA, financial- services data-protection), the per- receiver TLS-RPT aggregate provides a compliance-safe transport-layer observability channel WITHOUT the per- message-PII exposure the DMARC ruf= forensic-report channel imposes — the operator can author transport-layer DKIM-debug evidence-collection procedures referencing TLS-RPT without triggering the per-message-PII Data Protection Impact Assessment regime DMARC forensic-reports require. Read the TLS-RPT-protocol-overview spoke alongside this DKIM- troubleshooting page when the per- receiver per-day DKIM-fail-rate spike diagnostic ladder requires transport- layer-confound exclusion as a load- bearing root-cause-analysis step — the protocol-overview is the CHARTER + DEPLOYMENT-MODEL + PRIVACY-INVARIANT + PER-RECEIVER-AGGREGATION-MODEL canonical reference for the orthogonal observability channel DKIM-troubleshoot- ing structurally consumes.
• DMARC forensic (RUF) reports — the RUF-PER-MESSAGE-DKIM-FAILURE- FORENSIC-DIAGNOSIS-AT-TAG-LEVEL companion to this DKIM-troubleshooting reference. Where THIS page documents the symptom- driven DKIM-failure diagnostic ladder (NXDOMAIN selector lookup, TXT-syntax errors, body-hash mismatches, signed- header tampering, key-rotation gaps), the DMARC-forensic-reports (RUF) spoke is the PER-MESSAGE-FAILURE-SAMPLE channel whose RFC 5965 AFRF payload carries the verbatim DKIM-Signature header THIS troubleshooting page's tag-level diagnostic ladder is the operator-side analysis reference for, at FOUR verbatim-evidence channels: (i) RUF AFRF PAYLOAD CARRIES VERBATIM DKIM-SIGNATURE HEADER FOR TAG-LEVEL DIAGNOSIS — when a receiver emits a RUF sample for a dkim=fail verdict, the per-message AFRF payload (RFC 5965) carries the original message's verbatim DKIM-Signature header bytes (v=1; a=...; c=...; d=...; s=...; h=...; bh=...; b=...), enabling the operator to decode the failing message's per-tag values against THIS page's tag-level diagnostic ladder — the troubleshooting page's "is the s= selector published at the expected <selector>._domainkey.<d> owner-name" question becomes operationally answerable by reading the verbatim s= + d= values out of the RUF sample's DKIM-Signature header; (ii) RUF BODY-HASH-MISMATCH EVIDENCE VS OPERATOR'S SIGNING CANONICALIZATION CHOICE — when a RUF sample reports dkim=fail bodyhash-mismatch, the AFRF payload carries the receiver-computed body hash + the signer-claimed bh= tag + the canonicalization algorithm (c=relaxed/relaxed / c=simple/simple etc.), enabling the operator to attribute the failure to the specific per-hop body-modification (mailing-list footer insertion, ESP unsubscribe-link injection, content-filter rewrite) the troubleshooting page's canonicalization-pair-choice section documents the per-pair survival characteristics of; (iii) RUF PER-FAILURE-SAMPLE ENABLES PER-KEY-ROTATION- EVENT BLAST-RADIUS ASSESSMENT — when an operator rotates a DKIM selector (revoking the old p=<old-key> in favour of the new p=<new-key>), the post-rotation RUF stream surfaces every message still signed with the old selector (typically queued / replayed / forwarded messages) at the per-message-sample granularity, enabling the operator to bound the post-rotation legitimate-mail false-positive blast radius the troubleshooting page's "is your signing infrastructure still emitting the old selector after rotation" question addresses at the failure-class level; (iv) RUF AS GROUND-TRUTH COMPLEMENT TO RUA AGGREGATE WHEN DKIM-FAILURE-RATE TRENDS SPIKE — when an operator observes a sudden spike in the DKIM-fail- rate KPI from the daily RUA aggregate, the RUA's per-source-IP failure-row attribution is statistical / cohort-level evidence; the RUF channel provides the per-message-sample complement that enables the operator to identify the SPECIFIC SIGNING-PATH + SPECIFIC FAILURE-CLASS driving the spike — the troubleshooting page's symptom-to- diagnosis ladder is the cognitive structure the operator runs the RUF AFRF samples through to attribute the spike to a specific tag-level failure (wrong selector publication, body-hash divergence at a specific forwarder, signed-header-tampering at a specific intermediary). Read the DMARC-forensic-reports spoke alongside this DKIM-troubleshooting reference when authoring the post-failure forensic- investigation workflow — the spoke is the canonical RFC 7489 §7.3 / RFC 6591 / RFC 5965 RUF-format reference whose verbatim per-message AFRF payload feeds THIS page's tag-level DKIM-failure diagnostic ladder with concrete per-message evidence.
• How attackers bypass weak DMARC — the DKIM-VERDICT-DIAGNOSTIC-LADDER- AS-PER-ATTACKER-BYPASS-TECHNIQUE- CLASSIFICATION-CONTRACT-AT-FOUR-DKIM- VERDICT-TO-ATTACKER-BYPASS-CLASS- ATTRIBUTION-DIMENSIONS companion to this DKIM-troubleshooting symptom- driven debugging reference. Where THIS page documents the per-symptom DKIM- verdict diagnostic ladder (dkim=fail-bh body-hash-mismatch, dkim=fail-b signature-mismatch, dkim=temperror, dkim=permerror selector-NXDOMAIN, dkim=neutral, dkim=none, dkim=policy) and the canonical dig TXT <selector>._domainkey.<d-domain> multi-resolver fanout symptom-to-action walk, the attacker-bypass spoke is the OFFENSIVE-PERSPECTIVE 22-TECHNIQUE- CATALOGUE companion documenting the structural attribution framework the SOC analyst maps each per-message DKIM- verdict diagnostic outcome onto for incident-response escalation. Concretely, the spoke documents FOUR DKIM-verdict to attacker-bypass-class attribution dimensions: (i) dkim=pass with unaligned d=<cousin-domain> verdict → alignment-evasion class attribution — the troubleshooting page's identify-which- signer-key-the-per-message-b=-tag- was-generated-against step surfaces a cryptographically-valid signature against a cousin/homoglyph/Punycode- bidi domain — the attacker-bypass spoke names this as alignment-evasion- class technique #4 (cousin-domain DKIM signing) and provides the SOC analyst with the canonical adkim=s-strict-mode- publication mitigation and registrar- takedown escalation pathway; (ii) dkim=fail body-hash-mismatch verdict on otherwise-legitimate-source- IP traffic → authentication-evasion class attribution — the troubleshooting page's c=relaxed/relaxed vs c=simple/simple canonicalization-pair symptom-axis pins body-hash-mismatch to a downstream-relay content-modification boundary — the attacker-bypass spoke names this as authentication-evasion- class technique #9 (ARC-chain-stripping / canonicalization-mangle laundering) and provides the SOC analyst with the ARC-trust-anchoring mitigation pathway and the per-hop forwarder-attribution escalation surface; (iii) dkim=pass on subdomain whose published sp=none drifts from parent p=reject → policy-evasion class attribution — the troubleshooting page's identify-which- subdomain-policy-applied step matches the <header_from> subdomain literal against the publisher's sp=-tag publication discipline — the attacker- bypass spoke names this as policy- evasion-class technique #14 (parked- subdomain traversal) and provides the SOC analyst with the per-subdomain per-domain DMARC publication-discipline mitigation pathway; (iv) dkim=permerror NXDOMAIN verdict on legitimate selector with otherwise-stable per-resolver-cache history → infrastructure-evasion class attribution — the troubleshooting page's canonical dig TXT symptom-to-action walk from multiple geographic resolvers surfaces a per-resolver- differential NXDOMAIN response — the attacker-bypass spoke names this as infrastructure-evasion-class technique #19 (DNS-cache-poisoning against receiver authoritative resolver / BGP- hijack against victim authoritative nameservers) and provides the SOC analyst with the per-domain DNSSEC publication-discipline mitigation pathway and the registrar / hosting- provider escalation surface. Read the attacker-bypass spoke ALONGSIDE this DKIM-troubleshooting symptom-driven debugging reference to map every per- message DKIM-verdict diagnostic outcome the symptom-to-action sequence produces onto the specific 22-technique attacker-bypass class for incident- response escalation — the spoke is the AUTHORITATIVE classification-framework the per-symptom DKIM-verdict diagnostic ladder THIS page documents feeds into as input.
• DMARC aggregate reports (RFC 7489 §7.2 XML rua) — the PER-RECEIVER-PER-SOURCE-IP-PER-DAY- RUA-AGGREGATE-XML-AUTH_RESULTS-DKIM=- EVIDENCE-ROW-STREAM-AS-LOAD-BEARING- UPSTREAM-INPUT companion to this DKIM symptom-driven diagnostic-ladder reference. Where THIS page documents the per-symptom diagnostic ladder operators traverse when a per-receiver per-message DKIM verdict (dkim=none / dkim=neutral / dkim=pass / dkim=fail / dkim=policy / dkim=temperror / dkim=permerror per RFC 6376 §3.9) requires per-symptom root-cause attribution, the DMARC-aggregate-reports spoke is the per-receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report record-level UPSTREAM EVIDENCE STREAM the diagnostic-ladder traversal consumes at FOUR aggregate-evidence-to-diagnostic- ladder-coupling dimensions: (i) per-record row/auth_results/dkim/result= attribute as the per-receiver per-source- IP per-day per-message dkim= verdict-string evidence-row producer feeding the per- symptom diagnostic-ladder entry point — the aggregate-reports spoke is the operator-side per-receiver per-source-IP per-day evidence-row surface where the per-receiver per-source-IP per-day dkim= verdict-class distribution is captured as load-bearing input into the diagnostic- ladder per-symptom branch selection; (ii) per-record row/auth_results/dkim/domain= attribute as the per-receiver per-source- IP per-day per-message DKIM-Signature d=-tag-value evidence-row producer feeding the per-symptom diagnostic-ladder selector-attribution branch — the aggregate-reports spoke documents the per-record per-receiver per-source-IP per-day d=-tag evidence-row operators consume to attribute dkim=fail / dkim=permerror verdicts to specific publisher d=-tag values during legitimate-sender third-party-signing- platform onboarding investigations and during publisher-side selector-rotation cutover windows; (iii) per-record per-source-IP per-day temperror-vs- permerror verdict-class distribution as the per-receiver per-day DNS-resolver- health-vs-publisher-publication-discipline attribution signal the diagnostic ladder's branches require — the aggregate- reports spoke is the per-receiver per-day evidence-row surface where the per-symptom DNS-propagation-window-vs-publication- discipline-vs-stale-resolver attribution signal is captured, feeding the diagnostic- ladder's per-receiver per-source-IP per- symptom root-cause attribution decision; (iv) per-record per-source-IP per- day DKIM-verdict-class regression-detection as the operator-side per-day continuous- observability surface the diagnostic ladder's post-mitigation regression- confirmation step consumes — the aggregate-reports spoke documents the per- receiver per-source-IP per-day continuous evidence-row stream operators consume AFTER applying a per-symptom mitigation decision to confirm sustained per-receiver per-source-IP per-day dkim=pass-rate floor AND to detect any post-mitigation per- receiver per-source-IP regression that requires reopening the diagnostic-ladder traversal at a different per-symptom branch. Read the DMARC-aggregate-reports spoke ALONGSIDE this DKIM symptom-driven diagnostic-ladder reference when investigating any per-receiver per-source- IP per-day DKIM-verdict-class evidence-row surge — the spoke is the canonical per- receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report record-level upstream evidence-row stream the per- symptom diagnostic-ladder traversal consumes as the load-bearing per-receiver per-source-IP per-day evidence-attribution surface.
• RFC 6376 §3.9 — Result Reporting — the normative source for every verdict on this page.
• RFC 8601 — Authentication-Results header — the normative source for the Authentication-Results syntax.
• RFC 8301 — Cryptographic Algorithm Update for DKIM — the modern algorithm-policy reference.
• DMARC reporting pipeline — the PER-RUA-AGGREGATE-XML-EVIDENCE- STREAM-AS-LOAD-BEARING-EXTERNAL- DIAGNOSTIC-EVIDENCE-SOURCE-FOR-EVERY- DKIM-TROUBLESHOOTING-WORKFLOW- DOCUMENTED-HERE companion to THIS DKIM troubleshooting reference. Where THIS page documents the per-message DKIM failure-mode diagnostic playbook (Authentication-Results dkim=fail reasons, body-hash mismatch, public-key-lookup failure, selector misconfiguration, signature stripping, canonicalisation misalignment), the DMARC-reporting- pipeline spoke is the EXTERNAL TELEMETRY infrastructure documenting how the rua-aggregate-XML and ruf-AFRF streams produced by receivers feed diagnostic evidence at FOUR DKIM- troubleshooting-workflow-to-rua- evidence dimensions: (i) per- source-IP dkim=fail rua- aggregate-XML row counts — the reporting-pipeline spoke documents how the rua-aggregate-XML per-row policy_evaluated.dkim field surfaces per-source-IP DKIM-fail counts that the operator correlates against the per-source-IP signing- identity inventory THIS page's troubleshooting playbook references; (ii) per-selector dkim=permerror rua- evidence — the reporting- pipeline spoke documents how the rua- aggregate-XML auth_results.dkim block surfaces per-selector permerror verdicts that the operator traces back to the published p=-tag DKIM- public-key-publication-misconfiguration diagnostic THIS page documents; (iii) per-d=-domain DKIM signing- identity discovery rua-evidence — the reporting-pipeline spoke documents how the rua-aggregate-XML auth_results.dkim.domain field reveals unauthorised or forgotten DKIM signing-identities the per-d=-tag attribution workflow THIS page documents depends on; (iv) per-message ruf-AFRF body- modification evidence — the reporting-pipeline spoke documents how the ruf-AFRF per-message forensic-report stream (when emitted) captures per-receiver body- modification evidence the body-hash-mismatch diagnostic THIS page's troubleshooting playbook depends on. Read THIS page when DIAGNOSING a per-message DKIM failure; read the DMARC-reporting- pipeline spoke when ARCHITECTING the rua / ruf evidence-stream infrastructure the DKIM-troubleshooting playbook THIS page documents draws on.
• Email Header Analyzer — paste a failing message and the parser surfaces every diagnostic surface referenced on this page.
• Domain Security Checker — validates the published selector TXT record structurally.
• DMARC myths and misconceptions debunked — the canonical educational myth-busting reference whose 18 named DMARC misconceptions are empirically debunked against the per-symptom DKIM-verdict diagnostic ladder THIS troubleshooting page documents at four DKIM-symptom-to- DMARC-myth resolution dimensions: (i) the dkim=pass with-aligned=false ladder rung is the canonical empirical counterexample to the "dkim=pass means the message is legitimate" misconception — receiver Authentication-Results emit dkim=pass for any cryptographically-valid DKIM signature regardless of whether the d=-tag aligns with the RFC 5322.From organisational domain, and the per-symptom playbook traces the diagnostic ladder through to the canonical third-party-ESP d=-tag-drift defect- class the myth catalogue explicitly debunks; (ii) the dkim=permerror NXDOMAIN selector-lookup-failure ladder rung is the canonical empirical counterexample to the "DKIM signing is set-and-forget once the key is published" misconception — receiver-side permerror verdicts collapse the per-message DKIM-aligned-pass rate whenever the selector TXT record is rotated out of zone, deleted by accident during a DNS migration, or never re-synchronised after an ESP onboarding; (iii) the dkim=fail body-hash- mismatch + canonicalisation-mode ladder rung is the canonical empirical counterexample to the "dkim=fail always means the message was tampered with in transit" misconception — the per-symptom diagnostic ladder traces body-hash-mismatch verdicts to legitimate forwarder whitespace-folding, canonicalisation-mode misalignment (c=simple/simple vs c=relaxed/relaxed), and intermediary list-server Subject-prefix injection — none of which are tampering in the adversarial sense the myth implies; and (iv) the per-forwarder DKIM-Signature header-stripping + ARC-chain-rescue ladder rung is the canonical empirical counterexample to the "DKIM works identically across all forwarders" misconception — per-forwarder DKIM coverage variance ranges from signature-preserved (transparent relay) through signature-broken-by-modification (list-server footer injection) to signature-rescued-by-ARC (forwarder-sealed ARC chain) the myth catalogue's forwarding section explicitly debunks. Read the myths-and-misconceptions spoke ALONGSIDE this DKIM-troubleshooting playbook whenever the operator scopes a per-publisher operator- education curriculum — the diagnostic ladder THIS page documents IS the empirical evidence-chain that grounds every DKIM-subset entry in the myth catalogue against receiver-side Authentication-Results reality.
• DMARC monitoring discipline — where THIS page documents the symptom-to-action diagnostic ladder the operator executes ONCE a per-message dkim=fail or dkim=permerror verdict has been observed, the DMARC-monitoring spoke documents the standing operational discipline that PRODUCES the alert in the first place — the per-publisher per-domain per-receiver per-day DKIM-pass-rate KPI floor + per- source-IP DKIM-fail-rate alert threshold + post-key-rotation regression-detection signal + per-reporter coverage-drift surface that aggregate-XML rua reports materially expose. FOUR structurally-distinct MONITORING- CADENCE-VS-POINT-IN-TIME-DIAGNOSTIC coupling dimensions the DMARC-monitoring spoke operationally documents: (i) per-publisher per-domain DKIM-pass-rate KPI floor across all receivers as load-bearing standing observability input that surfaces the trigger condition this troubleshooting ladder responds to — the rua-aggregate-XML row/auth_results/dkim/result=fail rate trending above the per-domain alert-threshold floor (e.g., 5% per-day) is the observable signal that triggers operator entry into the per-symptom diagnostic ladder THIS page documents; (ii) per-source-IP DKIM-fail-rate alert threshold as load-bearing narrowed-scope diagnostic-ladder- entry-point — the DMARC-monitoring spoke's per-source- IP DKIM-fail KPI surfacing a previously-aligned legitimate sender now producing dkim=fail at a single receiver narrows the diagnostic ladder THIS page documents to a per-source-IP per-receiver per- forwarder scope; (iii) post- key-rotation regression-detection as load-bearing time-bounded diagnostic ladder activation criterion — the DMARC- monitoring spoke's post-rotation regression-detection signal (per- publisher per-domain dkim=pass rate dropping after a planned <new-selector>._domainkey TXT publication) is the load- bearing post-change activation trigger for the rotation-specific diagnostic-ladder branches (deprecated-selector still in DNS but signer migrated, new selector not yet propagated to recursive resolvers, deprecated-key still published but stripped at signer) THIS page documents; (iv) per-reporter coverage drift surface as load-bearing per- receiver scope-narrowing diagnostic input — the DMARC- monitoring spoke's per-reporter coverage-drift KPI (a receiver that WAS sending rua reports stops sending, or a NEW receiver appears in the rua report stream) narrows the diagnostic ladder THIS page documents to per-receiver scope before per-source-IP scope. Read the DMARC-monitoring spoke ALONGSIDE this DKIM-troubleshooting playbook whenever the operator scopes a per-publisher per-domain DKIM-operational-discipline — the DKIM-troubleshooting diagnostic ladder THIS page documents is the RESPONSE primitive; the DMARC- monitoring observability discipline is the DETECTION primitive that triggers it.
• DMARC for Google Workspace — the WORKSPACE-TENANT-PER-SELECTOR- DKIM-FAILURE-DIAGNOSTIC-PLAYBOOK companion to this per-deployment- topology DKIM-troubleshooting reference. Where THIS page documents the symptom-driven per-message DKIM verdict-failure-mode diagnostic ladder (per-selector publication errors, per-key rotation regressions, body- hash canonicalization breakage, h= tag drift, third-party-signer alignment ambiguity), the Workspace-deployment spoke is the WORKSPACE-TENANT EXECUTION- DISCIPLINE COMPANION documenting how each per-symptom diagnostic step on this page instantiates concretely on Google Workspace at FOUR per-Workspace- tenant-Admin-Console-configuration-vs- DKIM-troubleshooting-diagnostic-step dimensions: (i) per-Workspace- tenant Admin Console DKIM key generation is the per-tenant per- selector publication-discipline instantiation — the Workspace- deployment spoke documents how the per-tenant Admin Console DKIM key generation UI emits the per-selector TXT record (google._domainkey. <domain>) THIS page documents at the per-selector publication-discipline diagnostic step (selector typo, propagation lag, registrar publication failure); (ii) per-Workspace-tenant google selector publication discipline is the per-tenant per-domain DKIM-publication instantiation — the Workspace- deployment spoke documents how the per-tenant per-domain authoritative DNS-zone google selector publication feeds the per-receiver DKIM-key-lookup diagnostic step THIS page documents at the per-selector public-key-record lookup tier; (iii) per- Workspace-tenant 2048-bit key-size enforcement at the Workspace-managed signer boundary is the per-tenant RFC 8301 cryptographic-algorithm-update compliance instantiation — the Workspace-deployment spoke documents how the per-tenant Workspace- managed signer enforces RFC 8301 2048- bit minimum at the per-selector key generation tier the per-receiver per-message DKIM cryptographic-algorithm verdict THIS page documents depends on; and (iv) per-Workspace-tenant per-domain DKIM-signing toggle is the per-tenant per-domain DKIM-signer activation instantiation — the Workspace-deployment spoke documents how the per-tenant per-domain DKIM-signing toggle in Admin Console determines whether per-message DKIM signing actually occurs on outbound Workspace traffic, which is the upstream necessary precondition the per-message dkim=none diagnostic step THIS page documents distinguishes from per-receiver lookup failure or per- selector publication failure. Read the Workspace-deployment spoke ALONGSIDE this DKIM-troubleshooting playbook whenever the per-tenant Workspace operator scopes a per-message DKIM verdict-failure root-cause attribution — the per-symptom diagnostic ladder THIS page documents is the receiver- side DIAGNOSTIC primitive; the per- Workspace-tenant Admin Console configuration is the publisher-side REMEDIATION-EXECUTION primitive that closes the per-symptom diagnostic loop.
• DMARC for Microsoft 365 — the M365-TENANT-PER-SELECTOR-DKIM- FAILURE-DIAGNOSTIC-PLAYBOOK companion to this per-deployment-topology DKIM- troubleshooting reference. Where THIS page documents the symptom-driven per- message DKIM verdict-failure-mode diagnostic ladder (per-selector publication errors, per-key rotation regressions, body-hash canonicalization breakage, h= tag drift, third-party- signer alignment ambiguity), the M365- deployment spoke is the M365-TENANT EXECUTION-DISCIPLINE COMPANION documenting how each per-symptom diagnostic step on this page instantiates concretely on Microsoft 365 at FOUR per-M365-tenant-Exchange- Admin-Center-configuration-vs-DKIM- troubleshooting-diagnostic-step dimensions: (i) per-M365- tenant Exchange Admin Center DKIM key enable/disable is the per-tenant per- accepted-domain DKIM-signer-activation instantiation — the M365- deployment spoke documents how the per-tenant Exchange Admin Center DKIM key enable/disable UI determines whether per-message DKIM signing actually occurs on outbound M365 traffic, which is the upstream necessary precondition the per-message dkim=none diagnostic step THIS page documents distinguishes from per-receiver lookup failure or per-selector publication failure; (ii) per-M365-tenant selector1/ selector2 publication discipline is the per-tenant per-selector dual-CNAME publication instantiation — the M365- deployment spoke documents how the per-tenant per-accepted-domain authoritative DNS-zone selector1._domainkey. <domain> + selector2._domainkey. <domain> CNAME-chain publication discipline feeds the per- receiver DKIM-key-lookup diagnostic step THIS page documents at the per- selector public-key-record lookup tier — the Microsoft-managed CNAME- target-record is the structural Microsoft-managed dual-CNAME-resolution primitive the receiver follows during per-message verification; (iii) per-M365-tenant 2048-bit key- rotation discipline at the Microsoft- managed signer boundary is the per- tenant RFC 8301 cryptographic- algorithm-update compliance instantiation — the M365- deployment spoke documents how the per-tenant Microsoft-managed signer enforces RFC 8301 2048-bit minimum at the per-selector key generation tier the per-receiver per-message DKIM cryptographic-algorithm verdict THIS page documents depends on (Microsoft rotates 2048-bit keys server-side without per-tenant operator intervention); and (iv) per- M365-tenant per-accepted-domain DKIM-signing toggle is the per-tenant per-accepted-domain DKIM-coverage instantiation — the M365- deployment spoke documents how the per-tenant per-accepted-domain DKIM toggle determines whether outbound messages from each accepted domain actually receive DKIM signing, which the per-receiver per-message DKIM verdict THIS page documents as the per-domain DKIM-coverage prerequisite for dkim=pass evaluation. Read the M365-deployment spoke ALONGSIDE this DKIM-troubleshooting playbook whenever the per-tenant M365 operator scopes a per-message DKIM verdict-failure root-cause attribution — the per-symptom diagnostic ladder THIS page documents is the receiver- side DIAGNOSTIC primitive; the per- M365-tenant Exchange Admin Center configuration is the publisher-side REMEDIATION-EXECUTION primitive that closes the per-symptom diagnostic loop.
• DMARC policy rollout — the PER-SYMPTOM-DKIM-DIAGNOSTIC- LADDER-AS-LOAD-BEARING-PREREQUISITE-OF- PER-PUBLISHER-DMARC-RAMP-STEP-TIGHTENING companion to this per-symptom DKIM- diagnostic-ladder reference. Where THIS page documents the per-symptom diagnose- and-fix sequence keyed off the per-message dkim=fail / dkim=neutral / dkim=temperror / dkim=permerror / dkim=policy verdicts (DNS- side lookup ladder, header-side inspection ladder, publisher-side configuration ladder, third-party validator ladder), the policy-rollout spoke is the per-publisher per-domain DMARC enforcement-progression discipline whose every p=none → p=quarantine → p=reject ramp-step tightening commit is gated by the per-symptom DKIM- diagnostic-ladder closure-state THIS page documents at FOUR per-diagnostic-ladder- step-vs-DMARC-policy-ramp-step coupling dimensions: (i) per-symptom DKIM- diagnostic-ladder closure-state is the per-publisher per-domain operational prerequisite of the p=none observation-window opening — the policy-rollout spoke documents how the p=none observation-window opening (the first ramp-step in every per-publisher per-domain DMARC deployment) is preceded by a per-publisher per-domain per-selector DKIM-publication green-state baseline whose per-symptom diagnostic-ladder closure-state THIS page documents is the load-bearing verification-instrument — every per- symptom dkim=permerror (DNS-side lookup-failure ladder), dkim=neutral (publisher-side publication-defect ladder), and dkim=fail (signature- verification ladder) must drive to root- cause-resolution BEFORE the per-publisher operator commits the p=none observation-window opening; (ii) per-symptom DKIM-diagnostic-ladder closure-rate is the load-bearing gating input of the p=none → p=quarantine ramp-step commit — the policy-rollout spoke documents how the p=none → p=quarantine ramp-step commit decision reads the per-publisher per-domain per-symptom DKIM-diagnostic- ladder closure-rate THIS page documents as the load-bearing residual-failure- rate indicator — the per-publisher per- domain residual-failure rate across all per-symptom diagnostic-ladder branches must trend below the per-publisher per- domain false-positive-loss tolerance BEFORE the per-publisher operator can commit the p=quarantine tightening; (iii) per-symptom DKIM-diagnostic-ladder publisher-side- configuration ladder closure is the load-bearing publication-discipline- regression-resilience input of the p=quarantine → p=reject ramp-step commit — the policy-rollout spoke documents how the p=quarantine → p=reject ramp-step commit decision reads the per-publisher per- domain publisher-side-configuration ladder closure-state THIS page documents as the load-bearing publication- discipline-regression-resilience indicator — the per-publisher per- domain per-selector publication- configuration discipline must demonstrate per-publisher per-domain per-rotation- event green-state-baseline survival BEFORE the per-publisher operator can commit the p=reject tightening without per-rotation per- message legitimate-message-loss regression; and (iv) per-symptom DKIM-diagnostic-ladder is the load- bearing per-publisher per-domain ramp- step rollback-decision instrument when observed verdict-distribution regresses post-commit — the policy- rollout spoke documents how every per- publisher per-domain ramp-step tightening commit is followed by a per-publisher per-domain rolling-window per-message DKIM-verdict-distribution observation whose per-symptom diagnostic-ladder THIS page documents is the load-bearing per- publisher per-domain rollback-decision instrument — a post-commit per-symptom DKIM-verdict-distribution regression across the rolling-window forces the per-publisher operator into the per- symptom diagnostic-ladder THIS page documents to root-cause-attribute the regression BEFORE the per-publisher operator commits the per-publisher per- domain ramp-step rollback to the prior policy mode.
• DMARC for cPanel / WHM shared-hosting deployments — the per-cPanel-account per-customer- domain DMARC publication workflow at the WHM Email Deliverability auto-generation flow whose per-account DKIM-signing discipline is built on cPanel's Exim outbound MTA auto-generating per-domain DKIM key-pairs and publishing the per-domain default._domainkey TXT record at the cPanel DNS Zone Editor. When a cPanel-hosted publisher's per- message DKIM verdict trips Symptom Cluster A (selector typo / missing key) OR Symptom Cluster B (key-rotation gap between primary and rotation selectors) OR Symptom Cluster D (body-hash mismatch from cPanel Exim re-writing message headers in transit), read THIS DKIM- troubleshooting playbook alongside the cPanel deployment guide so the per- account diagnostic ladder accounts for the WHM-Email-Deliverability auto- generation profile and the cPanel-Exim per-account-MTA shared-outbound-IP operational discipline this page's cross-symptom diagnostic framework applies at the per-cPanel-account boundary.
• MTA-STS policy-file syntax — the PER-PUBLISHER-PER-DOMAIN- RFC-8461-MTA-STS-POLICY-FILE-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- PEER-TRANSPORT-LAYER-PUBLICATION-DISCIPLINE- TROUBLESHOOTING companion to this DKIM- troubleshooting playbook. Where THIS page documents the per-message DKIM-failure-mode symptom-cluster diagnostic ladders at the application layer (per-symptom-cluster diagnostic decision trees for body-hash- mismatch / signature-verification-failure / public-key-absence / canonicalization- mismatch / forwarder-modified-body / DKIM- Signature-header-tampered failure-mode classes), the MTA-STS-policy-syntax spoke is the peer per-publisher per-domain RFC 8461 transport-layer policy-file publication-discipline troubleshooting reference whose per-policy-file byte- grammar correctness contract is the upstream determinant of per-receiver per- session per-MX hop policy-fetch-and- evaluation failure-mode rows at FOUR per- publication-discipline-troubleshooting coupling dimensions: (i) per- publisher per-domain peer per-publication- discipline failure-mode catalogue parallelism — the per- message DKIM-failure-mode catalogue THIS page documents the per-symptom-cluster diagnostic decision trees of pairs operationally with the per-receiver per- session per-MX hop MTA-STS-policy-fetch- and-evaluation failure-mode catalogue (sts-policy-fetch-error from HTTPS timeout or DNS-resolution failure, sts- policy-invalid from policy-file byte- grammar violation, sts-webpki-invalid from per-MX certificate trust-chain failure) the MTA-STS-policy-syntax spoke documents the byte-grammar upstream of, and the per-publisher per-domain operator-side per-layer failure-mode- diagnostic discipline runs against BOTH per-protocol-layer failure-mode catalogues in parallel; (ii) per-publisher per-domain policy-file-byte-grammar- correctness as load-bearing upstream determinant of per-receiver per-session failure-mode-row emission — the per-publisher per-domain DKIM TXT-RR public-key publication byte- grammar correctness determines the per- message DKIM-permerror row emission in the DMARC aggregate rua stream THIS page documents the diagnostic ladder for, the per-publisher per-domain MTA-STS policy- file byte-grammar correctness the MTA- STS-policy-syntax spoke documents determines the per-receiver per-session sts-policy-invalid / validation-failure failure-mode row emission in the TLS-RPT failure-details aggregation stream, and the per-publisher per-domain operator- side publication-correctness- troubleshooting discipline is the load- bearing per-layer publication-correctness- diagnostic rhythm BOTH protocols share at the receiver-side failure-mode-row emission boundary; (iii) per- publisher per-domain two-leaf publication- cadence-coordination troubleshooting parallelism — the per- publisher per-domain DKIM key-rotation primary-secondary selector-coexistence two-record-publication coordination discipline THIS page documents the diagnostic ladder for pairs operationally with the per-publisher per-domain MTA- STS TXT-RR-policy-version-pointer-and- HTTPS-served-policy-file-body two-leaf publication-cadence coordination discipline the MTA-STS-policy-syntax spoke documents (the TXT-RR id=-value-bump-vs-policy- file-body-rewrite cadence-pairing contract), and the per-publisher per- domain operator-side per-layer two-leaf publication-coordination-troubleshooting discipline runs against BOTH per- protocol-layer two-leaf coordination failure-mode catalogues in parallel; (iv) per-publisher per-domain cross-layer DKIM-and-MTA-STS-and-TLS-RPT publication-discipline troubleshooting- stream co-ingestion — the per-publisher per-domain operator- side cross-layer authentication-and- encryption troubleshooting-stream that ingests BOTH the per-publisher per- domain DKIM-failure-mode telemetry stream THIS page documents the diagnostic ladder for AND the per- publisher per-domain MTA-STS-policy- publication-failure-mode telemetry stream the MTA-STS-policy-syntax spoke documents the publication-discipline upstream of is the load-bearing per- publisher per-domain cross-layer publication-discipline troubleshooting stream every per-publisher per-domain DMARC-deployment programme requires for per-publisher per-domain complete cross-layer publication-discipline- failure-mode diagnostic coverage. Read THIS page when WORKING per-message DKIM-failure-mode symptom-cluster diagnostic ladders; read the MTA-STS- policy-syntax spoke when CO-AUTHORING the per-publisher per-domain peer transport-layer policy-file publication- discipline troubleshooting discipline whose per-policy-file byte-grammar correctness contract is the upstream determinant of per-receiver per-session per-MX hop policy-fetch-and-evaluation failure-mode rows the per-publisher per-domain operator-side cross-layer publication-discipline troubleshooting stream ingests in parallel with the DKIM-failure-mode telemetry THIS page documents the diagnostic ladder for.
• SPF for Microsoft 365 — the PER-PUBLISHER-PER-MICROSOFT- 365-TENANT-SPF-PUBLICATION-DISCIPLINE-AS- LOAD-BEARING-PEER-PROTOCOL-LAYER-PER- OPERATOR-PER-TENANT-TROUBLESHOOTING- DISCIPLINE companion to this DKIM- troubleshooting diagnostic-ladder reference. Where THIS page documents the per-publisher per-selector DKIM-failure- mode diagnostic ladder at the per-message application-layer authenticity-binding (per-selector public-key publication- discipline troubleshooting, per-selector rotation-misstep troubleshooting, per- message body-hash mismatch troubleshooting, per-message canonicalization-mode troubleshooting), the SPF-for-Microsoft- 365 spoke is the peer per-publisher per- tenant per-Microsoft-365-operator SPF publication discipline whose per-M365- tenant SPF publication discipline (canonical v=spf1 include:spf.protection.outlook.com -all SPF-record template, per-tenant supplemental third-party-ESP include- statement composition, per-tenant cumulative 10-lookup-limit budget arithmetic, per-tenant M365 admin-portal zone-editor commit cadence) produces the per-message envelope-MAIL-FROM SPF-failure- mode catalogue (per-message permerror from cumulative include: 10- lookup-limit breach, per-message temperror from upstream M365-and-third-party-ESP SPF-publication unreliable-resolution dependency, per-message softfail from ~all mechanism-default, per-message hardfail from -all mechanism-default) that pairs operationally with the per-publisher per-selector DKIM- failure-mode diagnostic ladder THIS page documents at FOUR per-troubleshooting- discipline coupling dimensions: (i) peer per-protocol-layer per- operator per-tenant authentication-failure- mode-catalogue troubleshooting-discipline parallelism — the per- publisher per-selector DKIM-failure-mode diagnostic ladder THIS page documents at the application-layer authenticity-binding pairs operationally with the per-publisher per-M365-tenant SPF-failure-mode catalogue the SPF-for-Microsoft-365 spoke documents the per-tenant per-operator publication- rationale of — together the per-protocol- layer per-operator per-tenant authentication- failure-mode troubleshooting disciplines compose the per-publisher per-tenant per- operator complete cross-protocol-pillar authentication-failure-investigation posture every per-publisher per-tenant per- operator DMARC-deployment programme requires; (ii) per-publisher per- M365-tenant per-operator cross-protocol- pillar troubleshooting-attribution parallelism — the per- publisher per-selector DKIM-failure-mode diagnostic ladder THIS page documents attributes per-message authentication failure to per-selector key-discipline defects at the per-message application- layer; the SPF-for-Microsoft-365 spoke attributes per-message authentication failure to per-publisher per-M365-tenant SPF-publication-discipline defects (per- tenant cumulative include:spf.protection.outlook.com+supplemental-ESP-include 10-lookup-limit breach, per-tenant upstream M365-and-third-party-ESP SPF- publication unreliable-resolution dependency, per-tenant supplemental include-statement drift) at the per- message envelope-MAIL-FROM-layer — together the per-protocol-layer attribution disciplines compose the per-message complete authentication-failure-mode root- cause attribution that the per-publisher per-M365-tenant per-operator DMARC-failure investigation requires; (iii) per- publisher per-M365-tenant per-operator cross-protocol-pillar failure-mode co- ingestion as complete authentication- failure-investigation posture — the per-publisher per-selector DKIM-failure-mode diagnostic ladder THIS page documents is the per-application- layer-authenticity-binding failure-mode- investigation stream whose peer per- envelope-MAIL-FROM-layer failure-mode- investigation stream is the per-publisher per-M365-tenant per-operator SPF-failure- mode catalogue the SPF-for-Microsoft-365 spoke documents the per-tenant per- operator publication-rationale of — together the per-protocol-layer failure- mode-investigation streams compose the per-publisher per-tenant per-operator complete cross-protocol-pillar authentication-failure-investigation posture every per-publisher per-tenant per- operator DMARC-deployment programme requires for complete per-message failure- mode root-cause attribution; (iv) per-publisher per-M365-tenant per- operator operator-side cross-protocol- pillar troubleshooting-discipline coordination — the per- publisher per-selector DKIM-failure-mode diagnostic ladder THIS page documents is composed BY the per-selector signing- discipline / per-selector key-rotation- cadence / per-selector cryptographic- trust-anchor-publication operator-side discipline; the SPF-for-Microsoft-365 spoke documents the per-publisher per- M365-tenant per-operator SPF-publication- discipline operator-side troubleshooting (per-tenant Admin-Portal cumulative- include-statement audit, per-tenant Connectors-and-Hybrid-Migration complementary-supplemental-include- statement audit, per-tenant per-domain SPF-record zone-editor commit-step verification), and the per-publisher per- M365-tenant per-operator cross-protocol- pillar troubleshooting-discipline coordination is the load-bearing per- publisher per-tenant per-operator authentication-failure-mode prevention rhythm BOTH protocols share at the per- publisher per-M365-tenant per-operator cross-protocol-pillar troubleshooting- discipline-composition boundary. Read THIS page when DIAGNOSING per-publisher per- selector DKIM-failure-mode root causes; read the SPF-for-Microsoft-365 spoke when DIAGNOSING per-publisher per-M365-tenant per-domain SPF-publication-discipline defects whose per-tenant per-operator SPF-failure-mode catalogue pairs operationally with the per-publisher per- selector DKIM-failure-mode diagnostic ladder THIS page documents at the per- publisher per-M365-tenant per-operator cross-protocol-pillar troubleshooting- discipline-composition boundary.
• DMARC for transactional email — the per-publisher per-domain TRANSACTIONAL-EMAIL-DEPLOYMENT companion to this DKIM-troubleshooting diagnostic-ladder reference. Where THIS page documents the per-publisher per- selector DKIM-failure-mode diagnostic ladder at the per-message application- layer authenticity-binding (per-selector public-key publication-discipline troubleshooting, per-selector rotation- misstep troubleshooting, per-message body-hash mismatch troubleshooting, per- message canonicalization-mode troubleshooting), the DMARC-for- transactional-email spoke documents the per-publisher per-domain high-volume transactional-sender DMARC deployment discipline (per-ESP per-publisher per- domain SendGrid / Mailgun / Postmark / Amazon SES / SparkPost subdomain- delegation pattern, per-ESP DKIM-key- provisioning-with-publisher-d-tag configuration, per-publisher per-domain per-ESP CNAME delegation for selector key publication, per-publisher per- domain DMARC pct= ramp-up for transactional traffic). The transactional-email spoke is the OPERATIONAL DEPLOYMENT companion that relies on the per-selector DKIM- troubleshooting diagnostic ladder THIS page documents: a per-publisher per- transactional-sender DKIM-failure regression (the per-ESP CNAME- delegation drift, the per-ESP rotated- key publication mis-sync, the per- message body-hash mismatch from per-ESP transactional-template rendering changes) cascades through the per-message DKIM-verdict regression into per-message DMARC-verdict regression into per-recipient transactional-email delivery suppression — the highest- severity transactional-sender incident class because per-recipient transactional messages (password reset, two-factor codes, order confirmations, invoices) are time-sensitive and a delivery- suppression incident produces immediate per-recipient user-experience regression and per-publisher per-domain support- ticket volume spike. Read THIS page when DIAGNOSING per-publisher per- selector DKIM-failure-mode root causes on a per-publisher per-domain transactional-sender deployment; read the DMARC-for-transactional-email spoke when AUTHORING the per-publisher per-domain per-ESP transactional-sender DMARC deployment whose per-message DKIM-verdict green-state baseline is the load-bearing per-recipient transactional-email delivery prerequisite the diagnostic-ladder THIS page documents protects.
• 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 as discovery-baseline, p=quarantine spam-folder tier as preview-enforcement, and p=reject SMTP-time- rejection tier as production- enforcement; 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 structurally GATED by the per-publisher per- selector DKIM-verdict-diagnostic- ladder closure-state THIS page documents. The composition operates through FOUR per-DKIM-diagnostic- ladder-closure-state vs per-DMARC- policy-tier-ramp-gating coupling dimensions every per-publisher per- domain operator must reason about when promoting per-publisher per- domain DMARC enforcement: (i) per- publisher per-domain DKIM-diagnostic- ladder closure-state at p=none-tier baseline — per-publisher per-domain DKIM- verdict-failure discovery is the canonical use-case for the p=none monitoring-mode tier; the per-publisher per-domain operator MUST drive per-receiver per-day RUA-aggregate-report dkim=fail / dkim=permerror / dkim=temperror rate to the per-publisher per-domain green- state baseline using the DKIM- troubleshooting diagnostic ladder THIS page documents BEFORE proposing the p=none → p=quarantine ramp commit; (ii) per-publisher per- domain DKIM-diagnostic-ladder closure-state at p=quarantine-tier preview-enforcement — per-publisher per-domain p=quarantine-tier publication MAY proceed only when per-publisher per-day DKIM-aligned- pass-rate floor is sustainably above the per-publisher per-domain false-quarantine-tolerance ceiling; the per-publisher per-domain operator MUST re-run the DKIM- troubleshooting diagnostic ladder on every per-receiver per-day DKIM-aligned-pass-rate REGRESSION BEFORE proposing the p=quarantine → p=reject ramp commit; (iii) per-publisher per-domain DKIM-diagnostic-ladder closure- state at p=reject-tier production-enforcement — per- publisher per-domain p=reject-tier publication is the per-publisher per-domain DKIM-verdict closure- state production-endpoint; per- publisher per-day DKIM-aligned- pass-rate REGRESSION at the p=reject-tier is a per-recipient per-message SMTP- time-rejection production-incident the per-publisher per-domain operator MUST close via the DKIM- troubleshooting diagnostic ladder on EMERGENCY priority; (iv) per- publisher per-domain pct=-tag percentage- gradual-enforcement ramp as DKIM- diagnostic-ladder-driven progression — per-publisher per- domain pct=10 → 25 → 50 → 100 stepwise enforcement- percentage advancement is gated per-step by per-publisher per-day DKIM-aligned-pass-rate-after- enforcement-step measurement; the per-publisher per-domain operator applies the DKIM-troubleshooting diagnostic ladder THIS page documents on every per-step DKIM-aligned-pass-rate regression-investigation BEFORE advancing to the next pct=-step. Read THIS page when DIAGNOSING per- publisher per-selector DKIM- verdict-failure root-causes; 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-policy-tier TIGHTENING decision IS structurally GATED by the per- publisher per-selector DKIM- verdict-diagnostic-ladder closure-state the DKIM- troubleshooting diagnostic ladder THIS page documents drives to the per-publisher per-domain green-state baseline.
• Phishing protection — the PER-DKIM-VERDICT-DIAGNOSTIC-CLOSURE- DRIVES-PER-MESSAGE-ANTI-PHISHING-EVALUATION- FIDELITY companion to THIS DKIM troubleshooting diagnostic-ladder reference. Where THIS page documents the per-publisher per-selector DKIM-verdict-failure symptom-driven diagnostic ladder (selector DNS-publication NXDOMAIN, key-rotation atomic-cutover regression, body-hash canonicalization mismatch, header-set h= drift, third-party-signer alignment ambiguity) operators close on the publisher side to drive per-selector DKIM- aligned-pass-rate back to green-state, the phishing-protection spoke documents the per-receiver per-message anti-phishing defence-stack (SPF + DKIM + DMARC composite evaluator at the receiver-side authentication boundary; lookalike-domain and IDN-homograph detection at the per-recipient inbox-list display layer; OAuth-consent-abuse and MFA- push-bombing mitigation at the per-tenant per-account identity-protection boundary) at FOUR per-DKIM-verdict-vs-anti-phishing-control coupling dimensions: (i) per-publisher per-selector dkim=pass verdict production AS load-bearing per-receiver per-message anti-phishing sender-authenticity positive-evidence input — the per- receiver per-message anti-phishing evaluator consumes the per-message dkim=pass verdict as the cryptographic-binding-based authentication-positive-evidence input differentiating per-publisher legitimate signed mail from per-attacker spoofed unsigned mail at the per-receiver per-message spoofing-vs-legitimate disposition-decision boundary; the per-publisher per-selector DKIM-verdict-failure closure THIS page documents drives the per-publisher per-domain DKIM-aligned-pass-rate floor that the per-receiver per-message anti-phishing evaluator's per-publisher per-domain sender- reputation-score consumes as the per-publisher per-domain authentication- discipline-floor signal; (ii) per- publisher per-selector dkim=fail verdict diagnosis AS spoofing-vs-legitimate- breakage disambiguation discipline — the per-receiver per-message anti-phishing evaluator cannot distinguish per-attacker spoofing attempts (forged From: header without valid DKIM signature, replayed cryptographic signature against attacker- chosen recipients per RFC 6376 §6.2.2) from per-publisher legitimate-but-broken DKIM signing pipelines (forwarder body-modification breakage, selector rotation incomplete) using the dkim=fail verdict alone; the per-publisher per-selector DKIM-fail diagnostic ladder THIS page documents is the canonical operator-side reference for the spoofing-vs- legitimate-breakage disambiguation that determines whether the per-receiver per- message dkim=fail verdict feeds the per-publisher per-domain phishing defence-stack as attacker-side spoofing evidence or as publisher-side pipeline-breakage false-positive evidence; (iii) per- publisher per-selector dkim=permerror verdict diagnosis AS per-publisher per-domain phishing-attack-surface elevation signal — the per-receiver per- message anti-phishing evaluator interprets a sustained per-publisher per-selector dkim=permerror verdict (selector DNS-publication NXDOMAIN, malformed selector TXT-RR) as a per-publisher per-domain authentication-discipline-floor regression that elevates the per-publisher per-domain phishing-attack-surface (per-attacker exploit window for spoofed messages claiming the per-publisher From-domain identity); the per- publisher per-selector permerror diagnostic closure THIS page documents is the canonical operator-side phishing-attack-surface compression discipline at the per-publisher per-domain DKIM-selector publication boundary; (iv) per-publisher per-selector dkim=temperror verdict diagnosis AS per-publisher per-domain anti-phishing evaluation-deferral-window discipline — the per-receiver per-message anti-phishing evaluator defers per-publisher per-message sender-authenticity verdicts during sustained per-publisher per-selector dkim=temperror windows (authoritative-nameserver timeout, anycast- cluster partial outage); the per-publisher per-selector temperror diagnostic closure THIS page documents is the canonical operator-side per-publisher per-domain anti-phishing evaluation-fidelity restoration discipline at the per-publisher per-selector DNS-publication-availability boundary. Read THIS page when CLOSING per-publisher per- selector DKIM-verdict-failure diagnostic ladders; read the phishing-protection spoke when UNDERSTANDING how the per-publisher per- selector DKIM-verdict-failure-closure-state the DKIM-troubleshooting diagnostic ladder THIS page documents drives to the per- publisher per-domain green-state baseline IS the load-bearing input that the per-receiver per-message anti-phishing defence-stack consumes for per-publisher per-domain sender- authenticity-attribution disambiguation at the per-receiver per-message spoofing-vs- legitimate-mail disposition-decision boundary.
• Email authentication glossary
• TLS-RPT record syntax
• DNS propagation timelines
• SPF qualifiers explained — the per-publisher per-domain SPF qualifier-prefix envelope-MAIL-FROM-layer authorization-discipline companion at four per-publisher per-domain SPF-qualifier-prefix-vs-DKIM-troubleshooting coupling dimensions: (i) per-publisher per-domain SPF qualifier-prefix publication-decision matrix (+/-/~/? per RFC 7208 §4.6.2) result-class taxonomy IS structurally parallel envelope-MAIL-FROM-layer result-class catalogue to per-publisher per-selector DKIM-Signature verdict result-class catalogue per RFC 6376 §6 + RFC 8601 §2.7.1 (dkim=pass / dkim=fail / dkim=permerror / dkim=temperror / dkim=none) THIS DKIM troubleshooting diagnostic-ladder documents the symptom-driven root-cause-attribution sequence of — both per-publisher per-domain per-leg result-class taxonomies coordinate at the per-publisher per-domain composite envelope-MAIL-FROM-and-application-layer per-leg result-class catalogue coordination boundary; (ii) per-publisher per-domain SPF terminal-qualifier publication-decision -all strict-fail vs ~all softfail IS structurally parallel envelope-MAIL-FROM-layer enforcement-decision discipline to per-publisher per-selector DKIM-Signature l= partial-body-length tag publication-decision per RFC 6376 §3.5 strict-vs-permissive byte-coverage publication-discipline whose drift symptoms the DKIM troubleshooting diagnostic-ladder THIS page documents the root-cause-attribution of; (iii) per-publisher per-domain SPF permerror verdict on RFC 7208 §4.6.4 10-DNS-lookup-cap exhaustion under include:-cascade-delegation publication-discipline drift IS structurally parallel envelope-MAIL-FROM-layer publication-discipline-permerror failure-class to per-publisher per-selector DKIM permerror verdict-class on per-selector <selector>._domainkey.<domain> TXT-RR publication-discipline drift the DKIM troubleshooting diagnostic-ladder THIS page documents the symptom-driven root-cause-attribution sequence of materially diagnoses; (iv) per-publisher per-domain SPF qualifier-prefix mechanism-class publication-decision discipline drift (premature -all hardfail cutover surfacing as per-source-IP per-day DMARC RUA policy_evaluated/spf=fail attribution-distortion) IS structurally parallel envelope-MAIL-FROM-layer publication-discipline-drift class to per-publisher per-selector DKIM canonicalization-mode publication-decision drift (c=simple/simple-stuck publication-discipline drift surfacing as per-forwarder-class DKIM-verdict-collapse) the DKIM troubleshooting diagnostic-ladder THIS page documents the per-publisher per-selector application-layer authentication-leg-verdict root-cause-attribution discipline of materially diagnoses against the per-publisher per-domain composite envelope-MAIL-FROM-and-application-layer per-leg publication-discipline-drift coordination boundary.
• TLS-RPT JSON aggregate-report format — the PER-PUBLISHER-PER-POLICY-DOMAIN-TLS-RPT-JSON-AGGREGATE-REPORT-FAILURE-DETAILS-PER-MX-HOST-PER-FAILURE-CLASS-ATTRIBUTION-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-DIAGNOSTIC-EVIDENCE-STREAM-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-VERDICT-FAIL-ROOT-CAUSE-ATTRIBUTION-DIAGNOSTIC-LADDER companion at four per-publisher per-domain DKIM-troubleshooting-diagnostic-ladder-vs-TLS-RPT-aggregate-report-format-payload coupling dimensions: (i) per-publisher per-policy-domain TLS-RPT JSON aggregate-report failure-details[]/result-type/sending-mta-ip/receiving-mx-hostname per-day per-MX-host per-failure-class transport-layer per-receiver per-day attribution evidence-stream per RFC 8460 §4.3 IS structurally parallel transport-layer per-day per-MX-host per-failure-class diagnostic-evidence-stream to per-publisher per-selector DKIM-Signature application-layer per-message dkim=permerror/dkim=temperror/dkim=fail per RFC 8601 §2.7.1 per-receiver per-message verdict-attribution diagnostic-evidence-stream THIS DKIM-troubleshooting diagnostic-ladder THIS page documents the symptom-driven root-cause-attribution sequence of feeds — both per-publisher per-domain per-leg per-receiver evidence-stream references coordinate at the per-publisher per-domain composite application-and-transport-layer per-leg per-receiver evidence-stream coordination boundary; (ii) per-publisher per-policy-domain TLS-RPT JSON aggregate-report summary/total-successful-session-count/total-failure-session-count per-day per-policy-domain composite-success-rate evidence-stream IS the load-bearing transport-layer per-day per-policy-domain composite-success-rate diagnostic-evidence-stream attributing per-publisher per-domain STARTTLS-strip / MTA-STS-violation / DANE-mismatch / certificate-host-mismatch transport-layer per-MX-host per-failure-class diagnostic-evidence — structurally parallel application-layer per-day per-publisher per-domain composite-DKIM-aligned-pass-rate floor diagnostic-evidence-stream the per-publisher per-selector DKIM-troubleshooting diagnostic-ladder THIS page documents the symptom-driven root-cause-attribution sequence of consumes for per-publisher per-domain operator-side application-layer authentication-leg-verdict diagnostic-attribution discipline; (iii) per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format policies[]/policy-type/policy-string/policy-domain per-policy per-policy-domain attribution taxonomy IS structurally parallel transport-layer per-policy per-policy-domain attribution-taxonomy diagnostic-step to per-publisher per-selector DKIM-Signature header-tag publication-discipline (v=/a=/d=/s=/c=/h=/bh=/b=) per-message attribution-taxonomy diagnostic-step the per-publisher per-selector DKIM-troubleshooting diagnostic-ladder THIS page documents the per-message symptom-to-publication-discipline-drift root-cause-attribution sequence of walks; (iv) per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format publication-discipline drift (malformed JSON / missing failure-details[] attribution / oversized aggregate-payload / non-conformant result-type vocabulary) directly opens per-publisher per-domain transport-layer-aggregate-observability per-day per-MX-host evidence-stream blackout-window structurally parallel to per-publisher per-selector DKIM-Signature publication-discipline drift (mis-published per-selector <selector>._domainkey.<domain> TXT-RR byte-grammar per RFC 6376 §3.6.1 / malformed a= algorithm-identifier / truncated b= signature-bytes past RFC 6376 §3.5 byte-boundary / mis-published c= canonicalization-mode) the per-publisher per-selector DKIM-troubleshooting diagnostic-ladder THIS page documents the symptom-driven root-cause-attribution sequence of catalogues against — together the per-publisher per-selector DKIM-troubleshooting diagnostic-ladder THIS page documents the per-publisher per-selector application-layer per-message verdict-fail root-cause-attribution discipline of AND the per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format per-day per-MX-host per-failure-class transport-layer evidence-stream attribution publication-discipline compose the per-publisher per-domain composite application-and-transport-layer per-leg per-receiver per-day diagnostic-evidence-stream attribution-floor coordination boundary.
• DMARC multi-domain strategy
• SPF DNS record syntax
• BIMI certificates — the Verified Mark Certificate (VMC) program that sits at the very top of the stack this DKIM troubleshooting guide keeps healthy. A BIMI logo (and the VMC that vouches for it) only renders once the domain holds DMARC enforcement with a sustained aligned-pass rate, so every dkim=fail / permerror / temperror verdict this page teaches you to diagnose is also a reason the domain cannot safely hold the enforcement policy a VMC requires. Read the BIMI certificates spoke to see what the DKIM-leg health you are restoring here ultimately unlocks at the verified-logo layer.
• 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.

Diagnose a failing message now

DMARC Analyzer ingests every aggregate report and surfaces the per-source-IP failure profile in the dashboard. When you find a failing source, drill down on the per-IP detail view and the per-reporter detail view to see the failure-mode pattern over time. Then use the Email Header Analyzer to parse any representative failing message end-to-end — the symptom branch on this page will tell you the next step.

Sign up — Free plan Analyze a failing header