DMARC Analyzer

TL;DR

• Seven canonical DKIM verdicts per RFC 6376 §3.9 + RFC 8601 §2.7.1: none, neutral, pass, fail, policy, temperror, permerror. Each one tells you a structurally different thing about the message under verification.
• none vs fail vs permerror are the three most-confused verdicts. none = no signature present at all. fail = signature present and evaluated, but cryptography failed. permerror = signature present but could not be evaluated (missing public key, malformed signature, unsupported algorithm).
• dkim=pass does NOT mean DMARC passes. DMARC additionally requires ALIGNMENT — the d= tag must match (strict) or share an organizational domain with (relaxed) the From: header per RFC 7489 §3.1. The M365 onmicrosoft.com and Workspace gappssmtp.com gotchas are pure alignment failures with cryptographic dkim=pass.
• temperror is retryable; permerror is not. Concentrated temperror clusters from one receiver = transient DNS issue at THAT receiver; isolated temperror across receivers = your authoritative nameserver is flaky.
• policy is a receiver-side rejection distinct from fail — common causes are a key the receiver considers too weak (RFC 8301 permits RSA from 1024 bits and recommends 2048), the rsa-sha1 algorithm (forbidden by RFC 8301; also reported as permerror), a signature the receiver considers too old (t=; a signature past its x= is a permerror under RFC 6376), or headers the receiver's policy requires missing from the h= list.
• fail is almost always a forwarder/list problem when the underlying signature was valid at origin. Mailing-list footer injection, MTA body re-encoding, Microsoft Defender anti-spoof rewrite, security-gateway sandboxing — all of these break the body hash. ARC sealing (RFC 8617) is the protocol-level fix.
• Per-verdict diagnostic-next-step matrix is the section below. Map the verdict to the action and execute.
• DKIM failures arrive most often through DMARC aggregate reports — DMARC Analyzer's reports view (parsed via includes/DmarcParser.php) breaks down DKIM verdicts per reporter and per source IP so you can localize a failure to a single receiver, source, or time window.

What this guide covers

A complete receiver-side verdict reference for DKIM. Where DKIM explained documents how the signing pipeline works (sender-side: key generation, header canonicalization, body-hash computation, DKIM-Signature header emission per RFC 6376) and DKIM canonicalization documents the c= tag's simple-vs-relaxed tradeoff, THIS page documents the receiver-side verdict the verifier emits after evaluating the signature - what each verdict means structurally, what it implies operationally, and what diagnostic action it calls for.

The seven verdict keywords are normative per RFC 8601 §2.7.1 (Message Header Field for Indicating Message Authentication Status); they map back to the RFC 6376 §3.9 status enumeration that DKIM verifiers internally produce. Every DMARC aggregate report (RFC 7489 §7.2) that your rua= mailbox receives contains a <auth_results><dkim> block whose <result> element uses exactly these seven keywords.

The page is anchored against the Feb 2024 Google/Yahoo bulk-sender enforcement that demands aligned DKIM for high-volume senders. Misdiagnosing dkim=fail as "DKIM broken" when the actual cause is a forwarder body rewrite leads to wasted hours on the wrong fix; this page exists to short-circuit that misdiagnosis.

Anatomy of a DKIM verdict in Authentication-Results

The verifier records its verdict on each message in an Authentication-Results header per RFC 8601. A representative DKIM-only stanza:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1 header.b=AbCdEf12;
       dkim=fail (body hash did not verify) header.i=@list.example.org header.s=2024a header.b=ZyXwVu90;

A single message MAY produce MULTIPLE DKIM verdicts when it carries multiple DKIM-Signature headers - each signer's signature is evaluated independently and emits a separate dkim= stanza. The example above shows the sender's original signature passing (dkim=pass header.d=example.com) and a mailing-list re-signature failing (dkim=fail header.d=list.example.org, body rewritten by list footer injection).

Per-stanza fields

• dkim=<verdict> — one of the seven RFC 6376 §3.9 / RFC 8601 §2.7.1 keywords. The verdict.
• (<optional reason>) — optional free-text describing the failure cause (e.g., "body hash did not verify", "key not found", "weak key size"). Receiver-specific format; not normative.
• header.i=<AUID> — the agent or user identifier from the i= tag of the DKIM-Signature header (typically @<signing-domain>).
• header.d=<domain> — the signing-domain identifier from the d= tag. THIS is the value DMARC alignment checks against the From: header.
• header.s=<selector> — the selector from the s= tag. Locates the public-key TXT at <s>._domainkey.<d>.
• header.b=<sig-prefix> — at least the first eight characters of the b= tag value (RFC 6008). Useful for cross-referencing the verdict with the actual signature header without quoting the full signature.

Multiple Authentication-Results headers

A message that traverses multiple authentication-aware MTAs may accumulate multiple Authentication-Results headers, each scoped to the authserv-id at the start of the header (mx.google.com in the example). When debugging always identify the AUTHORITATIVE Authentication-Results — the one whose authserv-id matches the receiving MTA that ultimately delivered or rejected the message.

Verdict: dkim=none

Definition: per RFC 8601 §2.7.1, the message was not signed — the verifier had nothing to evaluate.

What it means

The message arrived without a single DKIM-Signature header. This is different from dkim=fail (signature present, crypto failed) or dkim=permerror (signature present but unevaluable). The verifier did not run cryptography at all because there was no input.

Common causes

• DKIM was never enabled at the sending platform. The #1 cause. On M365 the Set-DkimSigningConfig -Enabled $true step was skipped; on Workspace the Start authentication click never landed.
• The sender is mailing through a non-DKIM-enabled path — a bulk-mail platform that does not sign on the sender's behalf, an ESP whose free-tier account does not include DKIM signing, an SMTP-relay device that strips DKIM by default.
• An MTA in the path stripped the DKIM-Signature header. Rare in 2024 but possible with legacy appliances or misconfigured Default-Frontend Connectors on hybrid Exchange (see DMARC for Hybrid Exchange).
• The signing domain's outbound relay was bypassed — direct SMTP submission to the receiver that bypasses the platform's signing layer. Common with on-prem connectors and misconfigured SMTP-AUTH endpoints.

Operational consequence

DMARC requires at least one of DKIM or SPF to PASS AND ALIGN. dkim=none provides neither pass nor alignment (no signing domain to align against). If SPF also fails or misaligns, DMARC fails. dkim=none is the most-common DMARC failure root cause for senders that never finished DKIM rollout.

Diagnostic next step

Verify DKIM is enabled and active at the sending platform:

• For Microsoft 365: Get-DkimSigningConfig -Identity <your-domain> | Format-List Enabled,Status must return Enabled=True; Status=Valid. See DKIM for Microsoft 365.
• For Google Workspace: Admin Console Authenticate email panel must show domain status Authenticating email. See DKIM for Google Workspace.
• For any platform: send a test message to a mailbox you control and inspect the headers. If no DKIM-Signature appears, signing is not happening on that path.

Verdict: dkim=neutral

Definition: per RFC 8601 §2.7.1, the message was signed, but the signature contained syntax errors or could not otherwise be processed.

What it means

The verifier saw a signature but reached neither pass nor fail. RFC 8601 also uses neutral for failures not covered by the other results, so implementations vary in what they report under it.

Common emission cases

• The signing algorithm is one the verifier does not implement (e.g., ed25519-sha256 per RFC 8463 at a receiver that only supports RSA), so the signature cannot be processed.
• The verifier policy treats certain edge cases as neutral rather than fail. Some verifiers emit neutral when a l= (body-length-limit) tag is present but the partial-body verification was ambiguous.
• Local policy quirks — receivers sometimes mark questionable signatures neutral pending policy refinement.

Operational consequence

Treat dkim=neutral like dkim=none for DMARC alignment purposes — it does not produce a DKIM-pass-and-align. Unlike fail it is not a verifier-rejection; the message is not being branded as unauthentic.

Diagnostic next step

Inspect the optional reason text in the Authentication-Results stanza for hints (some verifiers include the algorithm name or specific policy rule). If volume is concerning, contact the receiver operator — dkim=neutral is rare enough that it usually indicates a niche compatibility issue worth surfacing.

Verdict: dkim=pass

Definition: per RFC 8601 §2.7.1, the signature verified cryptographically — the public key resolved, the algorithm was supported, the body hash matched, and the header signature matched.

What it means

The DKIM verifier successfully completed every protocol step:

1. Looked up <s=>._domainkey.<d=> TXT and retrieved a valid v=DKIM1; k=<algorithm>; p=<public-key> record.
2. Computed the body hash per the c= tag's canonicalization rules and confirmed it matches the bh= tag.
3. Reconstructed the signed-header set per the h= tag and verified the signature using the public key.
4. Verified the algorithm in the a= tag is supported and not deprecated.

What it does NOT mean

dkim=pass does not mean DMARC passes. Two messages can both have dkim=pass with different DMARC outcomes:

# Aligned - DMARC pass
From: alice@example.com
DKIM-Signature: ... d=example.com s=selector1 ...
Authentication-Results: dkim=pass header.d=example.com header.from=example.com
DMARC: pass (alignment via DKIM)

# Misaligned - DMARC fail
From: alice@example.com
DKIM-Signature: ... d=tenant.onmicrosoft.com s=selector1 ...
Authentication-Results: dkim=pass header.d=tenant.onmicrosoft.com header.from=example.com
DMARC: fail (no aligned authentication)

DMARC requires the d= tag to MATCH the From: header per RFC 7489 §3.1 — exact match for strict alignment, organizational-domain match (via the Public Suffix List) for relaxed alignment. The M365 onmicrosoft.com gotcha and the Workspace gappssmtp.com gotcha both produce dkim=pass with DMARC fail because the signing domain is the tenant routing domain rather than the custom domain.

Diagnostic next step

If dkim=pass but DMARC fails: read DMARC alignment for the alignment rules and inspect the header.d versus header.from in the Authentication-Results.

Verdict: dkim=fail

Definition: per RFC 8601 §2.7.1, signature evaluation completed but the cryptographic verification failed — the public key resolved but did not validate the signature.

What it means

The verifier got far enough to attempt cryptographic verification but the comparison failed. This is structurally different from permerror (could not even attempt verification) and temperror (could not retrieve the key).

Common causes — ordered by frequency

1. Body modification by a forwarder — a mailing list appended a footer ("You are receiving this because you subscribed to..."), a security gateway rewrote URLs through a sandbox, an outbound relay normalized line-endings. The body hash bh= no longer matches.
2. MIME re-encoding by an intermediate MTA — base64 ↔ quoted-printable conversion, whitespace normalization in text/plain bodies. Any byte change invalidates the body hash.
3. Header modification by an anti-spoof rewriter — Microsoft Defender's "From:" header rewrite for unauthenticated mail triggered for the wrong reason; anti-phishing scanners modifying Subject prefixes.
4. Body-hash canonicalization mismatch — sender signed with c=simple/simple (strict) but a downstream MTA changed even a single byte; c=relaxed/relaxed is the modern default for forwarder tolerance.
5. Key mismatch — the operator rotated the key but the old TXT was retired before in-flight signed messages cleared the system.

What dkim=fail almost always IS

A FORWARDER or LIST problem. The original sender's signature was valid when it left the sending MTA; something between sender and final receiver modified the message. ARC sealing per RFC 8617 is the protocol-level fix — see ARC explained.

What dkim=fail rarely is

A genuine sender-side configuration failure. If the sender's outbound signing was broken, you would see dkim=fail CONSISTENTLY across all messages — not the intermittent dkim=fail that forwarder rewrites produce.

Diagnostic next step

• Check whether the failing messages share a common X-Mailing-List / List-Id / forwarder signature header — a single source usually points at a single forwarder problem.
• If forwarders are the cause, the ARC seal has to be added by the intermediary and trusted by the receiver (Defender for Office 365 has a Trusted ARC Sealers list; Google Workspace seals with ARC automatically).
• If the failure is consistent across all messages, suspect sender-side configuration: signing module broken, key rotated incorrectly, MTA stripped the signature before transmission. Send a test message and inspect the DKIM-Signature header BEFORE the forwarder hop.

Verdict: dkim=policy

Definition: per RFC 8601 §2.7.1, the signature was evaluated against a LOCAL receiver policy and the policy rejected it.

What it means

The signature itself may have been cryptographically valid, but the receiver applied a stricter local rule than the minimum RFC 6376 spec — and that rule rejected the signature.

Common policy rejections

• Forbidden algorithm — rsa-sha1 is forbidden by RFC 8301, which requires signing and verifying with rsa-sha256 only; receivers report such a signature as policy or permerror.
• Weak key size — RFC 8301 permits RSA keys from 1024 bits and recommends at least 2048; keys shorter than 1024 bits are a permanent failure. Strict receivers may reject 1024-bit keys by policy as well, so 2048-bit is the baseline.
• Signature too old — the t= (signing timestamp) tag is older than the receiver-configured maximum. A signature past its x= (expiration) tag is already a PERMFAIL under RFC 6376, i.e. permerror.
• Missing required header in h= tag — the receiver requires From, Subject, Date, To, and Message-ID all covered by the signature, but the h= list omits one of them.
• Suspicious signing-domain pattern — receiver detected the d= tag is a freshly-registered throwaway or matches a known abuse catalogue.

Operational consequence

Like dkim=fail, dkim=policy does not provide DMARC alignment. Unlike dkim=fail the fix is almost always sender-side — you must upgrade your signing posture to meet the receiver's policy.

Diagnostic next step

• If the reason includes "weak key" or "key size", rotate to 2048-bit RSA per RFC 8301. See DKIM key rotation.
• If the reason includes "algorithm", ensure your signer uses a=rsa-sha256 (not rsa-sha1).
• If the reason includes "expired", extend the window of the x= tag or find out why messages arrive that late.
• If the reason is missing or generic, contact the receiver operator — local policy rules are not RFC-normative and often need direct communication to diagnose.

Verdict: dkim=temperror

Definition: per RFC 8601 §2.7.1, evaluation hit a TEMPORARY error that prevented completion — typically a DNS timeout while looking up the public key.

What it means

The verifier began evaluation but could not complete it. The signature is not necessarily invalid; the verifier just could not retrieve the public-key TXT in time. RFC 6376 calls this result TEMPFAIL and lets the verifier defer the message for later processing or try another signature (§6.1); RFC 8601 adds that a later attempt may produce a final result. Until the key is retrieved, the signature does not count as valid.

Common causes

• Authoritative nameserver outage — the operator's primary DNS host has a momentary outage while the verifier is querying.
• Recursive resolver flakiness — the receiver's resolver is overloaded or experiencing transient packet loss.
• CNAME-chain timeout — for M365 DKIM CNAMEs that resolve through the tenant onmicrosoft.com target, a slow resolution chain can time out before the TXT at the chain's end is retrieved.
• Anycast routing changes — DNS anycast pools occasionally shift traffic between sites mid-lookup; verifiers with aggressive timeouts hit these shifts as temperrors.

How to read temperror in aggregate reports

Isolated temperror rows (one or two from a single receiver in a 24-hour window) are routine and self-resolve.

Concentrated temperror clusters tell you something:

• If many rows from ONE receiver are temperror in a tight time window, that receiver's resolvers had an outage — not your problem.
• If many rows from ALL receivers are temperror across a 24-hour window, YOUR authoritative nameserver is flaky. Investigate your DNS provider.

Diagnostic next step

• Run continuous external DNS probes against <your-selector>._domainkey.<your-domain> from multiple geographies for 24-48 hours. If the probes show consistent sub-100ms responses, the issue is receiver-side.
• Validate the CNAME chain depth — long chains amplify lookup latency. M365 CNAMEs typically chain through 2 hops; more than 3 is suspicious.
• Verify TTL values are reasonable (3600-86400 for steady-state); very low TTLs increase lookup load and timeout risk.

Verdict: dkim=permerror

Definition: per RFC 8601 §2.7.1, evaluation hit a PERMANENT error that prevented completion — the verifier could not even attempt cryptographic verification.

What it means

Something is structurally wrong with the signature or its surrounding context such that the verifier cannot perform the crypto. Unlike temperror this is not retryable — the next lookup will produce the same permerror.

Common causes

• Public-key TXT does not exist — the <s>._domainkey.<d> query returns NXDOMAIN. Most common after a botched rotation that retired the old selector's TXT before in-flight signed messages cleared the system.
• Public-key TXT is empty or revoked — the TXT contains v=DKIM1; k=rsa; p= with no public-key bytes (Workspace explicit revocation pattern).
• Public-key TXT is malformed — invalid base64, wrong tag set, broken multi-string chunking past the 255-byte TXT character-string limit per RFC 1035 §3.3.14.
• DKIM-Signature header is syntactically broken — missing required tags (v=, a=, d=, s=, h=, b=, bh=), invalid base64, malformed canonicalization spec.
• Algorithm forbidden or not supported — the a= tag specifies rsa-sha1, which RFC 8301 treats as permanently failed, or an algorithm the verifier does not know at all (the latter is also reported as neutral).

Operational consequence

Like dkim=fail and dkim=policy, permerror does not produce DMARC alignment. Unlike fail, permerror almost always points at a sender-side publishing or signing problem, not a forwarder.

Diagnostic next step

• Look up the public-key TXT yourself: dig +short TXT <s=>._domainkey.<d=>. If NXDOMAIN, the publishing side is broken.
• Validate the TXT format with a DKIM record-syntax tool (or Domain Security Checker's DKIM block).
• Pull the failing message's full DKIM-Signature header (header.b= is in the Authentication-Results) and run it through Email Header Analyzer for the structural validation.

DKIM verdicts versus DMARC alignment

The single most-confused topic in DKIM diagnostics. DKIM verification is separate from DMARC alignment.

DKIM verification answers: "Did the signature cryptographically verify?" The answer is the verdict — one of the seven keywords above.

DMARC alignment answers: "Does the d= tag of a dkim=pass signature match (strict) or share an organizational domain (relaxed) with the From: header?"

Both must succeed for DKIM-based DMARC authentication. The standard error cases:

Case A: dkim=pass + DMARC pass

From: alice@example.com
DKIM-Signature: ... d=example.com s=selector1 ...
Authentication-Results: dkim=pass header.d=example.com header.from=example.com
DMARC: pass (DKIM aligned)

The happy path. d= equals From: so DMARC is satisfied.

Case B: dkim=pass + DMARC fail (M365 onmicrosoft.com gotcha)

From: alice@example.com
DKIM-Signature: ... d=tenant.onmicrosoft.com s=selector1 ...
Authentication-Results: dkim=pass header.d=tenant.onmicrosoft.com header.from=example.com
DMARC: fail (no aligned authentication)

Signature is valid (dkim=pass) but d=tenant.onmicrosoft.com does not match From=example.com — alignment fails. See DKIM for Microsoft 365 for the M365 fix.

Case C: dkim=pass + DMARC fail (Workspace gappssmtp.com gotcha)

From: alice@example.com
DKIM-Signature: ... d=tenant.gappssmtp.com s=20221208 ...
Authentication-Results: dkim=pass header.d=tenant.gappssmtp.com header.from=example.com
DMARC: fail (no aligned authentication)

Same structural problem as Case B but on Google Workspace. See DKIM for Google Workspace for the Workspace fix.

Case D: dkim=fail or dkim=permerror — alignment irrelevant

Without a dkim=pass verdict there is no DKIM-based alignment to evaluate. DMARC falls back to SPF-based alignment (or fails entirely if SPF also fails or misaligns).

Reading DKIM verdicts in DMARC aggregate reports

DMARC aggregate (rua) reports per RFC 7489 §7.2 include a <auth_results><dkim> block per signature evaluated. Schema:

<auth_results>
    <dkim>
        <domain>example.com</domain>
        <selector>selector1</selector>
        <result>pass</result>
        <human_result></human_result>
    </dkim>
    <dkim>
        <domain>list.example.org</domain>
        <selector>2024a</selector>
        <result>fail</result>
        <human_result>body hash did not verify</human_result>
    </dkim>
</auth_results>

The <result> element uses the same seven keywords this guide documents (pass, fail, neutral, temperror, permerror, none, policy). The <human_result> element optionally carries the receiver's free-text failure reason — exceptionally valuable for diagnosis when present.

DMARC Analyzer's report drill-down

The Reports page (parsed via includes/DmarcParser.php) groups DKIM verdicts by:

• Reporter — who issued the verdict (mail.google.com, outlook.com, mx.yahoo.com, etc.). A single reporter producing all the failures usually = a forwarder problem at that one receiver.
• Source IP — what sending IP the message came from. A single source IP producing all the failures usually = a misconfigured outbound MTA.
• Signing domain (header.d) — what d= tag the signer used. Useful for catching the M365 onmicrosoft.com and Workspace gappssmtp.com gotchas.
• Time window — when the failures occurred. Concentrated time clusters often correlate with deployment events (key rotation, signer migration, MTA upgrade).

The dashboard's per-reporter breakdown is the fastest way to localize "is this failure my fault or the receiver's?" — typically the answer is visible in seconds.

Per-verdict decision matrix

Map verdict to action:

• dkim=none → DKIM is not enabled at the sending platform. Verify Get-DkimSigningConfig (M365) or Admin Console status (Workspace); enable signing for the custom domain.
• dkim=neutral → Rare; inspect the reason text; usually a niche algorithm or policy edge case. Contact receiver if volume is concerning.
• dkim=pass + DMARC fail → Alignment problem, not a DKIM problem. Check header.d vs header.from; almost always the M365 onmicrosoft.com or Workspace gappssmtp.com gotcha.
• dkim=fail → Almost always a forwarder/list rewriting the body. Configure ARC sealing at the outbound MTA. If consistent across all messages, suspect sender-side signer breakage.
• dkim=policy → Sender-side posture upgrade needed. Rotate to 2048-bit RSA + rsa-sha256; remove the x= tag if present; ensure h= covers From, Subject, Date, To, Message-ID.
• dkim=temperror → DNS lookup transient failure. If isolated, ignore. If concentrated from one receiver, the receiver's DNS had an outage. If concentrated across all receivers, your authoritative nameserver is flaky.
• dkim=permerror → Sender-side publishing or signing problem. dig the public key, validate the TXT format, parse the DKIM-Signature header structurally.

Frequently asked questions

What does dkim=none mean in Authentication-Results?

dkim=none per RFC 8601 §2.7.1 means the message arrived with no DKIM-Signature header at all - the verifier had nothing to evaluate. The most common cause is that the sending domain never enabled DKIM signing for outbound mail. On Microsoft 365 the fix is Set-DkimSigningConfig -Identity <your-domain> -Enabled $true after publishing the two CNAMEs; on Google Workspace it is the Start authentication click in the Admin Console after publishing the google._domainkey TXT. dkim=none is NOT a failure per se - it indicates absence rather than verification failure - but it is fatal for DMARC because DMARC requires at least one of DKIM or SPF to align with the From: header domain. When you see dkim=none in DMARC aggregate reports for messages your domain sent, the diagnostic next step is to verify DKIM is enabled at the sending platform.

What is the difference between dkim=fail and dkim=permerror?

dkim=fail means the signature was evaluated and FAILED cryptographically - the public key resolved correctly but the signature did not verify against the message content. Common causes: body modification by a forwarder, mailing-list footer injection, MTA header rewriting, body-hash mismatch from MIME re-encoding. dkim=permerror means the signature could not be evaluated at all due to a permanent error - the public key TXT does not exist or is malformed, the d= domain has no DNS record at the selector, the signature header itself is syntactically broken, or the algorithm is unsupported. The diagnostic distinction matters: dkim=fail = signature reached the verifier but the content was tampered (operationally a forwarder/list problem); dkim=permerror = the verifier could not even attempt verification (operationally a publishing/configuration problem). RFC 6376 §3.9 defines three verifier outputs (SUCCESS, PERMFAIL, TEMPFAIL); RFC 8601 §2.7.1 defines the seven dkim=X keywords that appear in Authentication-Results.

What does dkim=temperror mean and should I be worried?

dkim=temperror means the verifier hit a temporary failure that prevented evaluation - usually a DNS timeout while looking up the public key at <s=>._domainkey.<d=>. The signature itself may be valid; the verifier just could not retrieve the key in time. Common causes: authoritative nameserver outage, recursive resolver flakiness, transient network failure between verifier and the publishing nameserver, CNAME-chain timeout (M365 CNAMEs that resolve through the tenant target onmicrosoft.com). Per RFC 8601 a later attempt may produce a final result, and RFC 6376 §6.1 lets the verifier defer the message for later processing or try another signature - until the key is retrieved the signature does not count as valid. If you see ISOLATED dkim=temperror rows in aggregate reports they are usually transient and self-resolve. If you see CONCENTRATED dkim=temperror clusters (many rows from the same receiver, same time window) then your authoritative nameservers may be under-resourced or there is a CNAME-chain problem.

What does dkim=neutral mean?

dkim=neutral per RFC 8601 §2.7.1 means the message was signed, but the signature contained syntax errors or could not otherwise be processed. The RFC also uses it for failures not covered by the other results. The most common modern case is a signature using an algorithm the verifier does not implement (e.g., ed25519-sha256 per RFC 8463 at a receiver that only supports RSA), or an edge case a verifier prefers to report as neutral rather than fail. dkim=neutral is rare in practice and implementations vary in what they report under it. RFC 8601 adds that neutral, like none, means the message will be treated as if it had not been signed, so treat dkim=neutral like dkim=none for DMARC alignment purposes (it does not produce alignment). If you see dkim=neutral in aggregate reports at a concerning volume, check the syntax of your own signature and contact the receiving operator.

What is dkim=policy and when does it appear?

dkim=policy per RFC 8601 §2.7.1 means the message was signed, but some aspect of the signature was not acceptable to the receiving domain - a LOCAL receiver policy rejected it. Common policy rejections: a key the receiver considers too weak (RFC 8301 permits RSA from 1024 bits and recommends at least 2048, and strict receivers may demand more than the minimum), a signature older than the receiver accepts (the t= timestamp tag), a third-party signing domain the receiver does not accept, or an h= tag that does not cover a header the receiver requires signed per its local policy. Some receivers also report rsa-sha1 signatures as policy, although RFC 8301 treats them as permanently failed. dkim=policy is a receiver-side rejection, distinct from the protocol-level dkim=fail. The operational fix is sender-side: sign with rsa-sha256, upgrade to 2048-bit keys, and ensure the h= tag covers From (an RFC 6376 requirement) plus Subject, Date, To and Message-ID. See RFC 8301 for the modern algorithm/key-size requirements.

My DKIM signature says dkim=pass but DMARC still fails - why?

Because dkim=pass evaluates ONLY the cryptographic signature, not DMARC ALIGNMENT. DMARC requires the DKIM-Signature d= tag to ALIGN with the From: header domain (RFC 7489 §3.1) - either strict (exact match) or relaxed (organizational-domain match via PSL). The most common alignment-failure pattern is the M365 onmicrosoft.com gotcha (dkim=pass header.d=tenant.onmicrosoft.com but header.from=example.com - signature passes, alignment fails) and the Workspace gappssmtp.com gotcha (dkim=pass header.d=tenant.gappssmtp.com but header.from=example.com). The fix is to enable DKIM signing for the CUSTOM domain at the sending platform so the d= tag points at example.com instead of the tenant routing domain. See help_dmarc_alignment.php for the alignment-evaluation rules and help_dkim_for_microsoft_365.php / help_dkim_for_google_workspace.php for the per-provider fixes.

How do I find DKIM failure verdicts in DMARC aggregate reports?

DMARC aggregate (rua) reports per RFC 7489 §7.2 include, in every report row, an <auth_results> block with one <dkim> element for each evaluated signature. Each block contains a <domain> (the DKIM d= tag), a <selector> (the s= tag), and a <result> element that is one of pass, fail, neutral, temperror, permerror, none, or policy (matching the RFC 6376 §3.9 status keywords exposed via RFC 8601 §2.7.1). DMARC Analyzer parses these blocks via includes/DmarcParser.php and surfaces the per-domain DKIM verdict breakdown on the dashboard. To pivot from "I see dkim=fail in my Authentication-Results header" to "show me all rua rows for that domain and selector", upload the rua XML or feed it via IMAP/Graph and open the Reports drill-down. The drill-down groups DKIM verdicts by reporter so you can isolate whether a single receiver is producing the failures (likely a forwarder/list problem on their side) or all receivers are (likely a sender-side configuration problem).

Can DKIM verdicts differ between receivers for the same message?

Yes, by design. RFC 6376 leaves DKIM verification policy choices to receivers, and RFC 8601 only specifies the verdict vocabulary - not the verdict-emission rules. Three common divergence patterns: (1) Forwarder rewrites the message body between hop 1 (receiver A reports dkim=pass for the original signature) and hop 2 (receiver B reports dkim=fail because body-hash mismatches after the rewrite) - solved by ARC sealing per RFC 8617. (2) Local-policy strictness: receiver A accepts a signature made with a 1024-bit key as dkim=pass while receiver B emits dkim=policy on the same message - solved by sender-side migration to 2048-bit keys and rsa-sha256. (3) DNS-cache state: receiver A had the DKIM TXT cached from a prior lookup while receiver B emits dkim=temperror because its lookup hit a transient nameserver outage. The DMARC aggregate-report ecosystem reveals this divergence by reporting receiver-by-receiver verdicts; the dashboard pivot view shows where consistency breaks down.

Related guides

• DKIM explained — the protocol primer covering RFC 6376 mechanics, signing pipeline, header canonicalization, and the Authentication-Results stack. Start here if you have not seen the sender-side signing model.
• Why SPF alone is insufficient — the DKIM-FAILURE-MODE-CATALOGUE- AS-LOAD-BEARING-PROOF-EVIDENCE-FOR-SPF- ALONE-IS-INSUFFICIENT-DEFENSE-IN-DEPTH- MOTIVATION companion to this DKIM-failure- mode operational catalogue. Where THIS page documents the per-DKIM-failure-mode catalogue (per-message body-hash mismatch, per-message canonicalization-mismatch, per-message signature-verification-failure, per-publisher per-selector public-key- absence, per-publisher per-selector key- revoked, per-message DKIM-Signature- header-tampered, per-message forwarder- modified-body, per-publisher per-selector cryptographic-trust-anchor-publication- defect), the why-SPF-alone-is-insufficient spoke is the per-publisher-per-receiver defense-in-depth motivation reference whose per-attack-class arguments map directly to per-DKIM-failure-mode operational-evidence at FOUR per-failure- mode-vs-SPF-alone-gap rebuttal-evidence dimensions: (i) per-message forwarder-modified-body DKIM-failure-mode as load-bearing proof-evidence for SPF- breaks-under-forwarding RFC 7208 §10.4 gap — per-message forwarder- modified-body DKIM-failure-mode is the per-publisher operational evidence-stream proving per-forwarder hops break per- source-IP envelope-MAIL-FROM SPF-aligned- pass on the second-hop without a per- publisher per-message DKIM-side cryptographic-trust-anchor to credentials the per-forwarder rewrite; (ii) per-message DKIM-Signature-header-tampered DKIM-failure-mode as load-bearing proof- evidence for SPF-cannot-detect-header- From-spoofing gap — per-message DKIM-Signature-header tampered-or-stripped DKIM-failure-mode is the per-publisher operational evidence-stream proving per- attacker per-message header-From-spoofing attacks pass per-source-IP envelope-MAIL- FROM SPF-aligned-pass when the attacker controls a per-source-IP envelope-MAIL- FROM that authenticates via SPF but the per-message DKIM-side verification catches the per-message header-From- tampering; (iii) per-publisher per-selector cryptographic-trust-anchor- publication-defect DKIM-failure-mode as load-bearing proof-evidence for SPF- record-publishing-alone-leaves-DKIM-side- gap — per-publisher per-selector cryptographic-trust-anchor publication absence-or-defect DKIM-failure-mode is the per-publisher operational evidence- stream proving per-publisher operators relying on per-source-IP SPF-alone publication discipline leave the per- publisher per-receiver per-message DKIM- side defense-in-depth leg ungated; (iv) per-message canonicalization- mismatch DKIM-failure-mode as load- bearing proof-evidence for SPF-only- DMARC-policy-mode-progression-is- insufficient gap — per-message canonicalization-mismatch DKIM-failure- mode is the per-publisher operational evidence-stream proving per-publisher operators committing to per-publisher p=quarantine / p=reject DMARC policy-mode with per-source-IP SPF-aligned-pass-rate floor BUT degraded per-message DKIM- canonicalization-discipline ship per- receiver per-message legitimate-message- loss as DMARC-fail dispositions when per- forwarder per-message canonicalization- rewrites break per-message DKIM-side verification.
• DKIM troubleshooting — the symptom-driven debugging companion keyed off the exact result values this page documents. Where THIS page explains what dkim=fail / dkim=neutral / dkim=temperror / dkim=permerror / dkim=policy MEAN at the protocol level (RFC 6376 §3.9 plus the Authentication-Results conventions), the troubleshooting page walks the operator through the diagnose-and-fix sequence starting from each result-value symptom: which DNS lookups to run, which message headers to inspect, which provider-side configuration knobs to check, and which third-party validators to consult. Read this page first to understand WHAT the result values mean, then jump to troubleshooting to find out WHAT TO DO when you see one in your Authentication-Results header or aggregate-report payload.
• DKIM canonicalization — the deep dive on the c= tag's simple-vs-relaxed semantics. The most common dkim=fail root cause is body modification, which interacts directly with canonicalization choice.
• DKIM selectors explained — the cross-provider selector catalogue. permerror often traces to a wrong-selector lookup; this page documents each provider's naming convention.
• DKIM DNS record syntax (TXT-record byte reference) — the byte-by-byte reference for the TXT record at <selector>._domainkey.<d-domain> operators consult when a dkim=permerror or dkim=fail verdict traces past the selector-name lookup to a malformed-record-body root cause. Where THIS page catalogues the seven RFC 6376 §3.9 verdict keywords, the DNS-syntax page documents the byte-level rules the public-key record itself must satisfy: the v=DKIM1 version-tag, the k=rsa / k=ed25519 algorithm tag, the p=<base64-public-key> tag with its DER-encoded SPKI payload, the p=-empty revocation signal (distinguishes deliberate revocation from accidental deletion — same observable dkim=permerror verdict, different root cause and different remediation), the 2048-bit public-key split-string TXT-record concatenation rule that the major registrars handle inconsistently (Cloudflare auto-splits, GoDaddy manual 255-byte chunks, BIND ("..." "...") concatenation form — the #1 silent- record-rejection cause when a UI truncates the public key without splitting), the optional t=y testing flag, t=s strict-alignment flag, h= hash-algorithm restriction, and legacy tags (g= granularity per RFC 6376 §3.6.1, s=* service-type-wildcard). Read this page when a verdict from THIS catalogue traces to a DNS lookup that returns a record — but the record fails to parse correctly at the receiver — and you need the byte-level reference to diagnose which constraint the record violates.
• DKIM key rotation — rotation operational discipline. Mid-rotation timing errors are a major source of temperror and permerror.
• DKIM replay attacks — the threat model behind why receivers enforce policies like algorithm strength and signature expiry that produce dkim=policy.
• DKIM cryptography basics — RSA-SHA256, 2048-bit key sizes, public-key verification chain. Understanding the crypto explains why dkim=fail can result from a single byte change anywhere in the signed material.
• DKIM best practices (the 15 deployment rules) — the operational recommendation catalogue whose 15 rules PREEMPT most of the dkim=fail / dkim=neutral / dkim=permerror / dkim=temperror / dkim=policy verdicts this page catalogues at the protocol level. Where THIS page documents WHAT each RFC 6376 §3.9 verdict keyword MEANS once it appears in an Authentication-Results header or aggregate-report row, best-practices documents the configuration discipline that keeps those verdicts from appearing in the first place: Rule 2 (RSA ≥ 2048 or Ed25519 — preempts the policy verdict receivers emit when they reject 1024-bit RSA per RFC 8301), Rule 4 (annual rotation with dual- selector overlap — preempts temperror windows during DNS-propagation overlap and permerror after retired-selector deletion), Rule 5 (c=relaxed/relaxed — preempts most of the body-hash-mismatch dkim=fail root causes catalogued in section 7 of the canonicalization page: forwarder whitespace folding, mailing-list footer injection, content-transform middleware, transfer- encoding changes), Rule 6 (header-list signing discipline — preempts the From-rewriting and Subject- prefix permerror patterns from mailing lists), Rule 8 (NEVER use l= — preempts the partial- body-replay and trailing-content injection dkim=pass-but-DMARC- fail patterns), Rule 9 (24–72h t=y burn-in — exercises the verdict surface in receivers' test buckets before flipping to enforcement, surfacing every dkim=fail root cause without operational impact), Rule 11 (multi-signature double-signing — hedges against ANY single receiver rejecting one signature: as long as the OTHER signature verifies the message emits dkim=pass regardless), and Rule 13 (DNS publication discipline — preempts the dkim=permerror wave that follows a Cloudflare auto-split mis-handle, a GoDaddy 255-byte-chunk truncation, or a BIND multi-string syntax error on the public-key record). Read best-practices alongside this page when triaging an observed verdict in your Authentication-Results or aggregate-report payload: this page tells you WHAT the verdict means and which RFC clause produced it, best-practices tells you WHICH configuration knob to harden to make that verdict disappear from future deliveries (and which adjacent rules are likely to be relevant once the immediate cause is addressed).
• DKIM for Microsoft 365 — provider-specific deployment guide; the onmicrosoft.com gotcha is the #1 dkim=pass + DMARC fail pattern on M365 tenants.
• DKIM for Google Workspace — provider-specific deployment guide; the gappssmtp.com gotcha is the #1 dkim=pass + DMARC fail pattern on Workspace tenants.
• DMARC for shared hosting — the PER-NON-CPANEL-CONTROL-PANEL shared-hosting deployment companion that amplifies four of the seven DKIM verdict classes THIS page documents. Where THIS page catalogues the seven receiver-side DKIM verdict keywords as provider-neutral failure modes (bodyhash-mismatch, signature-mismatch, permerror, temperror, neutral, none, policy), the shared-hosting spoke documents the per-panel deployment topology (Plesk's Mail → Mail Settings → DKIM toggle, DirectAdmin's Email-Authentication panel, ISPConfig's Email → Domain DKIM tab, Webmin/Virtualmin's per-virtual-server DKIM-Signing module, CWP's Email-Manager DKIM-key-management plugin) whose provider-managed default signer structurally amplifies FOUR of the verdict classes: (i) signature-mismatch amplification — when the provider's shared signer publishes a single default selector (default._domainkey.<provider>.com) that the operator never rotates, the per-tenant signing key footprint becomes a long-lived attack surface that produces receiver-side signature-mismatch verdicts at scale once any one tenant's key material leaks; (ii) bodyhash-mismatch amplification — provider-managed signers commonly default to c=simple/simple canonicalization which is brittle under per-tenant content-type variance; (iii) permerror amplification — provider-side _domainkey RR-set rotation without corresponding selector-naming coordination produces NXDOMAIN at the receiver's per-message DKIM evaluator; and (iv) temperror amplification — provider's DNS-infrastructure SERVFAIL during the per-message receiver-side DKIM key fetch. The shared-hosting spoke also documents the per-account escalation path to operator-controlled per-tenant DKIM selectors when the provider-managed default signer's failure-mode amplification crosses the operator's acceptable baseline. Read the shared-hosting spoke when diagnosing DKIM-fail aggregate-row clusters tied to provider-managed signing infrastructure outside the cPanel cohort, when composing per-tenant DKIM-failure remediation runbooks across heterogeneous control-panel customer-domain footprints, or when attributing dkim=temperror rows to provider-side DNS-infrastructure outages on the <selector>._domainkey.<tenant> leaf during provider maintenance windows.
• DMARC for transactional email — the TRANSACTIONAL-ESP-WORKLOAD-AS-DKIM- FAILURE-MODE-AMPLIFIER companion to THIS DKIM-failure-class catalogue. Where THIS page catalogues the seven RFC 6376 §3.9 + RFC 8601 §2.7.1 receiver-side DKIM verdict keywords (none / neutral / pass / fail / policy / temperror / permerror) along with the structural failure-mode taxonomy each verdict subdivides into (body-hash mismatch / signature-tag invalidity / header-list scoping omission / canonicalization mismatch / public-key DNS-resolution failure / RSA-key-too-small / l= drift / multi-signature precedence ambiguity / expired-key drift / replay- protection rejection), the dmarc_for_transactional_email spoke is the PER-TRANSACTIONAL-ESP-WORKLOAD-PROFILE companion documenting how each transactional ESP's deployment topology amplifies a SPECIFIC subset of the failure-class catalogue: (i) shared-MTA relay- rewriting body-modification failure amplification at SendGrid / Mailgun / Amazon SES — transactional ESPs operate shared-MTA relay infrastructure that subtly modifies message bodies (link- tracking URL substitution, open-pixel injection, footer-appending, character-set renormalization) BETWEEN the publisher's signing point and the receiver's verifying point, producing the canonical body-hash mismatch dkim=fail verdict documented in THIS catalogue's body-hash section; (ii) on-behalf-of-tenant d= default failure-class amplification — most transactional ESPs DEFAULT to signing with their own service-domain d= (SendGrid d=sendgrid.net, Mailgun d=mailgun.org, Amazon SES d=amazonses.com) producing the dkim=pass+DMARC-unaligned outcome the dkim_alignment_with_dmarc spoke documents; (iii) tenant- managed DKIM CNAME-delegation propagation- window temperror amplification — transactional ESPs require tenant-side CNAME publication for DKIM-domain alignment, and the receiver-side CNAME- chase-and-TXT-fetch produces dkim=temperror verdicts when either layer is mid-propagation; (iv) per-customer-stream IP-rotation and selector-rotation failure-class interaction — transactional ESPs rotate IPs and signing selectors at cadences faster than the receiver-side DNS-cache TTL, producing intermittent dkim=permerror on rotation- windows. Read the transactional-email spoke when an operator using a transactional ESP reports a high background-noise dkim=fail / dkim=permerror / dkim=temperror rate that this page's protocol-level catalogue catalogues as a verdict-class but does NOT attribute to the operationally-distinct ESP-side amplifier mechanisms.
• DMARC alignment — the alignment-evaluation rules that translate dkim=pass into DMARC outcomes. Section toc-alignment above is a summary; this page is the deep dive.
• DKIM alignment with DMARC — the DKIM-specific deep dive on the dkim=pass + DMARC=fail failure-mode this page documents as a category but does not exhaustively diagnose. Where THIS page catalogues the seven DKIM verdict keywords (pass / fail / neutral / policy / temperror / permerror / none) at the RFC 6376 §3.9 protocol level, the alignment-with- DMARC page focuses narrowly on the cross-protocol failure mode that produces a dkim=pass verdict but a dmarc=fail verdict on the same message: the signed d= domain does not share an organisational suffix with the From: header domain. The page documents the canonical alignment- failure provenance patterns this verdict catalogue does not cover symptom-by- symptom: the onmicrosoft.com gotcha (Exchange Online signing with d=<tenant>.onmicrosoft.com when the message From: domain is the customer's vanity domain), the gappssmtp.com gotcha (Google Workspace signing with d=<domain>.gappssmtp.com when relayed without DKIM-signing-domain customisation), ESP shared-domain signing patterns (SendGrid, Mailchimp, Postmark, Mandrill signing with d=<esp-domain> unless CNAME-delegated authenticated- domain DKIM is configured), the adkim=r (relaxed, organisational-domain match) vs adkim=s (strict, byte- identical match) DMARC policy knob and the receiver-side decision tree, and the mitigation sequences for each pattern. Read this page first to understand WHAT a DKIM verdict means at the protocol layer, then jump to alignment-with-DMARC when the verdict catalogue says dkim=pass but your aggregate-report payload shows dmarc=fail on the same row.
• Reverse DNS (PTR) and FCrDNS explained — the PER-SOURCE-IP-RDNS-AND-FCrDNS- LEGITIMACY-SIGNAL-ORTHOGONAL-TO-PER-MESSAGE- DKIM-CRYPTOGRAPHIC-VERDICT companion to this DKIM-failures taxonomy reference. Where THIS page documents the per-message DKIM verdict catalogue (the seven RFC 6376 §3.9 + RFC 8601 keywords: pass, fail, neutral, policy, temperror, permerror, none), and the per-failure-mode catalogue (body-hash mismatch, signature-verification failure, signature-syntax permerror, weak-key rejection, signature-expiration, signed- header tampering, public-key-absence, canonicalization-mismatch), the reverse-DNS / PTR / FCrDNS spoke documents the per-source-IP rDNS publication discipline whose forward-confirmed PTR-then-A-lookup round-trip is a per-IP-identity signal the receiver-side message-acceptance pipeline runs at the PER-CONNECTION layer SEPARATE from the per-message DKIM evaluation at FOUR per-DKIM- failure-mode-vs-rDNS-attribution dimensions: (i) per-source-IP FCrDNS-pass with dkim=fail as publisher-side DKIM defect attribution narrowing — when the per-source-IP forward-confirmed rDNS resolves successfully (PTR resolves to a hostname whose forward A-lookup returns the same IP) but the per-message dkim verdict is fail / permerror, the root cause narrows to publisher-side DKIM publication defects (selector public-key truncation, canonicalization misconfiguration, key rotation cutover window) rather than IP-origin legitimacy — the rDNS spoke documents the per-IP FCrDNS-pass signal that excludes the attacker-controlled-IP class; (ii) per-source-IP FCrDNS-fail with dkim=fail as widened root-cause class — when the per-source-IP rDNS fails (NXDOMAIN PTR, or forward A-lookup returns a different IP) AND the dkim verdict is fail, the operator's root-cause analysis widens to include forwarder / replay / attacker / unconfigured-origin classes alongside the publisher-side DKIM defect classes THIS page catalogues — the rDNS spoke catalogues the per-receiver per-IP FCrDNS-validation discipline whose outcome co-classifies the per-message DKIM failure root cause; (iii) per-shared-IP-pool rDNS as ESP / forwarder per-message DKIM attribution disambiguator — when the per-source-IP PTR resolves to a known ESP / forwarder hostname (e.g. mail-out-NNN.<esp>.com, fwd-NNN.<forwarder>.com), the per-message dkim=fail verdict's root cause attribution shifts to per-ESP CNAME-delegated signing-domain misconfiguration (third-party- sender unenrolled in the publisher's DKIM- delegation contract) or per-forwarder body- rewriting (mailing-list footer injection) rather than publisher-side DKIM publication defects; (iv) per-IP rDNS-publication discipline as publisher-side legitimacy- signal authoring prerequisite — operators publishing DKIM records use the rDNS spoke's per-IP PTR + FCrDNS publication checklist to ensure every legitimate egress IP carries forward-confirmable rDNS, removing the FCrDNS-fail class from per-receiver per- IP per-message DKIM-failure root-cause analysis the AUTH-RESULTS dkim-verdict stream THIS page documents downstream consumes. Read the reverse-DNS / PTR / FCrDNS spoke when triaging an unexpected dkim=fail / dkim=permerror spike whose per-source-IP attribution to a publisher-side defect, a third-party ESP misconfiguration, a forwarder rewrite, or an attacker-controlled origin depends on the per-IP rDNS state the per- message DKIM evaluator does not surface directly.
• ARC explained — Authenticated Received Chain per RFC 8617. The protocol-level fix for forwarder-induced dkim=fail.
• DMARC aggregate reports — the rua XML schema reference that section toc-aggregate above summarizes.
• DMARC reporting pipeline (RUA/RUF end-to-end flow) — the DKIM-FAILURE-VERDICT-AS-PIPELINE- OBSERVABILITY-PAYLOAD companion to this DKIM-failures taxonomy reference. Where THIS page documents the four DKIM failure classes operators decode from the auth_results/dkim/result field on aggregate-report rows (bodyhash-mismatch = signature body hash bh= does not match the receiver-recomputed body hash; signature-mismatch = the b= RSA signature fails verification against the public key; permerror = the DKIM-Signature header is syntactically invalid or the public key cannot be retrieved; temperror = transient DNS failure retrieving the public key TXT record), the DMARC-reporting-pipeline spoke is the END-TO-END-AGGREGATE-FLOW companion documenting how those four verdict values traverse FIVE stages of the application-layer RUA aggregate-report pipeline that connects receiver-side evaluation to operator-side observability: (i) receiver- side per-message DKIM evaluation — the receiver's milter/MTA performs the per-message DKIM-Signature verification per RFC 6376 §5.7 and emits one of the four verdict values THIS page documents; (ii) per- source-IP aggregation into the 24-hour rua window — the receiver groups all messages from a given source IP into a single rua record with the per-verdict count per RFC 7489 §7.2.1; (iii) per-org- domain rua-XML dispatch to the operator's rua=mailto: collector — the receiver sends the daily rua XML to the address published at _dmarc.<org>; (iv) operator-side rua-XML ingestion and per-source-IP DKIM- failure-class trend analysis — operators ingest the rua XML into their analytics surface and segment the four DKIM failure classes per- source-IP to distinguish authoring- problems (permerror at canonical- senders = misconfiguration), key- rotation problems (signature- mismatch with high count = stale key cache), body-modification problems (bodyhash-mismatch with forwarder signatures = MLM modification), and transient problems (temperror = DNS retrieval); (v) rollout- blocker decision branching off DKIM-failure-class observability from the pipeline — each failure class drives a distinct rollout-blocker decision: permerror blocks p=quarantine until the DKIM-Signature is syntactically valid; signature-mismatch blocks until key rotation completes; bodyhash-mismatch routes to ARC chain-of-custody deployment for the MLM forwarder topology; temperror routes to the recursive- resolver reliability subsystem. Read the reporting-pipeline spoke alongside this DKIM-failure-class taxonomy when designing operator- facing analytics that must segment the rua DKIM-failure-class stream into the four rollout- blocker-decision-branch streams — the reporting-pipeline spoke is the canonical end-to-end aggregate- report-flow reference; THIS DKIM failures page is the canonical verdict-class-taxonomy companion documenting the four DKIM-specific verdict values whose downstream flow through the pipeline drives the per-failure-class rollout- blocker decision branches.
• DMARC monitoring & reporting analysis — the DKIM-FAILURE-VERDICT-CATALOGUE-AS- MONITORING-ANOMALY-DETECTION-INPUT-STREAM companion to this DKIM-failures-taxonomy reference. Where THIS page documents the four DKIM failure-verdict classes (bodyhash-mismatch, signature-mismatch, permerror, temperror) operators decode from the auth_results/dkim/result field per RFC 6376 §3.9, the DMARC-monitoring spoke is the OPERATIONAL DISCIPLINE that consumes those four failure-verdict-class trend streams as the per-failure-class anomaly-detection input the monitoring page's "anomaly detection patterns" section acts on. The DKIM-FAILURE-VERDICT-CATALOGUE-AS- MONITORING-ANOMALY-DETECTION-INPUT-STREAM cross-reference establishes FOUR structurally-distinct DKIM-failure-class- to-monitoring-KPI-mapping dimensions: (i) signature-mismatch-trend-spike-as- key-rotation-anomaly-detection-signal dimension — the signature-mismatch failure verdict THIS page documents is the canonical input the monitoring page's "key-rotation anomaly detection pattern" alerts on: a sudden signature-mismatch rate spike at a previously-clean per-source-IP cohort is the canonical signal of a stale-key- cache event during a key-rotation misconfiguration; the monitoring page's alert-threshold guidance (signature- mismatch rate > 5% on previously- clean cohorts triggers Sev-2 alert) directly references the per-class verdict taxonomy THIS page documents; (ii) bodyhash-mismatch-rate-as- MLM-forwarder-inventory-drift-detection- signal dimension — the bodyhash-mismatch failure verdict THIS page documents is the canonical input the monitoring page's "sender-inventory drift" KPI tracks: bodyhash-mismatch is the structurally-distinct verdict produced by mailing-list-manager body-modification (footer-rewrite / Subject-tag-prepend / list-archive-link- injection), so a bodyhash-mismatch rate spike at a per-source-IP cohort indicates an unmonitored MLM appeared in the sender inventory; the monitoring page's per-source-IP-inventory-drift alert-routing guidance is directly predicated on the bodyhash-mismatch- as-MLM-fingerprint observation THIS page's verdict-class taxonomy documents; (iii) permerror-rate- as-DKIM-configuration-regression- detection-signal dimension — the permerror failure verdict THIS page documents is the canonical input the monitoring page's "regression detection post-change" pattern alerts on: permerror is the receiver-side verdict that the DKIM-Signature header is syntactically invalid or the public-key TXT record cannot be retrieved at all, so a permerror rate spike immediately post-DKIM-DNS-edit is the canonical regression signal indicating the published TXT record is malformed or was deleted; the monitoring page's post-change regression-detection alert thresholds directly consume the permerror-as-regression-signal observation THIS page's verdict-class taxonomy documents; (iv) temperror- rate-as-receiver-side-DNS-resolver- outage-coverage-degradation-detection- signal dimension — the temperror failure verdict THIS page documents is the canonical input the monitoring page's "reporter coverage" KPI gates on: temperror is the receiver-side verdict that the public- key TXT record retrieval transiently failed, so a temperror rate spike concentrated at a single receiver-side reporter cohort indicates the receiver's recursive resolver infrastructure is experiencing transient retrieval degradation (rather than a publisher-side error); the monitoring page's per-reporter- cohort coverage-quality KPI explicitly excludes the temperror- rate-as-receiver-side-resolver-outage- signal class from per-publisher rollout- blocker decision-making, per the THIS- page-documented temperror-as-transient- DNS-retrieval-failure taxonomy. Read this monitoring spoke alongside THIS DKIM-failures verdict-class taxonomy when instrumenting the receiver-side DKIM-failure-class trend-detection dashboard that consumes the per- verdict-class trend streams as the operational-decision input.
• DMARC forensic reports (RUF / AFRF) — the per-message-failure companion to the aggregate-report rua summary feed — the per-message-failure RUF channel documenting the individual failed DKIM-signature evaluations whose four failure classes THIS page categorises (bodyhash-mismatch, signature-mismatch, permerror, temperror). Where THIS DKIM failures page documents the four-class TAXONOMY operators use to decode the auth_results/dkim/comment field on aggregate-report rows, the forensic-reports spoke documents the DEEPER per-message RUF channel publishing the redacted-headers of the individual failed messages whose DKIM-Signature triggered each failure-class verdict (RFC 6591 AFRF message-format byte-grammar — multipart/report MIME envelope with the machine-readable message/feedback-report body-part listing the failed auth_results and the redacted message/rfc822-headers body-part). RUF reports historically gave operators a real-time per-message feed of the failed DKIM-Signature header values for cryptographic-mismatch root-cause analysis; the spoke documents WHY this channel is now largely deprecated (Google does not send RUF; Microsoft sends only on explicit opt-in due to PII / GDPR exposure of the original message headers in the message/rfc822-headers body-part) and the modern aggregate-only RUA-driven alternative for DKIM-failure diagnostic workflow. Read the forensic-reports spoke when an operator deploying DKIM and seeing high bodyhash-mismatch counts in aggregate-report rows wants per-message DKIM-Signature header-level visibility — the GDPR analysis on the spoke determines whether ruf= publication is lawful at all for the operator's regulatory posture.
• DMARC troubleshooting — the operator's cross-symptom diagnosis guide for the full DMARC + SPF + DKIM + ARC pipeline.
• DMARC myths and misconceptions — the DKIM-FAILURE-CLASS-AS-PER- MISCONCEPTION-DEBUNKING-TARGET companion to this DKIM-failures-taxonomy reference. Where THIS page documents the four DKIM failure classes operators decode from the auth_results/dkim/result field on aggregate-report rows (bodyhash-mismatch, signature-mismatch, permerror, temperror), the myths-and- misconceptions spoke is the STAKEHOLDER-EDUCATION-AGAINST-FALSE-MENTAL- MODELS reference that debunks the per- failure-class misconceptions that drive operators toward incorrect remediation decisions. The DKIM-FAILURE-MYTH-DEBUNKING cross-reference establishes FOUR structurally-distinct dimensions where the myths-and-misconceptions spoke debunks operator-side misconceptions about the failure classes THIS page diagnoses: (i) "DKIM-fail in RUA always means the private key is compromised" misconception → debunked by the legitimate-bodyhash- mismatch-from-forwarder-footer-injection class — operators new to DMARC RUA stream consumption frequently interpret any non-pass DKIM verdict as a cryptographic-key-compromise incident; the myths spoke documents the RFC 6376 body- canonicalization semantics that make mailing-list footer injection, Reply-Munged-Subject prepending, and corporate disclaimer-rewrite a NORMAL operational baseline producing dkim=fail bodyhash-mismatch on legitimate sender traffic — debunking the cryptographic-compromise-first mental model that misdirects operators toward expensive key-rotation responses when the actual root cause is downstream MTA body- modification at a forwarder hop; (ii) "permerror is always a fatal publisher misconfiguration requiring immediate remediation" misconception → debunked by the transient-DNS-publication- window false-permerror class — operators emitting dkim=permerror in aggregate-report rows during legitimate DKIM-CNAME-delegation propagation windows (third-party-signer onboarding, per-selector rotation pre-publication, CNAME-chain TTL-bounded resolver-cache skew) often misinterpret the verdict as a permanent infrastructure defect and roll back the deployment; the myths spoke documents the RFC 6376 §6.1 permanent-vs-temporary-failure classification rule the receiver applies — many "permerror" verdicts the publisher sees in RUA are actually receiver-side DNS-resolver-cache propagation artifacts that resolve within the per-receiver TTL boundary without publisher action; (iii) "temperror is always benign and safe to ignore" misconception → debunked by the fail-soft-DKIM-evaluator- as-attacker-bypass-vector class — operators reading dkim=temperror as a receiver-side transient issue with no publisher consequence frequently ignore the verdict entirely; the myths spoke documents the per-receiver fail-soft DKIM-evaluator behaviour (where some receivers downgrade temperror to "pass" for deliverability reasons) that attackers exploit by deliberately inducing DNS-resolver timeouts at the receiver to defeat DKIM-strict policies — debunking the operator's "temperror = deliverability noise" mental model that masks the fail-soft-receiver-as- attacker-bypass-amplifier security implication; (iv) "any DKIM-fail row is a phishing attempt requiring incident response" misconception → debunked by the four-class-taxonomy-with-distinct-non- adversarial-signatures class — operators new to DKIM-failure-class triage frequently treat the entire dkim=fail verdict-population as monolithic phishing-attempt signal; the myths spoke documents how the FOUR distinct failure classes THIS page enumerates each carry a structurally-distinct legitimate-vs- adversarial signature ratio (bodyhash- mismatch is mostly forwarder-noise with sparse BEC-attempt overlay; signature- mismatch is mostly key-rotation overlap with sparse selector-spoofing overlay; permerror is mostly DNS-propagation artifact with sparse infrastructure- sabotage overlay; temperror is mostly deliverability noise with sparse deliberate-resolver-DoS overlay) — the myths spoke debunks the operator's verdict-class-conflation mental model with the per-class adversarial-signature discrimination framework. Read the myths-and-misconceptions spoke alongside this DKIM-failures taxonomy reference when onboarding new RUA-stream consumers or when calibrating the §10 monitoring discrimination heuristics — the spoke is the canonical stakeholder-education reference whose four myth-debunking dimensions directly map to the four DKIM-failure classes this page catalogues, ensuring per-verdict remediation decisions are anchored in RFC-grounded receiver-side evaluation semantics rather than operator-side false-mental-model heuristics.
• Business Email Compromise (BEC) — the financial-fraud threat scenario that exploits the DKIM failure-class diagnostic blindspots — the operational deep dive on the financial-fraud threat scenario that deliberately exploits the DKIM-failure-class diagnostic blindspots documented on this page. Where THIS page is the four-class DKIM failure TAXONOMY (bodyhash-mismatch, signature- mismatch, permerror, temperror) used for decoding the auth_results/dkim/comment field on aggregate-report rows, the BEC spoke documents the THREAT SCENARIO that turns operationally- accepted DKIM failure modes into attacker bypass vectors. Three concrete BEC-exploitation patterns the BEC spoke catalogues map directly to the failure classes on THIS page: (1) the recurring-forwarder-bodyhash noise class trains operators to ignore DKIM- fail RUA signals — BEC attackers deliberately spoof at p=none with malformed DKIM-Signature headers from NEW sending IP blocks knowing operators will dismiss the rows as "forwarder noise" until the wire-transfer request is already executed, (2) the selector-key-mismatch failure class spikes legitimately during key-rotation overlap windows — BEC attackers deliberately time spoofing campaigns to rotation windows because the elevated DKIM-fail baseline masks attack traffic in the RUA stream, (3) the temperror class generated by DNS-resolver timeouts is used by BEC attackers to defeat DKIM-fail-soft policies at receivers that downgrade temperror to "pass" for deliverability reasons. Where the failure-class taxonomy on THIS page is the DIAGNOSTIC reference operators use to triage RUA rows, the BEC spoke is the THREAT-MODEL reference that explains how attackers monetize the diagnostic blindspots — including the precise attacker-vs-noise discrimination heuristics that distinguish recurring- forwarder-bodyhash noise from BEC-attempt bodyhash failure, and the wire-transfer business-context signals that flag a DKIM-fail row as BEC-relevant rather than operationally- ignorable. Read the BEC spoke when calibrating the §10 monitoring discrimination heuristics for BEC-attempt detection — the spoke is the authoritative threat-model reference for the financial-fraud scenario that gives DKIM-failure-class triage its business-impact stakes.
• Phishing protection — the DKIM-VERDICT-CLASS-AS-PHISHING- ATTEMPT-CLASSIFIER companion to this DKIM-failures taxonomy reference. Where THIS page documents the four DKIM failure classes operators decode from the auth_results/dkim/result field on aggregate-report rows (bodyhash-mismatch, signature-mismatch, permerror, temperror), the phishing- protection spoke is the DEFENSE-PROGRAM- EFFECTIVENESS-AND-PER-VERDICT-CLASSIFIER companion documenting how each of the four verdict classes carries a STRUCTURALLY-DISTINCT phishing-attempt signature at the publisher's RUA- visibility horizon, turning the verdict- taxonomy into an active phishing-defense observability stream: (i) dkim=none on publisher's domain → unsigned-spoof phishing-attempt classifier — the canonical phishing-attacker who cannot forge DKIM-Signature headers simply omits them entirely and relies on the publisher's p=none/pct<100 deployment gap; the phishing- protection spoke documents the DMARC- enforcement-ramp playbook that closes this attack class by advancing p=quarantine → p=reject at pct=100; (ii) dkim=fail bodyhash-mismatch on captured-and- modified messages → DKIM-replay-with- body-substitution phishing-attempt classifier — the phishing- attacker captures a legitimate signed message and modifies the body bytes (URL-substitution, cookie-jar substitution, body-content-replacement for the phishing payload) before rebroadcasting to attacker-chosen recipients; the receiver emits bodyhash-mismatch verdict EXACTLY matching THIS page's failure-class signature, and the phishing-protection spoke documents the per-source_ip clustering pattern that distinguishes attacker-replay traffic from legitimate- forwarder-modification noise; (iii) dkim=permerror on attacker-exploited DNS misconfiguration → publisher-side-DNS-vulnerability- exploitation phishing-attempt classifier — the phishing- attacker who observes the publisher's DKIM-record DNS misconfiguration (revoked-not-removed selector, truncated TXT record, malformed p= tag) times the phishing campaign to the UNTIL-FIXED window; the phishing-protection spoke documents the DNS-monitoring-and-rapid-remediation discipline that closes the exploitation window the receiver-side permerror verdict signals; (iv) dkim=temperror on attacker-timed DNS-outage attack → publisher-NS-outage-window-exploitation phishing-attempt classifier — the phishing-attacker who has positioned a DDoS-against-publisher-NS or BGP-route-misdirection times the campaign precisely during the outage window when the receiver cannot fetch the DKIM public key; the phishing- protection spoke documents the nameserver-redundancy + Anycast-DNS discipline that closes this attack- timing-window class. Read the phishing-protection spoke alongside this DKIM-failure-class taxonomy when designing the operator-side defense- program-effectiveness dashboard that must segment the auth_results/dkim/result stream into the per-phishing-attempt- class observability rollup — this page tells you WHAT the verdict means at the protocol level, the phishing- protection spoke tells you WHICH phishing-defense-program-effectiveness signal each verdict-class carries and which publisher-side defense layer (DMARC-policy-advancement, DNS- configuration-monitoring, NS-redundancy- engineering, MUA-banner-warning configuration) is the canonical remediation discipline.
• How attackers bypass weak DMARC — the DKIM-VERDICT-TAXONOMY-AT- RECEIVER-IS-PER-VERDICT-ATTACKER- BYPASS-ATTEMPT-CLASSIFIER companion to this DKIM-failure-class diagnostic reference. Where THIS page documents the FOUR DKIM FAILURE-CLASS TAXONOMY rows (bodyhash-mismatch, signature- mismatch, permerror, temperror) used for decoding the auth_results/dkim/comment field on aggregate-report rows, the attacker-bypass spoke documents how EACH of these failure-class verdicts carries a STRUCTURALLY-DISTINCT attacker-bypass-attempt signature at the publisher's RUA-visibility horizon, turning the verdict-taxonomy into an active attacker-bypass- classifier evidence stream. FOUR structurally-distinct DKIM-VERDICT- AS-ATTACKER-BYPASS-ATTEMPT-CLASSIFIER dimensions emerge from the receiver-side per-message-verdict evaluation. (1) dkim=none-as-unsigned- message-pass-via-relaxed-DMARC- attacker-bypass classifier — the bypass-spoke documents how an attacker who possesses neither the publisher's private key nor a legitimate signature simply omits the DKIM-Signature header entirely and relies on the publisher having published a weak DMARC posture (p=none aggregate-only, OR p=quarantine pct=<100 with the dkim-unsigned cohort below the threshold, OR no DMARC record at all). THIS page's dkim=none-verdict documentation is the receiver-side signal of this bypass attempt; the attacker-bypass spoke documents WHY the attacker chose this verdict-path as the lowest-cost bypass vector. (2) dkim=fail-bodyhash- mismatch-as-DKIM-replay-or-tamper- attacker-bypass classifier — the bypass-spoke documents how an attacker who has captured a legitimate DKIM-signed message from the target organisation replays the captured signed bytes to attacker-chosen recipients (the DKIM-replay attacker-bypass vector class — RFC 6376's cryptographically-valid-but- rebroadcasted-message bypass). WHERE the attacker has MODIFIED the body bytes since capture (cookie-jar substitution, URL rewriting, body-hash-attack-via- l=-tag-truncation per RFC 6376 §3.5), the receiver emits dkim=fail bodyhash-mismatch EXACTLY MATCHING the verdict signature THIS page documents. The bypass-spoke documents the attacker's strategy at each choice-point; THIS page documents the receiver's verdict-emission machinery the operator's RUA consumer parses to surface the campaign. (3) dkim=permerror-as- DNS-record-misconfiguration- exploitation-attacker-bypass classifier — the bypass- spoke documents how an attacker who has observed the publisher's DKIM-record DNS misconfiguration (revoked-but-not-removed selector, syntactically-broken p= tag, missing v=DKIM1 tag, truncated TXT-record above 255-byte continuation boundary) exploits the publisher's UNTIL- FIXED window during which the receiver emits dkim=permerror and the publisher's RUA stream records permerror-verdict without distinguishing legitimate-publisher misconfig from attacker-exploitation. THIS page's dkim=permerror- verdict documentation is the receiver-side primitive; the attacker-bypass spoke documents the threat-actor's exploitation timing window. (4) dkim=temperror-as- DNS-resolver-outage-window- attacker-bypass classifier — the bypass-spoke documents how an attacker who has observed the publisher's authoritative- nameserver outage window (DDoS-against-publisher-NS, BGP-route-misdirection of NS traffic, registrar-side outage) sends the attack messages precisely during the outage window when the receiver's DNS resolver cannot fetch the DKIM-public-key TXT record and emits dkim=temperror per RFC 6376 §6.1 — the publisher loses RUA visibility precisely during the same window when attacker-bypass-vector exploitation is occurring. THIS page's dkim=temperror- verdict-vs-temporary-DNS-failure- documentation is the receiver-side primitive; the attacker-bypass spoke documents the threat-actor's timing-window exploitation pattern. Read the attacker-bypass spoke alongside THIS page when the RUA-stream consumer is decoding receiver-side verdict rows: this page tells you WHAT the verdict MEANS at the cryptographic-and-DNS layer, the bypass-spoke tells you WHAT ATTACK PATTERN the verdict SIGNATURE-MATCHES against the publisher's expected baseline AND WHY each verdict-class functions as an active per- message attacker-bypass-attempt classifier.
• DKIM-Signature header tag anatomy — the DKIM-FAILURE-MODE-ATTRIBUTION- TO-SPECIFIC-SIGNATURE-TAG companion reference. Where this page documents the SEVEN RECEIVER-SIDE DKIM VERDICTS (none / neutral / pass / fail / policy / temperror / permerror per RFC 6376 §3.9 + RFC 8601 §2.7.1) and the per-verdict triage workflow, the signatures-explained spoke is the FIELD-LEVEL CANONICAL REFERENCE for the DKIM-Signature header tags whose specific values determine each verdict: a bh= body- hash mismatch produces dkim=fail (the body canonicalization layer's hash does not match the signed value), an s= selector lookup miss produces dkim=permerror (the s._domainkey.d TXT record does not resolve), a d= domain misalignment with the From: header produces a dkim=pass-but-DMARC-fail outcome (the signature verifies but DMARC alignment fails), an a= algorithm of rsa-sha1 produces dkim=policy under RFC 8301 strict- algorithm receivers, an h= signed-header-list missing From: produces dkim=permerror under RFC 6376 §3.5 (From: is mandatory in the signed-header list), and a missing DNS-published-public- key record produces dkim=temperror on DNS timeout or dkim=permerror on NXDOMAIN. Read the signatures- explained spoke alongside this page when correlating an aggregate-RUA dkim= verdict to the specific signature-header field that triggered it: this page gives the per-verdict triage workflow, the spoke gives the per-tag canonical anatomy, and together they form the end-to-end attribution chain from verdict (this page) back to the responsible tag value (the spoke).
• DMARC policy modes (p=none / p=quarantine / p=reject) — the DKIM-FAIL-VERDICT-AS-POLICY-MODE- ENFORCEMENT-INPUT companion to this DKIM failure-mode reference. Where THIS page documents the per-verdict triage workflow for the seven canonical dkim= status keywords (none, pass, fail, neutral, policy, temperror, permerror) a receiver emits per RFC 6376 §3.9 + RFC 8601 §2.7.1, the DMARC policy-modes spoke documents the publisher-side p=none / p=quarantine / p=reject policy-mode tag whose enforcement consumes the dkim= verdict THIS page diagnoses — a publisher-side enforcement dimension structurally DOWNSTREAM of every dkim= verdict triage decision on this page because (i) the dkim= verdict is the per-message authentication-RESULT input; the p= policy-mode is the publisher-side enforcement DIRECTIVE — together with the SPF-pass/fail input they form the complete DMARC enforcement decision the receiver evaluates per RFC 7489 §6.3, (ii) under p=reject, a sustained dkim=fail / dkim=permerror verdict regression (the failure-modes on this page) produces immediate receiver-side rejection of the publisher's mail — an outage that cannot be debugged without the dkim= verdict triage workflow this page documents, (iii) the p=quarantine mode is the operationally-correct staging mode for a domain whose dkim=fail rate is in the 1-3% range — quarantine isolates the false-positive risk while the operator works through the dkim=fail triage workflow this page documents. Read the DMARC policy-modes spoke when escalating from per-verdict DKIM debugging into the publisher-side policy-mode strategic decision — particularly when the operator is weighing whether the steady-state dkim=fail rate is low enough to advance from p=quarantine to p=reject without producing material false-positive rejections of legitimate mail.
• DANE for SMTP (RFC 7672) explained - the DANE-VALIDATED-SMTP-DELIVERY-AS- TRANSPORT-LAYER-PREREQUISITE companion to this DKIM-failure-class catalogue. Where THIS page documents the seven dkim= verdict classes (none / pass / fail / policy / neutral / temperror / permerror per RFC 6376 §3.9) the receiver emits AFTER successfully accepting the message at the SMTP layer and computing the per-message DKIM signature verdict, the dedicated DANE deep-dive documents the structurally- ORTHOGONAL transport-layer-validation step that EXECUTES BEFORE the receiver-side DKIM verifier ever processes the message - producing a per-DANE-validating-receiver- cohort DKIM-fail-rate distribution structurally-distinct from the per-non- DANE-validating-receiver-cohort distribution at FOUR DANE-vs-DKIM-pipeline- coordination dimensions: (i) DANE TLSA-validation-failure at the SMTP connection terminates the message stream BEFORE the receiver can ever evaluate DKIM - the message never reaches the DKIM verifier, never produces an Authentication-Results: ...; dkim=X verdict, never appears in the receiver's RUA aggregate stream as a per-message DKIM- verdict row, but DOES produce a transport- layer-failure row in the receiver's TLS-RPT stream if the receiver publishes TLS-RPT - the structurally-distinct DANE-as-DKIM- evaluation-blocker pattern surfaces in RUA streams as "DKIM verdict counts from DANE- validating receiver X DROPPED compared to the baseline whilst the same publisher's DKIM signing is functioning correctly" symptom class; the DANE deep-dive documents the DANE-validation-failure-as- upstream-DKIM-evaluation-blocker coordination contract; (ii) DANE- validating receiver populations (the IronPort cohort, the on-prem M365 hybrid cohort with DANE enabled since 2022, the German DE-Mail cohort, the DNSSEC-anchored receiver populations) produce a STRUCTURALLY- DIFFERENT per-source-IP DKIM-verdict distribution from non-DANE-validating receivers because DANE-validating receivers filter out a subset of legitimate-but- transport-misconfigured sender mail BEFORE the DKIM verifier sees it - operators consuming RUA streams from mixed-DANE- validation-cohort receiver populations must segment per-receiver DKIM-fail-rate analysis by DANE-validation status to avoid attributing transport-layer-evidence artifacts to DKIM-signing-side root causes; the DANE deep-dive documents the per-receiver-cohort DANE-validation- status-as-DKIM-fail-rate-baseline-modifier framework; (iii) DANE-cert-rotation propagation cycles (per RFC 7671 §8 dual- TLSA-publication overlap discipline) produce a TRANSIENT per-DANE-validating- receiver-cohort DKIM-fail-rate spike that is NOT a DKIM-signing-side root cause - the publisher's cert rotation produces a window during which DANE-validating receivers temporarily reject delivery, producing a TRANSIENT collapse in the DKIM-verdict-row count from that receiver cohort while non- DANE-validating receivers continue producing their baseline DKIM-verdict distribution - operators must reconcile DKIM-fail-rate spikes against cert-rotation cutover windows when DANE-validating receivers appear in the receiver-population set; the DANE deep-dive documents the cert- rotation-cutover-as-DKIM-fail-rate-spike- cause attribution framework; and (iv) DANE-prerequisite zone-DNSSEC-state transitions (parent-zone DS-record roll, zone-DNSKEY-record expiry, zone-RRSIG-record expiry) cascade to TLSA-validation-failure which cascades to SMTP-rejection which cascades to absence-of-DKIM-verdict-row in the receiver's RUA stream - a multi-protocol- layer failure cascade that produces a symptom indistinguishable from a DKIM-signing- side root cause without segmenting by DANE- validation status and DNSSEC-state; the DANE deep-dive documents the multi- layer DNSSEC-DANE-DKIM cascade-attribution diagnostic checklist. Read THIS page when the operator is interpreting per-DKIM- verdict-class baselines and per-source-IP DKIM-fail-rate distributions in RUA streams; read the dedicated DANE deep-dive alongside when the receiver-population set includes DANE-validating receivers and the operator must segment DKIM-verdict counts by DANE- validation-status to avoid attributing transport-layer DANE-validation failures to DKIM-signing-side root causes - the DANE spoke is the authoritative transport- layer-validation companion whose four DANE-vs-DKIM-pipeline coordination boundaries this DKIM-failure-class catalogue is the application-layer-verdict-distribution consumer for.
• DMARC deployment checklist — the END-TO-END DEPLOYMENT-PHASE-AS-DKIM- FAILURE-PREVENTION companion to THIS DKIM- verdict-class catalogue. Where THIS page documents the seven RFC 6376 §3.9 + RFC 8601 §2.7.1 receiver-side DKIM verdict keywords (none / neutral / pass / fail / policy / temperror / permerror) as the OBSERVED-RECEIVER-SIDE-OUTCOMES of a deployed DKIM signing pipeline, the deployment checklist documents the ORDERED-PRE-FLIGHT- CONFIGURATION-SEQUENCE that produces a deployment whose receiver-side verdict distribution converges on dkim=pass across the major mailbox-provider population (Gmail / Microsoft / Yahoo / Mail.ru / Comcast / Apple iCloud / AOL). Four DEPLOYMENT-PHASE-VS-DKIM-VERDICT axes the checklist documents that this page's verdict catalogue is the post-deployment observability consumer of: (1) DKIM publication phase — the checklist's "publish DKIM TXT at <selector>._domainkey" step with the byte-level public-key splitting discipline (Cloudflare auto-split / GoDaddy manual 255-byte chunks / BIND ("..." "...") concatenation form) whose CORRECT execution preempts the dkim=permerror wave that follows a registrar UI truncating the public key without splitting, and whose INCORRECT execution produces the dkim=permerror verdict documented in section 5 of this page; (2) monitoring phase — the checklist's "deploy p=none with rua= reporting" step whose 24-72 hour observation window emits the dkim=fail / dkim=neutral / dkim=temperror / dkim=permerror / dkim=policy verdicts THIS page catalogues at the FIRST observable opportunity — BEFORE the operator commits to p=quarantine or p=reject enforcement and BEFORE the verdict distribution affects legitimate-message delivery; (3) third-party sender enumeration phase — the checklist's "audit the rua-stream for unsigned tenants" step whose per-third-party-sender DKIM-signing-or-not decision produces the dkim=none verdict documented in section 2 of this page for every tenant the operator decides to leave unsigned (relying on SPF-alone for that tenant); (4) enforcement commitment phase — the checklist's p=none → p=quarantine → p=reject ramp whose per-step DKIM-verdict-distribution observation gate prevents the operator from flipping enforcement while the rua stream still emits a non-zero dkim=fail / dkim=permerror background rate that would affect legitimate-message delivery once enforcement is committed. Read the deployment checklist BEFORE shipping DKIM signing on a new domain to preempt the verdicts this page catalogues; read THIS page AFTER deployment when interpreting the verdict-distribution rua-stream that the checklist's monitoring phase emits.
• DMARC for Microsoft 365 — the M365-TENANT-DEPLOYMENT-CONTEXT companion to this DKIM-failure-mode verdict-catalogue reference. Where THIS page documents the seven RFC 6376 §3.9 DKIM verdict status keywords with per- verdict root-cause attribution + per- verdict mitigation playbook, the M365 deployment spoke is the M365-TENANT- DEPLOYMENT-SPECIFIC verdict-attribution REFERENCE documenting how the same seven-verdict catalogue maps onto the M365 cloud-only tenant deployment specifics every Exchange Online operator must coordinate. Concretely the spoke documents FOUR per-M365- tenant-configuration-vs-DKIM-verdict- root-cause-attribution dimensions: (i) per-tenant selector1-<tenant>._domainkey.<d-domain> + selector2-<tenant>._domainkey.<d-domain> CNAME-delegation publication is the M365-tenant per-message DKIM verdict publication-discipline primitive — the M365-deployment spoke documents the per-tenant CNAME-delegation publication-discipline contract every Exchange Online operator must satisfy so the per-message DKIM-Signature verification at receiver-side resolves the per-tenant Microsoft-managed rotating key from selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com — the dkim=permerror NXDOMAIN verdict THIS page catalogues at the CNAME-delegation tier maps onto the per-tenant deployment failure mode the M365-deployment spoke documents; (ii) per-tenant Defender Set-DkimSigningConfig + Rotate-DkimSigningConfig automation cadence is the M365-tenant DKIM- signing-infrastructure operational discipline — the dkim=fail body-hash- mismatch verdict THIS page catalogues during dual-selector overlap-window rotation maps onto the per-tenant Rotate-DkimSigningConfig timing discipline the M365-deployment spoke documents as the dual-selector overlap-window publication-discipline coordination every Exchange Online operator must apply to prevent receiver-side cache-miss against the rotating key during the transient-key-substitution window; (iii) per-tenant tenant.onmicrosoft.com default-domain unconfigured-CNAME- delegation gotcha is the M365-tenant DMARC-non-alignment failure-mode — the dkim=pass with policy_evaluated.dkim=fail DMARC-non-aligned verdict THIS page catalogues maps onto the per-tenant unconfigured-default-domain CNAME-delegation failure-mode the M365-deployment spoke documents — when the per-tenant selector1-<tenant>._domainkey.<org-domain> CNAME is not published, M365 signs with the d=<tenant>.onmicrosoft.com default-domain key emitting dkim=pass against the wrong organisational domain; and (iv) per-tenant Exchange Online Protection cloud-egress IP-pool DKIM-signing-infrastructure- stability dependency is the M365- tenant DKIM-signing-coverage operational invariant — the dkim=none / dkim=temperror / dkim=policy verdicts THIS page catalogues during transient EOP-side signing-infrastructure outage maps onto the per-tenant EOP-cloud-egress IP-pool dependency the M365-deployment spoke documents as the per-tenant DKIM-signing- coverage availability KPI every Exchange Online operator must monitor via aggregate-report stream. Read the M365-deployment spoke ALONGSIDE this DKIM-failure-mode verdict-catalogue reference when diagnosing per-M365-tenant per- message DKIM verdict root causes — the spoke documents how the seven- verdict catalogue THIS page establishes maps onto the per-M365- tenant deployment-time configuration primitives every Exchange Online operator must coordinate.
• SPF forwarding issues — the PER-FORWARDER-ENVELOPE-REWRITE-AS- CROSS-AUTHENTICATION-CO-FAILURE-MODE companion to this DKIM-failures-explained reference. Where THIS page catalogues the seven RFC 6376 §3.9 DKIM verification result enums (none, pass, fail, policy, neutral, temperror, permerror) and the per-message body-modification, header- modification, key-rotation, and clock-skew failure root-causes that drive each verdict, the SPF-forwarding-issues spoke is the ENVELOPE-MAIL-FROM-REWRITE-COMPANION documenting how the SAME per-forwarder hop that breaks DKIM via mailing-list body modification ALSO breaks SPF via envelope- MAIL-FROM rewriting at FOUR per-forwarding- hop cross-authentication-coupling dimensions: (i) per-mailing-list- expander forwarder simultaneously breaks DKIM via Subject:/footer body modification AND SPF via envelope-MAIL-FROM rewrite to the list's bounce-handler domain — the canonical mailing-list-induced cross- authentication failure mode where BOTH message-layer DKIM and envelope-layer SPF fail at the receiver, leaving ARC-chain inspection as the only receiver-side forwarder-recognition signal; the SPF- forwarding-issues spoke catalogues the envelope-rewrite half of this cross- authentication co-failure mode that the DKIM-failures verdict THIS page documents is the message-layer half of; (ii) per-account-forwarding (Gmail filter- forwarding, .forward redirection, Outlook rule-forwarding) preserves DKIM body-bytes but rewrites envelope-MAIL-FROM to the forwarding-account domain — the canonical per-user forwarding pattern where DKIM SURVIVES (forwarder transparent to body bytes, no Subject:/footer modification, no DKIM canonicalization violation) but SPF FAILS (envelope rewrite breaks the SPF-MAIL-FROM-vs-published- record-IP match); the SPF-forwarding- issues spoke catalogues this DKIM-survives- SPF-fails forwarding signature that the DKIM-verdict catalogue THIS page documents the cryptographic-survival half of; (iii) per-SRS-rewriter (Sender Rewriting Scheme) deployment as the canonical per- forwarder SPF-rescue primitive that deliberately ALTERS envelope-MAIL-FROM identity in a way the DKIM verifier MUST treat as orthogonal — the SPF- forwarding-issues spoke catalogues the SRS forwarder-rewriting RFC primitive that rescues SPF at the cost of orphaning the downstream DMARC-alignment signal, which the DKIM verifier on THIS page treats as independent of envelope identity (DKIM binds the d= signing domain to the message body cryptographically, NOT to the envelope-MAIL-FROM the SRS rewriter manipulates); (iv) per-forwarder ARC-chain sealing as the receiver-side per-hop cross-authentication-evidence primitive that preserves the originating- hop DKIM-pass-verdict AND SPF-result across forwarders that would otherwise invalidate both — the SPF- forwarding-issues spoke catalogues ARC- sealing as the receiver-side per-hop SPF-and-DKIM-evidence preservation primitive that the DKIM verdict catalogue THIS page documents the message-layer survival evidence consumer of. Read the SPF- forwarding-issues spoke alongside this DKIM-failures-explained reference when triaging per-forwarded-message DMARC-fail incidents whose root-cause spans both envelope-layer SPF-rewrite AND message- layer DKIM-modification failure modes.
• SPF for Microsoft 365 — the PER-M365-TENANT-SPF-PUBLICATION-AS- SIBLING-MESSAGE-LAYER-AUTHENTICATION- PUBLICATION companion to this DKIM- failures-explained reference. Where THIS page catalogues the seven RFC 6376 §3.9 DKIM verification result enums (none, pass, fail, policy, neutral, temperror, permerror) and the M365-tenant deployment- context per-verdict root-cause taxonomy (per-tenant selector1/selector2-CNAME publication, per-tenant Set-DkimSigningConfig cadence, per-tenant tenant.onmicrosoft.com default-domain unconfigured-CNAME gotcha), the SPF-for-Microsoft-365 spoke is the SIBLING PER-TENANT MESSAGE-LAYER AUTHENTICATION PUBLICATION reference whose per-tenant SPF publication discipline is co-emitted with the per-tenant DKIM publication discipline THIS page documents the verification-outcome taxonomy of at FOUR per-M365-tenant SPF-vs-DKIM cross- authentication-publication coupling dimensions: (i) per-M365-tenant SPF publication (DNS TXT v=spf1 include:spf.protection.outlook.com -all) as sibling per-tenant message-layer authentication-publication primitive to per-tenant DKIM publication (DNS CNAME selector1-<tenant>._domainkey + selector2-<tenant>._domainkey) — both per-tenant DNS-anchored authentication-publication primitives are co-emitted by the per-tenant deployment topology; the SPF-for-M365 spoke catalogues the per-tenant SPF half whose per-tenant publication discipline parallels the per-tenant DKIM publication discipline whose seven verdict enums THIS page catalogues; (ii) per-M365-tenant SPF-evaluation outcome (SPF-pass / SPF- fail / SPF-softfail / SPF-permerror / SPF- temperror) at receiver-side Workspace-or- peer-inbound vs per-tenant DKIM-evaluation outcome (the seven RFC 6376 §3.9 enums) at the SAME receiver-side Authentication-Results header — each per-M365-tenant message at any receiver-side mailbox-provider produces BOTH an SPF-evaluation result AND a DKIM- evaluation result in the Authentication- Results header; the SPF-for-M365 spoke catalogues the per-tenant SPF-evaluation outcome taxonomy whose per-tenant diagnostic context complements the per- tenant DKIM-evaluation outcome taxonomy THIS page catalogues; (iii) per- M365-tenant spf.protection.outlook.com include-cascade misconfiguration as per- tenant SPF-permerror root-cause class sibling to per-tenant CNAME-delegation gotcha as per-tenant DKIM-permerror root- cause class — the SPF-for-M365 spoke catalogues the per-tenant include- cascade overflow / mistyped-include macro / cousin-tenant-include macro permerror root-cause classes whose per- tenant diagnostic-context parallels the per-tenant DKIM CNAME-delegation gotcha permerror root-cause class THIS page catalogues; (iv) per-M365-tenant SPF-pass + per-tenant DKIM-pass combination as load-bearing per-tenant DMARC-pass precondition vs per-tenant SPF-fail + per-tenant DKIM-fail combination as canonical per-tenant receiver-side DMARC-fail root-cause class — the cross-protocol per- tenant SPF-and-DKIM verdict combination is the load-bearing per-tenant DMARC- evaluation input every receiver-side DMARC evaluator consumes; the SPF-for- M365 spoke catalogues the per-tenant SPF publication discipline whose per-tenant verdict combines with the per-tenant DKIM verdict taxonomy THIS page catalogues at receiver-side DMARC evaluation. Read the SPF-for-Microsoft-365 spoke alongside this DKIM-failures- explained reference when triaging per- M365-tenant per-message DMARC-fail incidents whose root-cause attribution requires the per-tenant SPF + DKIM cross- authentication verdict pair every receiver-side DMARC evaluator consumes.
• Email security glossary — the SECURITY-OPERATIONS-AND-THREAT- TAXONOMY-VOCABULARY-CATALOGUE companion to this DKIM-failures- explained operator-reference. Where THIS page catalogues the seven receiver-side DKIM-verdict keywords (dkim=pass, dkim=fail, dkim=neutral, dkim=temperror, dkim=permerror, dkim=policy, dkim=none) at the RFC 6376 §3.9 protocol layer, the glossary spoke catalogues the SOC-and-IR vocabulary every downstream analyst applies when interpreting these verdicts against threat-actor-taxonomy and email- attack-taxonomy at four DKIM-failure- verdict-to-security-operations- vocabulary coupling dimensions: (i) dkim=fail on inbound mail purporting to originate from a known-executive sender as a load-bearing input to the glossary's phishing-taxonomy entries (bec, ceo-fraud, invoice-fraud, spear-phishing, whaling) consumed by the SOC analyst triaging a suspected executive-impersonation incident — the glossary's BEC-variant catalogue documents the per-fraud-pattern operator response (out-of-band verification thresholds, dual- approval workflows, executive- impersonation domain monitoring) that the dkim=fail verdict this page documents structurally consumes as the message-layer authentication signal whose interpretation drives the per-incident IR-playbook selection; (ii) dkim=permerror and dkim=temperror as load-bearing inputs to the glossary's IR-lifecycle entries (incident-response, detection-analysis, containment, ioc, mttd-mttr, dwell-time) consumed by the SOC analyst during the detection-and-analysis phase — the glossary's NIST SP 800-61r2 IR-lifecycle catalogue documents the per-phase analyst tradecraft applied to per-message DKIM-error- class evidence (the dkim=permerror verdict is itself an IoC class at the Authentication-Results header layer whose pattern frequency feeds the SOC's MTTD KPI, and whose root- cause attribution informs the per-publisher remediation runbook), bridging the protocol-layer verdict keyword this page documents to the operational-response vocabulary the glossary defines; (iii) dkim=policy verdicts (RFC 8301 algorithm or key-size policy violations) as load-bearing inputs to the glossary's defense-in-depth entries (defense-in-depth, secure-email-gateway, phishing-resistant-mfa, zero-trust) consumed by the operator hardening the cross-layer defensive posture — the glossary's defense-in-depth catalogue documents the per-layer control (perimeter, gateway, endpoint, identity, data, response) that the dkim=policy-driven SHA-1-deprecation / sub-1024-bit-key-rejection receiver-side enforcement this page documents is one operationally- relevant control among, anchoring the algorithm-rotation discipline every gateway-class SEG product eventually catches up to; (iv) aggregate-rate DKIM-failure distributions (per-source-IP per- selector per-day) as load-bearing inputs to the glossary's threat- intelligence and threat-modelling entries (threat-intelligence, mitre-attack, kill-chain, diamond-model, ttp, pyramid-of-pain) consumed by the threat-hunter pivoting from per-message verdict- evidence to per-adversary TTPs — the glossary's MITRE ATT&CK + kill-chain + Diamond Model catalogue documents the analytic scaffolding the threat-hunter applies when correlating per- receiver per-message DKIM-failure evidence into per-adversary infrastructure pivots, anchoring the protocol-layer verdict evidence this page documents to the threat-intelligence pipeline the glossary defines. Read the glossary alongside this DKIM- failures-explained reference when building the per-incident IR- playbook that consumes per-message DKIM-verdict evidence and operationally translates it into the SOC + IR + threat-intelligence + defense-in-depth vocabulary every downstream analyst consumes.
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN-BIMI-LOGO- RENDERING-DISCIPLINE-AS-LOAD-BEARING- DOWNSTREAM-CONSUMER-OF-PER-MESSAGE-DKIM- FAILURE-VERDICT-CATALOGUE companion to this per-message DKIM-verdict status-keyword catalogue. Where THIS page documents the SEVEN RFC 6376 §3.9 / RFC 8601 §2.7.1 per- message DKIM-verification status keywords (none when no DKIM-Signature header existed, pass on successful cryptographic verification, fail on signature-or-body-hash mismatch, policy on local policy rejection, neutral on verification-skipped, temperror on transient DNS failure, permerror on malformed record), the BIMI spoke documents the FOUR PER- PUBLISHER-PER-DOMAIN-BIMI-LOGO-RENDERING- ELIGIBILITY-DIMENSIONS structurally gated on the per-message DKIM-verdict catalogue THIS page documents: (i) per- publisher per-receiver per-message BIMI- rendering ELIGIBILITY GATED on per-message DKIM-aligned pass — ONLY a per-message DKIM-aligned-pass verdict produces per-receiver per-message BIMI-rendering eligibility; per-message DKIM verdicts of none / fail / policy / neutral / temperror / permerror ALL defeat per-message BIMI-rendering regardless of every other BIMI-precondition surface (DMARC enforcement, BIMI l=-tag publication, VMC certificate-binding); (ii) per- publisher per-domain BIMI-rendering-rate FLOOR driven by per-receiver per-day DKIM- aligned-pass-rate floor — the per-publisher per-domain per-receiver per- day BIMI-rendering-rate is structurally bounded by the per-receiver per-day DKIM- aligned-pass-rate floor produced by the absence of the SEVEN DKIM-verification failure modes THIS page catalogues; per- publisher per-receiver per-day per-domain BIMI-rendering-rate optimisation REDUCES TO per-domain per-day per-receiver minimisation of the six non-pass DKIM- verdict outcomes THIS page documents; (iii) per-publisher per-domain BIMI VMC certificate-binding cryptographic- attestation CASCADE FAILURE under per- message DKIM fail / permerror — the per- publisher per-domain BIMI VMC (Verified Mark Certificate) cryptographic-binding attestation chain BREAKS at per-receiver per-message verification BENEATH the per- message DKIM fail or permerror verdict ceiling; the per-publisher BIMI-VMC investment is operationally inert until per-domain per- receiver per-day per-message DKIM-aligned- pass-rate continuity discipline is established; (iv) per-publisher per-domain per-receiver per-day per-DKIM- verdict rua= aggregate-report observability primitive as joint BIMI- rendering-eligibility-diagnostic SURFACE — the per-publisher per- domain operator reads the per-day per- receiver per-source-IP per-DKIM-verdict <auth_results><dkim><result> row-by-row distribution in the rua= aggregate-report block as the SINGLE observability surface for attributing per-publisher per-receiver per- day BIMI-rendering-rate deviations to the SPECIFIC per-DKIM-verdict failure mode (none-publication-gap vs fail-body-hash-drift vs permerror-key-syntax-fault vs temperror-DNS-failure) THIS page documents — closing the per-publisher per-domain BIMI-rendering-rate optimisation feedback loop. Read the BIMI spoke ALONGSIDE this DKIM-failures-explained reference whenever the per-publisher per- domain operator ATTRIBUTES per-receiver per-day BIMI-rendering-rate deviations to per-message DKIM-verdict-failure root causes — the per-publisher per-domain BIMI- rendering-eligibility-as-DKIM-verdict- catalogue-consumer attribution discipline is the canonical operator-facing companion every per-publisher per-domain BIMI-rendering operator MUST master.
• Email authentication glossary — the DKIM-FAILURE-MODE-CATALOGUE- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER- EMAIL-AUTHENTICATION-TERMINOLOGY-HUB companion to this DKIM-failure-mode diagnostic-ladder reference. Where THIS page documents the per-publisher per- selector DKIM failure-mode catalogue (the seven RFC 6376 §3.9 + RFC 8601 §2.7.1 Auth-Results dkim= status- keyword set: pass / fail / policy / neutral / temperror / permerror / none, each with its canonical upstream signing- side or downstream verification-side causation, per-receiver triage workflow, and per-publisher remediation discipline), the email-authentication-glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every DKIM-failure-mode discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term DKIM-signature-anatomy vocabulary resolution — the DKIM-Signature header tag-set vocabulary (d= signing- domain, s= selector, b= signature value, bh= body-hash, h= signed-header list, c= canonicalization algorithm, l= body-length count, t= timestamp, x= expiration, a= algorithm, q= query-method, i= AUID identity) THIS page's per-failure-mode diagnostic ladder structurally references at every per-failure-mode entry is canonically defined in the glossary spoke; the per-publisher per-selector per-message DKIM-Signature tag-set terminology vocabulary that drives every DKIM-failure-mode triage discussion lives in the glossary's per-tag entry-set; (ii) per-term DKIM-cryptographic- primitive vocabulary resolution — the DKIM-cryptographic-primitive vocabulary (RSA-SHA256 algorithm, 2048-bit modulus, public-key TXT-RR at <selector>._domainkey.<d> owner-name, simple-vs-relaxed canonicalization, body-hash-over- canonicalized-body, signature-over- canonicalized-headers-plus-body-hash) THIS page's per-failure-mode catalogue references when describing each failure mode's upstream cryptographic causation is canonically defined in the glossary spoke; per-failure-mode discussion of permerror (cryptographic- primitive misconfiguration), fail (cryptographic-primitive verification mismatch), and temperror (cryptographic-primitive DNS-resolution unavailability) terminology depends on the glossary's canonical per-primitive definitions; (iii) per-term DMARC- alignment vocabulary resolution — the DMARC-alignment vocabulary (organizational domain, alignment-strictness adkim= s/relaxed mode, RFC5322-From domain, AUID i= identity, d= vs From-domain comparison) THIS page's per-failure-mode catalogue references when describing how DKIM-pass verdicts feed into DMARC-aligned-pass determinations is canonically defined in the glossary spoke; the per- message d=-vs-From-domain alignment- evaluation vocabulary that determines whether a per-message DKIM-pass becomes a DMARC-aligned-pass lives in the glossary's per-term alignment-vocabulary entry-set; (iv) per-term Auth- Results header vocabulary resolution — the Auth-Results header vocabulary (RFC 8601 §2.7.1 dkim= status- keyword set, header.d= property, header.s= property, header.i= property, header.b= property, reason= property, comment= property) THIS page's per-failure-mode catalogue references when documenting per-receiver verdict-emission is canonically defined in the glossary spoke; the per-receiver per-message Auth-Results-header decode vocabulary that drives every operator-side per- failure-mode triage discussion lives in the glossary's per-term Auth-Results- vocabulary entry-set. Read the email- authentication-glossary spoke alongside this DKIM-failure-mode diagnostic-ladder reference when authoring per-publisher per-selector per-message DKIM-failure triage runbooks and decode-discipline documents that need the shared terminology hub.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- RECORD-BYTE-LEVEL-PUBLICATION-DISCIPLINE-AS- COMPLEMENTARY-AUTH-LEG-EVIDENCE companion to this DKIM-failure-mode diagnostic-ladder reference. Where THIS page documents the per-DKIM-failure-mode catalogue (dkim=fail / dkim=neutral / dkim=temperror / dkim=permerror / dkim=policy) and the per-failure-mode diagnose-and-fix sequence, the SPF-DNS-record-syntax spoke is the per-publisher-per-domain SPF-side byte-level publication reference every per-DKIM-failure triage operator consults at FOUR per-failure- mode-vs-SPF-correlation triage-decision dimensions: (i) per-message dkim=fail combined with per-source-IP spf=pass indicates per-publisher per-message DKIM-side-only failure scope — when a per-message DKIM verification fails but the SPF DNS record's per-source-IP envelope check passes (the v=spf1 record correctly authorises the sending IP via ip4:/ip6:/a/ mx/include: mechanisms with ~all/-all qualifier), the per-publisher per-message DKIM-side investigation scope is bounded to DKIM-specific failure modes (body-hash mismatch, canonicalization mismatch, signature-verification failure, public-key absence) — the SPF-side is exonerated by the per-source-IP envelope verdict, freeing the operator to focus per-message DKIM triage on per-message header signing or per-publisher per-selector DNS-record publication; (ii) per-message dkim=fail combined with per-source-IP spf=fail indicates per-source-IP outbound- pool drift requiring per-publisher SPF DNS record audit — when both per- message DKIM and per-source-IP SPF fail together, the per-publisher root cause is usually per-source-IP outbound-pool drift (a new SaaS sender added without updating SPF, an outbound relay IP migrated without SPF re-publication, or a per-tenant SaaS platform whose include: mechanism resolves to a different ip4-block than expected) — the per-publisher SPF DNS record syntax reference documents the ip4:/ip6:/a/mx/ include: mechanism semantics the per- publisher operator audits when the per- source-IP envelope-verdict reveals SPF- record drift simultaneous with DKIM failures; (iii) per-publisher per-domain SPF record 10-DNS-lookup limit (RFC 7208 §4.6.4) as per-message spf=permerror upstream cause cascading into DKIM-only DMARC alignment — when a per-publisher SPF record exceeds the 10-DNS-lookup limit (a common drift when nested include: chains expand beyond depth-4), per-source-IP spf=permerror is the published-evidence verdict that downgrades per-publisher per-message DMARC alignment to DKIM-only, making per-message DKIM verification the load-bearing-AND-only authentication leg — the per-publisher per-DKIM-failure- mode triage scope expands to include per-source-IP spf=permerror diagnosis, which the per-publisher SPF DNS record syntax reference documents the per- mechanism per-include resolution path for; (iv) per-publisher per- domain SPF -all qualifier as per-source- IP-spoof-prevention complement to per- message DKIM-Signature-header tampering defense — the per-publisher SPF DNS record's per-domain -all qualifier is the per-publisher per-message envelope-MAIL-FROM authorisation hardening discipline that complements the per-message DKIM- Signature-header cryptographic verification THIS page documents as the per-publisher per-receiver second-leg of defense — operators triaging per-message DKIM-Signature-header tampering events cross-reference the per-publisher SPF DNS record's -all qualifier publication to confirm the per-publisher per-message envelope-MAIL-FROM authorisation is per-source-IP-restrictive (preempts per-source-IP-spoof attacks that would otherwise pass per-source-IP spf=softfail with ~all). Read the SPF DNS record syntax spoke alongside this DKIM-failure-mode diagnostic reference when authoring per-publisher per-domain per-message authentication triage runbooks coordinating per-source-IP SPF-side envelope-MAIL-FROM verdicts with per-message DKIM-side cryptographic verdicts, when investigating per- publisher per-message DMARC alignment failures spanning both authentication legs simultaneously, or when establishing the per-publisher per-domain SPF DNS record's per-source-IP outbound-pool authorisation discipline as the complementary-first-leg evidence stream the per-DKIM-failure-mode triage workflow depends on to scope per-message DKIM investigations correctly.
• RFC 6376 §3.9 — DKIM Verification Algorithm — the normative source for the seven status keywords.
• RFC 8601 §2.7.1 — DKIM Authentication-Results status — the receiver-side Authentication- Results header format that exposes the verdicts.
• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — modern algorithm + key-size guidance; the source of most dkim=policy rejections.
• Email Header Analyzer — paste any message's headers and see the parsed Authentication-Results stack including all DKIM verdicts.
• Domain Security Checker — live DNS lookups for every DKIM selector on a domain. Catches publishing-side permerror root causes.
• Email spoofing — the DIRECT-DOMAIN-SPOOFING- THREAT-MODEL-AS-LOAD-BEARING- RECEIVER-SIDE-DKIM-FAILURE- VERDICT-INTERPRETATION-CONTEXT companion to this DKIM-failures- explained operator-reference. Where THIS page catalogues the seven receiver-side DKIM-verdict keywords (dkim=pass, dkim=fail, dkim=neutral, dkim=temperror, dkim=permerror, dkim=policy, dkim=none) at the RFC 6376 §3.9 protocol layer, the email-spoofing spoke documents the THREAT-MODEL every receiver-side DKIM- failure-verdict is operationally interpreted against, bridging the per-verdict-keyword protocol-layer evidence this page documents to the per- threat-class direct-domain-spoof threat-model the email-spoofing spoke catalogues at four cross- protocol-receiver-side-DKIM- verdict-to-direct-spoof-threat- model coupling dimensions: (i) dkim=fail verdict on mail purporting to originate from the publisher's Header-From domain as the canonical message-layer evidence of a direct-domain-spoofing attempt — the email-spoofing spoke documents the DIRECT- DOMAIN-SPOOFING threat-class (attacker forges From: ceo@victim.com without an authentic DKIM signature for the victim.com d=domain) whose receiver-side message-layer evidence-signature is the dkim=fail-or- dkim=none verdict on a message whose Header-From d-domain belongs to the publisher's authorised-signer set, framing the per-message DKIM-failure verdicts this page catalogues as the per-message evidence-class the per- publisher anti-direct-spoof threat-model directly consumes; (ii) dkim=none + dkim=neutral verdicts as the load-bearing evidence-class for the attacker-omits-DKIM-signature spoof-variant the spoofing spoke catalogues — the email-spoofing spoke documents the attacker-omits-DKIM spoof-variant whose receiver- side evidence is the dkim=none verdict (no DKIM signature present) or dkim=neutral verdict (signature present but for the attacker's domain, not the Header-From d-domain), framing the per-message DKIM-none and DKIM-neutral verdicts this page catalogues as the per- message evidence-class distinguishing legitimate unsigned mail (newsletters, small-publisher transactional) from per-domain-spoofing attacker-omitted DKIM; (iii) per-publisher DKIM coverage- completeness as load-bearing precondition for direct-domain- spoof-detection at the receiver-side authentication- chain — the email-spoofing spoke documents the per- publisher anti-direct-spoof defense-stack (DMARC at enforcement, SPF + DKIM-signing coverage across all per-publisher mail sources, ARC-chain validation, BIMI display-gating) whose precondition is per-publisher DKIM-signing coverage completeness — any per- publisher per-mail-source unsigned mail produces an ambiguous dkim=none verdict the receiver-side anti-spoof evaluator cannot cleanly distinguish from a per-domain-spoofing attempt; the per-message DKIM-verdict catalogue THIS page documents is the per-message protocol- layer evidence the per- publisher anti-direct-spoof defense the spoofing spoke documents structurally consumes; (iv) aggregate- rate per-domain DKIM-failure distributions as load-bearing per-domain-spoofing-campaign- detection evidence in the receiver-side rua-aggregate- XML evidence-stream — the email-spoofing spoke documents the per-domain- spoofing-campaign-detection workflow consuming per- source-IP per-Header-From per-disposition per-DKIM- verdict per-SPF-verdict evidence in the rua-aggregate- XML stream; aggregate-rate dkim=fail-on- publisher's-Header-From-domain distributions surface the per- spoofing-campaign source-IP topology the receiver-side threat-hunter pivots from to per-attacker-infrastructure attribution, anchoring the per-message DKIM-verdict evidence this page documents to the per-spoofing-campaign aggregate-rate detection- workflow the email-spoofing spoke documents. Read the email-spoofing spoke alongside this DKIM-failures- explained reference when triaging per-message DKIM- failure verdicts against the per-publisher direct-domain- spoofing threat-model every receiver-side anti-spoof evaluation this page's per- verdict catalogue consumes.
• SPF PermError vs TempError — the PER-PUBLISHER-PER-MESSAGE-CROSS- MECHANISM-MESSAGE-LAYER-AUTHENTICATION- EVALUATION-FAILURE-CLASS-CATALOGUE- PARALLEL companion to this DKIM- failures-explained reference. Where THIS page documents the per-publisher per-message DKIM-failure-class catalogue at message-layer cryptographic-authentication- evaluation boundary (per-message dkim= fail from per-message cryptographic- signature-verification failure, per- message dkim=permerror from per- message DKIM-Signature-header syntax- error / per-publisher per-selector DKIM-key-record absence, per-message dkim=temperror from per-receiver per- message DKIM-key-record DNS-resolution- timeout per RFC 6376), the SPF- PermError-vs-TempError spoke documents the STRUCTURALLY-PARALLEL per- publisher per-message SPF-failure- class catalogue at message-layer IP- authentication-evaluation boundary at FOUR per-publisher per-message cross- mechanism message-layer-authentication- evaluation-failure-class catalogue parallel coupling dimensions: (i) per-publisher per-message permanent-evaluation-failure-class cross-mechanism parallel: DKIM- permerror vs SPF-permerror as load- bearing per-publisher per-domain publication-fault attribution primitive — per-publisher per- message dkim=permerror verdict-class emergence attributes per-publisher per- domain DKIM-publication-discipline- fault (per-publisher per-selector DKIM-key-record absence, per-message DKIM-Signature-header syntax-error, per-publisher per-selector cryptographic-anchor-publication misconfiguration) at message-layer cryptographic-authentication-evaluation boundary THIS page documents; per- publisher per-message spf=permerror verdict-class emergence per RFC 7208 §4.6.4 attributes per-publisher per- domain SPF-publication-discipline- fault (per-publisher SPF-record- syntax-error, per-publisher 10-DNS- lookup-limit-overflow, per-publisher void-lookup-overflow, per-publisher multi-record-SPF-publication) at message-layer IP-authentication- evaluation boundary — BOTH per- publisher per-message verdict-classes compose the per-publisher per-message PERMANENT-PUBLICATION-FAULT-CLASS attribution primitive at distinct cross-mechanism per-publisher per- message message-layer-authentication- evaluation boundaries; (ii) per-publisher per-message transient- evaluation-failure-class cross- mechanism parallel: DKIM-temperror vs SPF-temperror as load-bearing per- receiver-fault transient-attribution primitive — per-publisher per- message dkim=temperror verdict-class emergence attributes per-receiver per- message DKIM-key-record DNS-resolution- infrastructure-failure (per-receiver DNS-resolution-timeout, per-receiver intermittent-DNS-failure, per- receiver per-message DKIM-key-fetch- network-error per RFC 6376) at receiver-side cryptographic- authentication-evaluation boundary THIS page documents; per-publisher per- message spf=temperror verdict-class emergence per RFC 7208 §4.6.4 attributes per-receiver per-message SPF-record DNS-resolution- infrastructure-failure (per-receiver DNS-resolution-timeout, per-receiver intermittent-DNS-failure, per- receiver SPF-record-fetch-network- error) at receiver-side IP- authentication-evaluation boundary — BOTH per-publisher per-message verdict-classes compose the per- publisher per-message TRANSIENT- RECEIVER-FAULT-CLASS attribution primitive at distinct cross- mechanism per-publisher per-message message-layer-authentication- evaluation boundaries; (iii) per-publisher per-message cross-mechanism message-layer- authentication-evaluation-failure- class composition as load-bearing per-publisher per-domain DMARC- aligned-pass-evaluation-failure upstream attribution-pipeline primitive — per-publisher per- message DMARC-aligned-pass-evaluation consumes per-message dkim=permerror / dkim=temperror AND per-message spf= permerror / spf=temperror verdict- class composition as load-bearing per-message DMARC-aligned-pass- evaluation-failure upstream attribution-pipeline primitive — per- publisher per-message DKIM-failure- class catalogue THIS page documents AND per-publisher per-message SPF- failure-class catalogue the SPF- PermError-vs-TempError spoke documents operationally compose the per- publisher per-message cross-mechanism message-layer-authentication- evaluation-failure-class catalogue the per-publisher per-message DMARC- aligned-pass-evaluation-failure attribution-pipeline structurally consumes; (iv) per-publisher per-domain cross-mechanism message- layer-authentication-evaluation- failure-class observability surface as load-bearing per-publisher per- domain operations team cross- mechanism per-message-class evidence- capture composition primitive — per-publisher per-domain operations team responsible for per-publisher per-domain message-layer- authentication-evaluation operational- discipline structurally consumes per- publisher per-domain rua-aggregate- XML row capture of per-message dkim= permerror / dkim=temperror verdict- class THIS page documents the per- publisher per-domain attribution- catalogue of AND per-publisher per- domain rua-aggregate-XML row capture of per-message spf=permerror / spf= temperror verdict-class the SPF- PermError-vs-TempError spoke documents the per-publisher per-domain attribution-catalogue of as the per- publisher per-domain cross-mechanism message-layer-authentication- evaluation-failure-class composed observability surface — per-publisher per-domain operations team cross- mechanism per-message-class evidence- capture composition primitive at per-publisher per-receiver per-day per-source-IP row-level granularity. Read the SPF-PermError-vs-TempError spoke alongside this DKIM-failures- explained reference for the canonical per-publisher per-message RFC 7208 §4.6.4 SPF-evaluation-failure-class catalogue STRUCTURALLY-PARALLEL at cross-mechanism failure-class catalogue level to the per-publisher per-message DKIM-failure-class catalogue THIS page documents — the two per-publisher per-message catalogues compose the per-publisher per-message cross-mechanism message- layer-authentication-evaluation- failure-class composed catalogue every per-publisher per-domain operations team responsible for per- publisher per-domain message-layer- authentication-evaluation operational discipline structurally consumes.
• BIMI SVG Tiny PS logo requirements — the PER-MESSAGE-DKIM-PASS-IS-LOAD- BEARING-PRECONDITION-OF-BIMI-LOGO- DISPLAY companion to this DKIM-failures- explained operator-reference. Where THIS page catalogues the seven receiver- side DKIM-verdict keywords (dkim=pass, dkim=fail, dkim=neutral, dkim=temperror, dkim=permerror, dkim=policy, dkim=none) and the per- receiver per-message DKIM-evaluation diagnostic surface every operator-side IR workflow consumes, the BIMI-SVG- requirements spoke documents the DOWNSTREAM brand-enrichment surface whose per-message rendering eligibility is STRUCTURALLY GATED on the per- message DKIM-pass verdict THIS page catalogues. Four concrete DKIM-verdict- to-BIMI-rendering-eligibility coupling points: (i) DKIM-fail at the per-message scope drops BIMI logo rendering on Gmail + Yahoo + Apple Mail — every mailbox provider that surfaces BIMI requires the per- message DKIM verdict to be dkim=pass AND aligned with the RFC 5322 From: domain BEFORE rendering the brand logo; a sustained dkim=fail rate at the per- publisher per-domain scope drops BIMI logo display on the impacted mail stream, even when the BIMI DNS record and Tiny PS SVG file are byte-perfect; (ii) DKIM-permerror at the per-publisher per-domain scope blocks BIMI logo display across the receiver fleet — when a missing or malformed selector TXT record drives receiver-side dkim=permerror, the BIMI-logo-rendering eligibility also collapses because no receiver will surface BIMI without an aligned DKIM-pass; the BIMI-SVG-requirements spoke documents the file-format axis that is the ORTHOGONAL precondition (DKIM-pass closes the message-layer precondition; Tiny PS file-format compliance closes the byte-level publication-side precondition); (iii) DKIM-policy due to RSA-1024 key-size at the per-publisher per- selector scope — RFC 8301 receivers reject RSA-1024 signatures with dkim=policy; this collapses BIMI eligibility on the impacted receiver subset because the per-message authentication evidence no longer satisfies the BIMI-display precondition; (iv) DKIM-neutral from a body-modified forwarder path — when an RFC 5322 body modification by a forwarder invalidates the DKIM signature, the per-receiver verdict transitions to dkim=fail or dkim=neutral on the forwarder hop; BIMI logo display drops on the forwarded-mail subset until either the originator's DKIM signature scope is renegotiated or ARC chain-of-trust is established to preserve the originating per-message DKIM-pass evidence across the hop. Read the BIMI-SVG-requirements spoke ALONGSIDE this DKIM-failures-explained reference whenever the per-domain BIMI-logo-rendering KPI surfaces a regression and the DKIM-verdict distribution is the load-bearing upstream variable to investigate first.
• DMARC policy rollout — the PER-DKIM-FAILURE-MODE- DIAGNOSTIC-EVIDENCE-AS-LOAD-BEARING- GATING-INPUT-OF-PER-PUBLISHER-DMARC- POLICY-PROGRESSION companion to this DKIM-failure-mode operational catalogue. Where THIS page documents the per-DKIM- failure-mode catalogue at the per-message cryptographic-authentication-evaluation boundary (eight failure-mode classes per the section above), 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-DKIM-failure- mode distribution THIS catalogue documents at FOUR per-DKIM-failure-mode-vs-DMARC- policy-ramp-step coupling dimensions: (i) per-message body-hash-mismatch DKIM-failure-mode 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-message body-hash-mismatch DKIM-failure-mode rate THIS catalogue documents as the load- bearing per-publisher per-domain false- positive-loss-floor indicator — the body- hash-mismatch rate must trend below the per-publisher per-domain false-positive- loss tolerance BEFORE the per-publisher operator can commit the p=quarantine tightening without per-receiver per-message legitimate-message-loss regression; (ii) per-message canonicalization-mismatch DKIM-failure- mode rate is the load-bearing gating 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-message canonicalization-mismatch DKIM-failure- mode rate THIS catalogue documents as the load-bearing per-forwarder per-message signature-survival indicator — the canonicalization-mismatch rate across the per-publisher per-domain receiver topology must trend below the per-forwarder per-message signature-survival floor BEFORE the per-publisher operator can commit the p=reject tightening without per-forwarder per-message legitimate- message-loss regression; (iii) per- publisher per-selector public-key-absence DKIM-failure-mode is the load-bearing publication-discipline regression-indicator of every DMARC ramp-step — the policy-rollout spoke documents how the per- publisher per-selector public-key-absence DKIM-failure-mode THIS catalogue documents is the per-publisher publication-discipline regression-signal that BLOCKS every per- publisher per-domain DMARC ramp-step tightening commit — a per-selector public- key-absence regression collapses the per- publisher per-message DKIM-aligned-pass rate to zero on the affected selector and forces a per-publisher per-domain ramp-step rollback to the prior p=none or p=quarantine policy mode; and (iv) per-message DKIM-failure- mode rolling-window distribution is the load-bearing per-publisher per-domain green-state-baseline of the ramp-step observation window — the policy- rollout spoke documents how every ramp-step tightening commit is preceded by a per- publisher per-domain rolling-window observation period whose per-DKIM-failure- mode distribution stability THIS catalogue documents is the load-bearing green-state baseline — the rolling-window distribution across all eight failure-mode classes THIS catalogue documents must remain stable across the observation window BEFORE the per-publisher operator can commit the ramp-step tightening with per-domain per- receiver per-message false-positive-loss confidence.
• TLS-RPT explained — the PER-RECEIVER-PER-SESSION- TRANSPORT-LAYER-ENCRYPTION-FAILURE-TELEMETRY- AS-LOAD-BEARING-PEER-FAILURE-MODE-CATALOGUE- COMPANION companion to this DKIM-failure-mode operational catalogue. Where THIS page documents the per-message DKIM-failure-mode catalogue at the per-message cryptographic- authentication-evaluation boundary (eight failure-mode classes per the section above), the TLS-RPT-explained spoke is the per- receiver per-session transport-layer- encryption failure-mode catalogue whose per- publisher per-domain per-MX hop failure- distribution stream pairs operationally with the per-message DKIM-failure-mode catalogue THIS page documents at FOUR per-receiver-side telemetry-stream coupling dimensions: (i) per-receiver-side failure-telemetry- pillar parallelism — the TLS-RPT failure-details report stream is the per-receiver-per-session transport-layer- encryption failure-mode catalogue whose per- publisher per-domain reporting cadence, receiver-side aggregation discipline, and per-failure-mode classification taxonomy mirror the per-receiver per-message DKIM- verdict aggregation stream THIS page documents at the application layer; (ii) per-MX-hop transport-encryption- failure vs per-message cryptographic- authentication-failure attribution separability — TLS-RPT failure-details and per-message DKIM-verdict streams are structurally independent evidence-streams that BOTH must be ingested before per-publisher per-domain operators can distinguish per-MX-hop starttls-downgrade or certificate-validation failure (visible only in TLS-RPT) from per-message DKIM- signature-mode failure (visible only in DMARC aggregate rua reports) at attribution time; (iii) per-receiver-per-session transport-layer-encryption-failure as upstream cause-candidate for per-message DKIM-failure- mode regression — a per- receiver-per-session transport-layer- encryption failure (e.g. starttls-not- supported or validation-failure in the TLS-RPT failure-details stream) can downgrade the per-receiver per-session message-handling path in ways that surface as per-message DKIM-fail rate spikes in the DMARC aggregate rua stream THIS catalogue documents; (iv) per-publisher per- domain Bulk-Sender-Requirements-2024 deliverability-floor composition — TLS-RPT publication is one of the terminal-state cross-layer publication disciplines (alongside MTA-STS, DKIM-key- rotation, BIMI-VMC, and DMARC p=reject) the per-publisher per-domain Bulk-Sender- Requirements-2024 deliverability-floor composition explicitly requires for a complete cross-layer authentication-and- encryption posture. Read the TLS-RPT- explained spoke ALONGSIDE this DKIM-failures- explained reference whenever a per-publisher per-domain authentication-failure investigation needs the per-receiver-per-session transport- layer-encryption failure context that the DMARC aggregate rua stream cannot surface on its own.
• include: vs ip4: vs a: vs mx — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-DECISION-VIEW-AS-LOAD-BEARING- PEER-PROTOCOL-LAYER-AUTHENTICATION-FAILURE- MODE-CATALOGUE companion to this DKIM- failure-mode catalogue. Where THIS page documents the per-publisher per-selector DKIM-failure-mode catalogue at the per- message application-layer cryptographic- authenticity-binding (per-message body-hash mismatch, per-message canonicalization- mismatch, per-message signature-verification- failure, per-publisher per-selector public- key-absence, per-publisher per-selector key- revoked, per-message DKIM-Signature-header- tampered, per-message forwarder-modified- body, per-publisher per-selector cryptographic-trust-anchor-publication- defect), the include-vs-ip4-vs-a-vs-mx spoke is the peer per-publisher per-domain SPF-mechanism-decision-view whose per- mechanism-choice publication discipline (include: delegated to a third- party SPF-publisher, ip4: literal-IP-range publication, a: A-record-lookup publication, mx: MX-record-lookup publication) determines the per-message envelope-MAIL-FROM SPF-failure-mode catalogue emission and pairs operationally with the per-publisher per-selector DKIM-failure-mode catalogue THIS page documents at FOUR per- failure-mode coupling dimensions: (i) peer per-protocol-layer- authentication-failure-mode-catalogue parallelism — the per- publisher per-selector DKIM-failure-mode catalogue THIS page documents at the application-layer authenticity-binding (eight per-DKIM-failure-mode classes) is the per-publisher per-selector peer-protocol- layer-authentication-failure-mode catalogue whose per-protocol-layer-companion is the per-publisher per-domain SPF-mechanism- decision-view's per-mechanism-choice-derived per-message envelope-MAIL-FROM SPF-failure- mode catalogue (per-message permerror from include: 10-lookup-limit breach, per-message temperror from a:/mx: DNS- resolution failure, per-message softfail from ~all mechanism-default, per-message hardfail from -all mechanism-default) the include-vs-ip4-vs-a- vs-mx spoke documents the per-mechanism- choice rationale of — together the two per-protocol-layer-authentication-failure- mode catalogues compose the per-publisher per-domain complete cross-protocol-pillar authentication-failure-mode investigation coverage; (ii) per-message authentication-failure-mode-attribution parallelism — per-selector-DKIM-key- discipline-attribution vs per-domain-SPF- mechanism-choice-attribution — the per-publisher per-selector DKIM- failure-mode catalogue THIS page documents attributes per-message authentication failure to per-selector key-discipline defects (per-selector key-absence, per- selector key-revocation, per-selector cryptographic-trust-anchor-publication- defect) at the per-message application- layer; the include-vs-ip4-vs-a-vs-mx spoke attributes per-message authentication failure to per-domain SPF-mechanism-choice defects (per-publisher per-domain include: chain-depth breach, per-publisher per-domain a: FQDN-resolution failure, per-publisher per- domain mx: MX-RR-set drift, per-publisher per-domain ip4: IP-range staleness) at the per-message envelope-MAIL-FROM-layer — together the two per-protocol-layer attribution disciplines compose the per-message complete authentication-failure-mode root-cause attribution that the per-publisher per- domain DMARC-failure investigation requires; (iii) per-publisher per- domain cross-protocol-pillar failure-mode co-ingestion as complete authentication- failure-investigation posture — the per-publisher per-selector DKIM- failure-mode catalogue 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-domain SPF-mechanism-choice- derived per-message SPF-failure-mode catalogue the include-vs-ip4-vs-a-vs-mx spoke documents the per-mechanism-choice determinants of — together the two per- protocol-layer failure-mode-investigation streams compose the per-publisher per- domain complete cross-protocol-pillar authentication-failure-investigation posture every per-publisher per-domain DMARC-deployment programme requires for complete per-message failure-mode root- cause attribution; (iv) per- publisher per-domain operator-side authentication-failure-mode-root-cause discipline parallelism — the per-publisher per-selector DKIM- failure-mode catalogue 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 include-vs-ip4-vs-a-vs-mx spoke documents the per-publisher per- domain SPF-mechanism-choice operator-side discipline (decision-view between delegating to third-party-SPF-publishers via include:, publishing literal-IP-ranges via ip4:, publishing dynamic FQDN-lookups via a:, or publishing MX-RR-set lookups via mx:), and the per-publisher per-domain operator-side per-protocol-pillar publication-discipline coordination is the load-bearing per- publisher per-domain authentication- failure-mode prevention rhythm BOTH protocols share at the per-publisher per- domain cross-protocol-pillar publication- discipline composition boundary. Read THIS page when INVESTIGATING per-publisher per- selector DKIM-failure-mode root causes; read the include-vs-ip4-vs-a-vs-mx spoke when CHOOSING the per-publisher per-domain SPF-mechanism publication approach (include:, ip4:, a:, or mx:) whose per-mechanism-choice operational discipline determines the per-message envelope-MAIL-FROM SPF-failure-mode catalogue pairing operationally with the per-message application-layer DKIM-failure- mode catalogue THIS page documents.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) and SPF flattening — the PER-PUBLISHER-PER-DOMAIN-SPF- LOOKUP-BUDGET-BREACH-AS-PARALLEL-ENVELOPE- LAYER-FAILURE-MODE-CATALOGUE companion to THIS DKIM-failure-verdict catalogue. Where THIS page documents the seven per-publisher per-selector RFC 6376 §3.9 + RFC 8601 §2.7.1 receiver-side DKIM-verdict keywords (none / neutral / pass / fail / policy / temperror / permerror) and the per- verdict diagnostic root-cause ladder (per-publisher per-selector body-hash mismatch, per-publisher per-selector signature-tag invalidity, per-publisher per- selector canonicalization mismatch, per- publisher per-selector public-key DNS- resolution failure, per-publisher per- selector RSA-key-too-small RFC 8301 rejection, per-publisher per-selector retired-key permerror, per-publisher per- selector multi-signature precedence ambiguity), the SPF-lookup-limit spoke is the PER-PUBLISHER-PER-DOMAIN-ENVELOPE-MAIL- FROM-LAYER-AUTHENTICATION-FAILURE-MODE catalogue companion at FOUR per-DKIM- failure-mode-vs-SPF-lookup-permerror parallelism dimensions: (i) per- publisher per-domain SPF permerror at 10- DNS-lookup budget breach AS structurally- parallel envelope-layer counterpart to per- publisher per-selector DKIM permerror at public-key DNS-resolution failure — the per-publisher per-domain SPF- evaluation permerror from RFC 7208 §4.6.4 10-DNS-lookup cap breach the SPF-lookup- limit spoke documents IS the structurally- parallel per-publisher per-domain envelope- MAIL-FROM-layer counterpart to the per- publisher per-selector DKIM-verifier permerror from <selector>. _domainkey.<d-domain> TXT-RR DNS-resolution failure THIS page documents: both verdicts surface DNS-infrastructure defects (one per-publisher per-domain SPF- include cascade-depth-exhaustion, one per- publisher per-selector public-key-record absence-or-corruption) and BOTH cascade to per-publisher per-domain DMARC composite- verdict-fail at the per-publisher per- domain composite-authentication-decision boundary; (ii) per-publisher per- domain SPF temperror at transient DNS- resolver failure AS structurally-parallel envelope-layer counterpart to per-publisher per-selector DKIM temperror at transient nameserver outage — the per- publisher per-domain SPF-evaluation temperror from per-message per-include SERVFAIL the SPF-lookup-limit spoke catalogues (per-publisher per-include upstream-nameserver outage, per-publisher per-domain authoritative-nameserver rate-limit triggering) IS the structurally- parallel per-publisher per-domain envelope- MAIL-FROM-layer counterpart to the per- publisher per-selector DKIM-verifier temperror from per-message per-selector DNS-cache-miss-during-nameserver-outage THIS page documents; both surface per- message transient-recoverable verdicts receivers re-evaluate on retry and BOTH produce per-publisher per-domain DMARC RUA aggregate-report row-noise operators must distinguish from per-publisher per-domain persistent-failure verdicts at the per- publisher per-domain RUA aggregate-stream signal-vs-noise reconciliation boundary; (iii) per-publisher per-domain composite SPF + DKIM permerror co- occurrence AS load-bearing per-publisher per-domain DMARC catastrophic-disposition evidence-stream — the per- publisher per-domain composite- authentication-failure investigation depends on the per-publisher per-domain SPF permerror catalogue the SPF-lookup-limit spoke documents PLUS the per-publisher per- selector DKIM permerror catalogue THIS page documents to attribute per-publisher per- domain DMARC-fail dispositions correctly: per-message rows where SPF=permerror AND DKIM=permerror indicate per-publisher per- domain authoritative-DNS-infrastructure outage (BOTH protocols depend on the same publisher-side authoritative nameservers); per-message rows where SPF=permerror AND DKIM=pass indicate per-publisher per-domain SPF-include-cascade-depth-exhaustion independent of per-publisher per-selector DKIM publication discipline; per-message rows where SPF=pass AND DKIM=permerror indicate per-publisher per-selector retired- key or per-publisher per-selector record- truncation independent of per-publisher per- domain SPF publication discipline — all three composite-failure patterns require cross-referencing BOTH catalogues for complete per-publisher per-domain DMARC- composite-verdict root-cause attribution; (iv) per-publisher per-domain SPF- flattening remediation pipeline AS structurally-parallel publisher-side operational discipline counterpart to per- publisher per-selector DKIM-multi-signature- publication remediation pipeline — the per-publisher per-domain SPF- flattening remediation pipeline the SPF- lookup-limit spoke documents (per-publisher per-domain include-cascade resolution to per-publisher per-domain ip4: / ip6: literal mechanisms via daily cron-driven refresh, per-publisher per-domain subdomain-delegation to split per-publisher per-mail-stream 10-lookup budget across per-publisher per-subdomain SPF records, per-publisher per-domain sender- consolidation to reduce per-publisher per- domain ESP-include cardinality) IS the structurally-parallel per-publisher per- domain publisher-side operational discipline counterpart to the per-publisher per-selector DKIM-multi-signature-publication remediation pipeline THIS page documents (per-publisher per-selector dual-selector key-rotation overlap, per-publisher per-selector algorithm-migration sender-side burn-in, per-publisher per-selector multi-signature ESP-signed-PLUS-publisher-signed publication hedge): BOTH remediation pipelines preempt per-publisher per-domain catastrophic- authentication-verdict cascades at the per- publisher per-domain operational-hygiene- discipline boundary. Read THIS page when diagnosing per-publisher per-selector DKIM- failure verdicts; read the SPF-lookup-limit spoke when diagnosing the structurally- parallel per-publisher per-domain envelope- MAIL-FROM SPF-permerror verdicts that cascade BOTH catalogues into per-publisher per-domain DMARC composite-verdict-fail cascade investigations.
• BIMI Verified Mark Certificates (VMC and CMC)
• TLS-RPT record syntax
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF-ENVELOPE-MAIL-FROM-LAYER-MECHANISM-CLASS-RESULT-CATALOGUE-AS-STRUCTURALLY-PARALLEL-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-VERDICT-RESULT-CLASS-CATALOGUE companion at four per-publisher per-domain SPF-mechanism-vs-DKIM-failure-mode coupling dimensions: (i) per-publisher per-domain SPF mechanism-class evaluation per RFC 7208 §5 yields result-class taxonomy pass / fail / softfail / neutral / none / permerror / temperror per RFC 7208 §2.6 IS structurally parallel envelope-MAIL-FROM-layer result-class catalogue to per-publisher per-selector DKIM-Signature verdict result-class catalogue dkim=fail / dkim=permerror / dkim=temperror per RFC 6376 §3.9 + RFC 8601 §2.7.1 THIS page documents at the per-publisher per-domain composite cross-layer failure-mode-evidence-stream coordination boundary; (ii) per-publisher per-domain SPF include: mechanism-class DNS-lookup-chain expansion failure-mode (cascading permerror via 10-DNS-lookup-cap exhaustion per RFC 7208 §4.6.4) IS structurally parallel application-layer publication-discipline-permerror failure-class to per-publisher per-selector DKIM permerror verdict-class arising from per-selector TXT-RR-parse-failure or key-publication malformation THIS page documents the diagnostic discipline of; (iii) per-publisher per-domain SPF mechanism-evaluation surfaces in DMARC policy_evaluated/spf per-row attribution per RFC 7489 §5.6.2 IS structurally parallel application-layer composite-verdict evaluation companion to per-publisher per-selector DKIM verdict surfacing in DMARC policy_evaluated/dkim per-row attribution — both per-publisher per-domain receiver-emission failure-evidence streams jointly feed the DMARC composite-aligned-pass-rate floor preservation discipline the DKIM-failure catalogue THIS page documents the per-selector application-layer leg of; (iv) per-publisher per-domain SPF mechanism-class publication-discipline drift (premature -all hardfail cutover surfacing as per-source-IP per-day DMARC RUA spf=fail attribution-distortion + premature `include:` chain restructuring surfacing as permerror floor-breaches) IS structurally parallel envelope-MAIL-FROM-layer publication-discipline-drift class to per-publisher per-selector DKIM-key-rotation publication-discipline drift surfacing as per-selector per-day DMARC RUA dkim=temperror attribution-floor regression the DKIM-failure catalogue THIS page documents the operational-mitigation discipline of.
• DMARC multi-domain strategy
• DNS propagation — the DNS-timing root-cause companion to this DKIM-failures catalogue. Where this page documents the per-publisher per-selector DKIM verdict-fail taxonomy (dkim=fail / permerror / temperror / none and the root-cause-attribution ladder for each), the DNS-propagation spoke documents the timing mechanism behind a large and easily-misdiagnosed class of those failures: a newly-published <selector>._domainkey.<domain> TXT record, or a dual-selector key rotation, is not visible to every receiver's recursive resolver until the prior negative-cache TTL expires — so the same selector returns NXDOMAIN at one receiver (yielding dkim=temperror or a body-hash-unverifiable dkim=fail) and resolves cleanly at another during the same reporting window. The DNS-propagation spoke explains the TTL, negative-caching, and authoritative-vs-recursive resolution timing that makes a DKIM key appear intermittently broken. Read it when a DKIM verdict in the RUA aggregate stream looks transient or receiver-specific immediately after a key publication or rotation — DNS propagation timing is the usual root cause this failures catalogue's temperror class points back to.
• SPF for Google Workspace
• DMARC for SaaS & platform senders — multi-tenant SaaS sending is where DKIM failures cluster: shared selectors, per-customer key distribution, and forwarding all erode the dkim=pass rate this page teaches you to localize. The SaaS-senders guide is the deployment-side companion — it shows the platform how to publish aligned per-tenant DKIM so the failures you diagnose here stop recurring at scale.
• SPF qualifiers explained — the +/-/~/? prefix reference that decides which verdict each SPF mechanism emits; the same per-message Authentication-Results the DMARC evaluator reads carries both the dkim= verdict catalogue this page documents and the spf= verdict the qualifier you publish produces, so read the qualifier reference to tune the SPF leg's pass/softfail/fail alongside the DKIM leg.
• SPF explained (the envelope-MAIL-FROM authorization check, the v=spf1 … -all record, and the receiver-side mechanism evaluation per RFC 7208) — SPF is the other DMARC leg this failures catalogue's DKIM verdicts share the composite with: when a DKIM-failure class collapses the dkim=pass leg, the DMARC composite-disjunction per RFC 7489 §3.1.1 survives only if the SPF leg aligns, so read the SPF primer to understand the fallback authentication path every DKIM failure shifts the verdict onto.
• TLS-RPT report format — the STRUCTURED-PER-FAILURE-CLASS-DIAGNOSTIC-TAXONOMY companion to this DKIM failures catalogue: the dkim=permerror/dkim=temperror/dkim=fail verdict classes this page documents and the TLS-RPT failure-details[].result-type classes the report-format spoke documents are the same idea applied at two layers — a structured, machine-readable per-failure-class enumeration an operator reads to root-cause a delivery problem, one at the application-authentication layer (the per-message Authentication-Results header), the other at the transport-encryption layer (the per-day per-receiver aggregate JSON). Read the TLS-RPT-report-format spoke when extending failure-mode root-cause analysis from the DKIM verdict catalogue into the transport-layer STARTTLS-failure catalogue.
• 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.

Localize a DKIM failure in your reports now

DMARC Analyzer parses the <auth_results><dkim> blocks of every aggregate report via includes/DmarcParser.php and surfaces the per-domain, per-selector, per-reporter verdict breakdown on the dashboard. The Reports drill-down lets you pivot from "I see dkim=fail" to "here are the 47 rua rows that produced that failure, grouped by reporter and source IP". The Email Header Analyzer at header_analyzer.php structurally validates individual DKIM-Signature headers via includes/EmailHeaderParser.php — paste a failing message's headers and see the verdict breakdown plus the DKIM-Signature tag-by-tag parse.

Sign up — Free plan Analyze a message header