DMARC Analyzer

TL;DR

• DMARC failures fall into three root-cause classes: SPF failure (no authorized IP / lookup limit / syntax), DKIM failure (no signature / body hash mismatch / key not found), or ALIGNMENT failure (SPF and DKIM both verify but neither domain matches the From: header). The third is the single most common DMARC anomaly.
• Read aggregate (rua) reports for the failure inventory. Every receiver emits a daily XML report describing which IPs produced which SPF / DKIM / alignment results. DMARC Analyzer ingests these via includes/DmarcParser.php and surfaces per-source-IP failure rates in the dashboard.
• Read message headers for a single- message diagnosis. The Authentication-Results: header at the receiving MTA contains the verdict (spf=pass / dkim=fail / dmarc=fail) plus the matched domain. DMARC Analyzer's Email Header Analyzer (header_analyzer.php) parses this for you.
• The 7 canonical failure patterns: (1) SaaS sender without custom-domain DKIM; (2) SPF 10-lookup permerror; (3) DKIM body modified by mailing list; (4) DKIM key not found (selector or DNS error); (5) DNS record at wrong name / duplicate TXT; (6) Forwarding breaks both SPF and DKIM; (7) Subdomain inheriting overly strict sp= policy.
• SPF permerror is the silent killer. Exceeding 10 DNS lookups (RFC 7208 §4.6.4) makes every recipient return permerror and every message fail SPF. Fix by SPF flattening, consolidating senders, or DKIM-only auth.
• Alignment failure looks like authentication failure. SaaS senders that sign with their own domain pass SPF and DKIM but fail DMARC. Enable custom-domain DKIM at every SaaS provider during DMARC rollout.
• Forwarding is a known-failing path for DMARC at p=reject. Deploy ARC (RFC 8617) at the forwarding hop OR accept that mailing-list traffic will be refused.
• Diagnostic commands: dig +short TXT _dmarc.example.com for the DMARC record, dig +short TXT example.com for the SPF record, dig +short TXT selector._domainkey.example.com for the DKIM public key, dig +short TXT _smtp._tls.example.com for the TLS-RPT record.

1. Reading the failure signal

DMARC failures surface through three distinct diagnostic channels. Each carries different information and demands a different troubleshooting workflow.

Channel 1 — Aggregate reports (rua=)

Daily XML reports from every major receiver (Google, Microsoft, Yahoo, Mail.ru, La Poste, plus DMARC reporting services such as Cloudflare and Postmark). Defined in RFC 7489 §7.2. Each report describes which sending IPs produced mail claiming to be from your domain during a 24-hour window, what SPF / DKIM / DMARC results each IP produced, and whether the receiver applied your published policy. The full schema walk-through is on the dedicated aggregate reports page.

What aggregate reports tell you:

• WHO is sending mail using your domain (legitimate senders + spoofers).
• WHICH IPs fail SPF, DKIM, or alignment.
• HOW MANY messages were affected (volume per IP + result combination).
• WHAT receiver action was taken (policy_evaluated.disposition).

What aggregate reports do NOT tell you:

• The original message content (rua reports are privacy-preserving aggregates).
• The specific recipients affected.
• Which DKIM selector signed the message (only the result, not the signature header).

Channel 2 — Authentication-Results headers

Every receiving MTA stamps an Authentication-Results: header onto the message (RFC 8601). This header contains the receiver's verdict on SPF, DKIM, DMARC, and any ARC chain validation. Capture the full raw headers of a known-failing message — recipient forwards it to you, you check the spam folder, or you find it in your Sent Items — and read the receiver's verdict directly.

Example failure header:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@em.sendgrid.net designates 168.245.21.20 as permitted sender)
       dkim=pass header.i=@sendgrid.net header.s=s1 header.b=AbC123
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

Reading: SPF passed authentication (the IP is authorized), DKIM passed cryptographically (the signature verifies), but DMARC failed because neither identifier ALIGNS with the From: header domain example.com — both used sendgrid.net instead. This is the canonical SaaS-sender-without-custom-domain-DKIM pattern from Section 3.

Channel 3 — User reports (missed mail)

The most operationally urgent signal: a user reports that legitimate mail did not arrive. Common phrasings during rollout: "my password reset email never came", "the partner says they sent the invoice but I do not see it", "newsletter subscribers are not receiving anything". This channel surfaces ENFORCEMENT consequences (legitimate mail blocked by the receiver) rather than visibility (aggregate-report data points). Workflow: collect the sender, the recipient, the approximate send time, the recipient's mailbox provider, and any bounce message the sender received — then correlate with aggregate reports from that receiver during that window.

2. The 7 canonical DMARC failure patterns

The keystone reference for this page: every DMARC failure observed in the wild maps to one of seven canonical patterns. Each pattern has a recognizable signature, a root cause, and a known remediation.

Patterns 1 and 2 account for roughly 60 percent of observed DMARC failures in the wild — SaaS-sender alignment plus SPF lookup overflow. Pattern 3 (DKIM body hash) accounts for most of the remainder. Patterns 4 through 7 are edge cases that nevertheless block specific user-visible mail flows and must be diagnosed individually.

3. SPF root causes

SPF failures fall into a small number of distinct categories. Each has a recognizable signature in aggregate reports and message headers.

SPF permerror (the 10-DNS-lookup ceiling)

Defined in RFC 7208 §4.6.4. Every include:, a, mx, ptr, exists, and redirect counts as one lookup. Nested includes count recursively. Once the lookup count exceeds 10, the receiver returns permerror for every message and DMARC's SPF authentication input is permanently broken until the record is fixed.

Common causes of overflow: layered SaaS deployments (each include: adds 1-3 lookups), legacy on-prem MTAs still in the record after migration, redundant ranges that already overlap a SaaS include:. Diagnose with the Domain Security Checker (domain_checker.php) which reports the exact lookup count alongside the record syntax.

Fix options ranked by maintainability:

1. Audit and remove stale includes (often half the includes were added for a project that has since migrated elsewhere). Try this first.
2. SPF flattening — a flattening service (e.g. SPF macros + a managed DNS provider) replaces include: chains with explicit ip4:/ip6: ranges so each include becomes a single zero-lookup mechanism. Costs money and adds a vendor dependency.
3. Consolidate senders — move from multiple SaaS providers to one. Each provider removed reclaims at least one include: slot.
4. Rely on DKIM — for low-volume senders that you cannot flatten, accept SPF none / permerror and ensure DKIM aligns. DMARC passes if EITHER SPF or DKIM aligns; you do not need both.

SPF temperror

Transient DNS failure — the receiver could not resolve a name in the SPF record (SERVFAIL, timeout, recursive resolver limit). Most receivers treat temperror as none, meaning DMARC falls back to DKIM. Diagnose by checking your authoritative nameservers for the failing record, then your nameserver provider's status page. Recurring temperror indicates an unreliable nameserver and warrants a provider conversation.

SPF none (no SPF record published)

Means the domain in the envelope MAIL FROM (the 5321.From) has no SPF record. Two cases. First, the sender ACTUALLY has no SPF — publish one. The SPF record generator in DNS Record Generator builds a syntactically-correct record for your inventory of senders. Second, you THOUGHT you had SPF but the envelope sender uses a different domain than the From: header (typical of SaaS bounce-domain delegation). In that case, SPF is present on the bounce domain but does not align with your From: — fix by enabling custom-domain DKIM instead.

SPF softfail (~ qualifier)

The IP is not authorized, but the sender requested the message be delivered anyway (probably to spam). DMARC treats softfail and fail equivalently — both produce an spf=fail result. The ~all default at the end of most SPF records is a transitional safety setting; once your SPF is accurate, tighten to -all (hardfail).

SPF passes authentication but does not align

The envelope MAIL FROM has SPF authorization for the sending IP, but the envelope domain (5321.From) does not match the visible From: header domain (5322.From) under the aspf alignment mode. Pattern 1 from Section 2. Most common with SaaS senders using provider bounce domains. The alignment deep dive walks through this in detail.

4. DKIM root causes

DKIM failures fall into four categories: missing signature, key not found, body hash mismatch, and signature verification failure. Each has a distinct diagnostic signature.

No DKIM-Signature header present

Receiver result: dkim=none. The message has no DKIM-Signature header at all — the sending MTA did not sign the message. Common causes: the SaaS sender requires explicit DKIM activation in the dashboard; on-prem MTA signing not configured; automated job using a third-party email API without DKIM enabled. Fix at the source: enable DKIM signing for the sending domain. Defined in RFC 6376 §3.5.

DKIM key not found (selector lookup failure)

Receiver result: dkim=permerror with "key not found in DNS". The DKIM-Signature header carries the selector (s=) and signing domain (d=); receivers look up {selector}._domainkey.{d} for the public key. If that name has no TXT record, DKIM cannot verify. Common after a key rotation that forgot to publish the new public key, or a typo in the selector name.

Diagnose with:

dig +short TXT selector._domainkey.example.com

Expected response: "v=DKIM1; k=rsa; p=MIIBIjANBgkq...". No response means the record does not exist publicly — republish it.

DKIM body hash did not verify

Receiver result: dkim=fail with "body hash did not verify". The DKIM-Signature includes a bh= tag containing a base64-encoded hash of the message body canonicalized per the c= canonicalization mode. The receiver re-canonicalizes the body as received and compares the hashes — mismatch means the body changed in transit.

Body modification sources:

• Mailing lists appending a footer ("To unsubscribe, click here") or rewriting subject prefixes.
• Antivirus / security gateways adding a banner ("EXTERNAL: This email originated outside the organization") or replacing links with click-tracker URLs.
• Transfer encoding rewrites — quoted-printable to 8bit, line-ending normalization on a misbehaving MTA.
• Strict canonicalization (c=simple/simple) that fails on innocuous whitespace differences.

Remediation: switch to c=relaxed/relaxed (the recommended and most tolerant), eliminate the modifying middlebox if possible, or deploy ARC at the modifying hop so the original DKIM verdict is preserved for downstream receivers.

DKIM signature verification failed

Receiver result: dkim=fail with "signature did not verify". The body hash matched (body intact) but the RSA / Ed25519 signature itself failed to verify against the published public key. Causes: the public key was rotated but the private key on the signing MTA was not updated (or vice versa); the published key uses a different algorithm than the signing key; key corruption during a copy-paste publish.

Fix by re-deriving the public key from the signing private key and republishing the DNS record. The DNS Record Generator (dns_generator.php) builds a syntactically-correct DKIM record once you provide the public-key material.

DKIM passes but does not align

Pattern 1 from Section 2. The DKIM-Signature d= tag does not match the From: header domain under the adkim alignment mode. The signature verifies — DKIM has done its job — but DMARC alignment fails. Fix by enabling custom-domain DKIM at the sender so the d= tag matches your domain.

5. Alignment root causes

Alignment is the difference between AUTHENTICATION (SPF and DKIM both verify cryptographically) and DMARC (the verified domain matches the visible From: header). The alignment deep dive covers the full concept; this section documents the failure modes you see in practice.

SaaS senders signing with their own domain

Pattern 1, the dominant cause of DMARC failures in the field. SendGrid, Mailgun, Postmark, Marketo, HubSpot, ServiceNow, Zendesk, Salesforce, ActiveCampaign — all default to signing DKIM with their own domain (sendgrid.net, mailgun.org, postmarkapp.com) until you complete a custom-domain DKIM onboarding step. Until then DKIM passes (the signature verifies for sendgrid.net) but does not align with your example.com From: header.

Remediation is provider-specific but follows a common shape: log into the SaaS dashboard, navigate to "Sending Authentication" or "Domain Authentication", enter your sending domain, and publish the CNAME or TXT records the provider issues. The provider's signing MTA then uses your domain in the d= tag, aligning DKIM with the From: header.

Provider bounce-domain breaks SPF alignment

SaaS providers rewrite the envelope MAIL FROM (5321.From) to a provider-controlled address (e.g. bounces@em.sendgrid.net) so they can receive bounce-back notifications. SPF passes because em.sendgrid.net authorizes the SaaS-owned IP; but the envelope domain (em.sendgrid.net) does not align with the visible From: header (example.com) under the aspf mode. Fix by enabling custom bounce-domain delegation at the SaaS (a subdomain of your domain, e.g. bounces.example.com, that CNAMEs to the provider's bounce infrastructure).

Subdomain From: header without aligned auth

Marketing teams send from marketing.example.com via a SaaS that signs with sendgrid.net. The _dmarc.example.com record applies via sp= inheritance, mail fails alignment, and gets rejected once you publish sp=reject. Fix by either publishing a permissive _dmarc.marketing.example.com record overriding the apex sp=, or fixing the SaaS to sign with marketing.example.com (or example.com — strict alignment vs relaxed determines whether the parent organizational domain counts).

Header From: rewrites by middleboxes

Rare but devastating: some legacy security gateways rewrite the From: header on incoming mail (e.g. inserting a display name). Authentication-Results headers may be stripped or replaced by the gateway. ARC (RFC 8617) is designed to defend against this — the gateway seals the pre-rewrite verdict so the downstream receiver can trust it.

6. DNS record syntax errors

A surprisingly large fraction of "DMARC not working" reports trace back to a syntactically- invalid record at the DNS layer — invisible to the operator who published it but invisible to receivers too.

Wrong record location

DMARC records live at _dmarc.example.com, not at example.com. SPF lives at example.com (the apex), not at _spf.example.com. DKIM lives at {selector}._domainkey.example.com. BIMI lives at default._bimi.example.com. MTA-STS advertisement lives at _mta-sts.example.com (with the policy file at https://mta-sts.example.com). Publishing at the wrong name is the single most common DNS-level error.

Multiple TXT records at the same name

RFC 7489 §6.6.3 requires receivers to treat any DMARC name with two or more v=DMARC1 TXT records as if no DMARC record exists. The same rule applies to SPF (RFC 7208 §4.5). Some DNS panels publish the long record fragmented across two TXT entries; some operators leave an old DMARC record behind when adding a new one. Both produce silent DMARC disablement.

Diagnose with:

dig +short TXT _dmarc.example.com

Must return EXACTLY ONE quoted string starting with v=DMARC1. Two or more responses, or one fragmented response with no DMARC1 prefix, means receivers see no DMARC.

Long TXT record RDATA quoting

DNS TXT RDATA limits a single quoted string to 255 characters; longer records must be split into multiple quoted strings concatenated by the resolver. Some DNS panels handle this automatically; some require manual splitting. A DKIM public key longer than 255 bytes published without proper quoting produces an invalid record. Verify with dig +short TXT — the output should show multiple quoted strings on the same line, which dig concatenates.

Trailing whitespace and embedded newlines

Some DNS panels accept multi-line input and preserve embedded newlines literally — the record value becomes "v=DMARC1;\np=none;..." and receivers cannot parse it. Always paste the record on a single line.

DNS TTL and propagation delay

After publishing a new DMARC / SPF / DKIM record, receivers continue to use the cached old record (or cached NXDOMAIN) until the previous record's TTL expires. Default TTLs are typically 1 hour to 1 day. Before declaring "DMARC not working", confirm the record propagated by querying an external resolver (dig @1.1.1.1 or dig @8.8.8.8).

7. Forwarding and mailing lists

Forwarding is the canonical hard case for DMARC. Plain forwarding (mailbox-level forwarding rule) breaks SPF because the forwarding server's IP is not in the original sender's SPF record. Mailing lists break DKIM because they modify the body (footer, unsubscribe link, subject prefix). Once you publish p=reject, every forwarded copy that fails BOTH SPF and DKIM alignment is refused at the receiver.

The three remediation strategies

Ranked by completeness:

1. ARC (RFC 8617) — the forwarding hop seals the pre-modification authentication result for downstream receivers. The receiver validates the ARC chain (cv=pass) and, if the sealing entity is trusted (e.g. Gmail trusts a known-good mailing list), uses the sealed verdict instead of the post-modification verdict. The ARC deep dive covers the full mechanism.
2. SRS (Sender Rewriting Scheme) at the forwarder — the forwarder rewrites the envelope MAIL FROM to one that points back to the forwarder's domain, so SPF aligns with the new envelope domain. The forwarder accepts the bounces. Solves SPF but not DKIM body modification.
3. Accept forwarding as a known-failing path at p=reject — educate users to subscribe to high-value mailing lists with personal addresses, publish operational documentation that mailing-list forwarding may fail under DMARC, accept the user-friction cost.

Receiver-specific behavior

Major mailbox providers (Gmail, Outlook, Yahoo) trust major ARC sealers (other major mailbox providers, some well-known mailing list operators). A message ARC-sealed by a recognized sealer with cv=pass can pass DMARC at the final receiver even though the post-modification SPF and DKIM both fail. Less well-known forwarders may not be trusted as ARC sealers; their seals are evaluated but do not override the post-modification verdict.

8. Mailbox-provider-specific issues

Every mailbox provider implements DMARC consistently with RFC 7489, but each surfaces different operational diagnostics and has quirks worth knowing.

Google (Gmail / Google Workspace)

Google publishes Postmaster Tools (postmaster.google.com) with per-domain spam rate, IP / domain reputation, feedback loop signals, and authentication breakdown. Google's Authentication-Results header is the most informative in the industry — it explicitly lists the matched domain for SPF (spf=pass smtp.mailfrom=) and DKIM (dkim=pass header.i=) so alignment is easy to verify. The DMARC for Google Workspace deployment guide covers the Workspace-specific setup. As of February 2024, Google enforces DMARC for any domain sending more than 5000 messages per day to gmail.com.

Microsoft (Outlook.com / Microsoft 365 / Exchange Online)

Microsoft uses CNAME-based DKIM with two selectors (selector1 / selector2) for automatic key rotation. The most common M365 DMARC failure is the onmicrosoft.com signing pattern: if you have not enabled custom-domain DKIM in the Microsoft 365 Defender portal, Exchange Online signs outbound mail with tenant.onmicrosoft.com instead of your domain, and DKIM never aligns. The DMARC for Microsoft 365 deployment guide walks through the Set-DkimSigningConfig PowerShell workflow.

Microsoft also publishes SNDS (Smart Network Data Services) for sending-IP reputation and JMRP (Junk Mail Reporting Program) for feedback loop signals. Both are required operational signals for high-volume senders.

Yahoo / AOL (Verizon Media Group)

Yahoo was the FIRST major mailbox provider to enforce strict DMARC on consumer addresses (publishing p=reject for yahoo.com / aol.com in 2014), which broke many mailing lists overnight and motivated the ARC standard. Yahoo's enforcement bar follows Google's lead — as of February 2024, Yahoo enforces DMARC for high-volume senders.

Mail.ru and Yandex (Russian providers)

Both implement DMARC and emit aggregate reports. Authentication-Results headers are in English. Reporting destinations sometimes drop rua= mail; check that your reporting destination is not blacklisted at these providers.

ProtonMail / Tutanota / privacy-focused providers

Enforce DMARC strictly. ProtonMail end-to-end encrypts message bodies, so DKIM body modification is rare (encrypted blob transits unchanged). Authentication-Results headers are present and informative.

9. Diagnostic toolkit

The minimum set of tools and commands every DMARC operator should keep within reach.

Command-line DNS queries

# DMARC record
dig +short TXT _dmarc.example.com

# SPF record (TXT at the apex)
dig +short TXT example.com | grep -i spf

# DKIM public key (replace selector with the value from the DKIM-Signature s= tag)
dig +short TXT selector._domainkey.example.com

# BIMI record
dig +short TXT default._bimi.example.com

# MTA-STS advertisement record
dig +short TXT _mta-sts.example.com

# TLS-RPT record
dig +short TXT _smtp._tls.example.com

# CAA records (CA authorization)
dig +short CAA example.com

# Query from a specific public resolver to bypass local caching
dig @1.1.1.1 +short TXT _dmarc.example.com

DMARC Analyzer integrated tools

• Domain Security Checker — live DNS lookups for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, and CAA in one report. Includes SPF lookup count for the 10-DNS-lookup limit.
• Email Header Analyzer — paste any message's full headers and see SPF, DKIM, DMARC results, ARC chain validation, and alignment evaluation. Built on includes/EmailHeaderParser.php.
• DNS Record Generator — generate syntactically-correct DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, and CAA records from a guided wizard.
• Blacklist Checker — check sending IPs against major RBLs / DNSBLs. Poor IP reputation drives spam-folder placement even with DMARC pass.

Aggregate-report ingestion

DMARC Analyzer ingests aggregate (RUA) reports via includes/DmarcParser.php (RFC 7489 §7.2 schema) and surfaces per- source-IP failure rates in the dashboard. Publish rua=mailto:dmarc-reports@example.com and forward the reports into the platform via the upload UI or IMAP / Microsoft Graph ingestion (includes/ImapFetcher.php / includes/GraphFetcher.php). Forensic (RUF) failure reports per RFC 6591 are parsed by includes/ForensicReportParser.php when the receiver supports ruf= emission.

Mailbox-provider postmaster portals

• Google Postmaster Tools (postmaster.google.com) — domain / IP reputation, spam rate, authentication breakdown.
• Microsoft SNDS (sendersupport.olc.protection.outlook.com/snds) — IP-level data for Microsoft 365 / Outlook.com.
• Microsoft JMRP — junk mail reporting program (feedback loop).

10. Troubleshooting best practices

1. Read aggregate reports weekly. Anomalies appear as new failing sources or volume spikes. A weekly cadence catches misconfigurations within days of introduction.
2. Capture full raw headers for every user-reported missed-mail incident. Forwarded message body without headers is unactionable.
3. Distinguish authentication failure from alignment failure early in every diagnosis. They have different fixes.
4. Verify DNS from an external resolver (dig @1.1.1.1) before concluding a record is broken. Local caching masks DNS issues.
5. Audit the SPF lookup count proactively. The 10-DNS-lookup limit is silent — you can be at 11 lookups and not know until aggregate reports show universal spf=permerror.
6. Enable custom-domain DKIM at every SaaS sender during onboarding, not later. Retrofitting alignment after you publish p=reject is incident-grade work.
7. Maintain a sending-source inventory. Every SaaS, every on-prem MTA, every automated job. Without the inventory you cannot reason about which failures matter.
8. Test new senders at p=none first. A new SaaS deployment at p=reject in the apex record can drop legitimate mail on day one.
9. Document mailing-list / forwarding as a known-failing path. Operations teams hit this question repeatedly; a written stance saves cycles.
10. Run the Domain Security Checker monthly. Records drift — someone adds an include:, someone publishes a stale DKIM key. The checker catches drift early.

11. Common diagnostic mistakes

1. Treating SPF pass + DKIM pass as "DMARC must be fine". Alignment is a separate check — both can pass authentication while neither aligns. See Pattern 1.
2. Publishing the DMARC record at the apex (example.com) instead of at _dmarc.example.com. Receivers look at the underscore-prefixed name only.
3. Leaving a second DMARC TXT record in place after editing — both the old and new are returned, the receiver disables DMARC.
4. Trusting that "the DNS panel saved the record" without verifying with dig. Some panels save records with embedded newlines, trailing whitespace, or wrong record type.
5. Skipping aggregate-report review because rua= is published and reports are being received. Receiving reports is necessary but not sufficient — reading them is the operational work.
6. Diagnosing a single failing message without capturing the full raw headers. Body-only or summary-only information rules out 80 percent of diagnostic paths.
7. Jumping straight to p=reject without clearing failures observed under p=none — see the rollout page.
8. Assuming forwarding will "just work" under p=reject. Forwarding is a known-failing path; plan ARC, SRS, or acceptance.
9. Adding senders to SPF without checking the lookup count. Each new include: nudges you toward the permerror ceiling.
10. Confusing 5321.From with 5322.From. SPF authenticates the envelope (5321); DKIM signs the body and verifies a signature carrying a d= tag; DMARC alignment compares against the visible From: header (5322). The alignment deep dive walks through the distinction.

12. Frequently asked questions

Why is my DMARC failing even though SPF and DKIM pass?

This is the single most common DMARC question and almost always indicates an ALIGNMENT failure rather than an authentication failure. SPF passes when the envelope MAIL FROM (5321.From) matches an authorized IP. DKIM passes when the DKIM-Signature verifies cryptographically. DMARC additionally requires that the domain used by SPF and/or DKIM ALIGNS with the visible From: header domain (5322.From). A SaaS sender that signs DKIM with sendgrid.net and uses bounces@em.sendgrid.net as the envelope passes both SPF and DKIM but FAILS DMARC because neither identifier aligns with your@example.com in the From: header. Fix by enabling custom-domain DKIM at the SaaS sender.

What does SPF permerror mean and how do I fix it?

SPF permerror is a permanent error in SPF evaluation, almost always caused by exceeding the 10-DNS-lookup limit defined in RFC 7208 §4.6.4. Every include:, a, mx, ptr, exists, and redirect mechanism counts as one DNS lookup. Nested include directives count recursively. Once your record requires 11 or more lookups, every recipient returns permerror and DMARC fails because SPF cannot produce a usable verdict. Fix by SPF flattening (replacing include: chains with literal ip4:/ip6: ranges using a flattening service), consolidating SaaS senders, or moving low-volume senders to DKIM-only authentication.

What does DKIM body hash mismatch mean?

DKIM body hash mismatch means the message body the receiver sees does not match the body hash (bh= tag) recorded in the DKIM-Signature when the message was signed. The signature itself may verify but DKIM still fails because the body changed in transit. Root causes: a mailing list appended a footer or unsubscribe link; an antivirus / security gateway modified the body (added a banner); the canonicalization mode is too strict (c=simple/simple cannot survive whitespace changes); the message was transcoded from quoted-printable to 8bit. Fix by using c=relaxed/relaxed canonicalization, removing modifying middleboxes, or deploying ARC (RFC 8617) so downstream receivers see the original DKIM verdict preserved across the modifying hop.

My DMARC record looks correct but receivers say no DMARC record found. Why?

Three common causes. (1) The TXT record is published at the wrong name: DMARC records live at _dmarc.example.com, not at the apex example.com. (2) Multiple TXT records at _dmarc.example.com — RFC 7489 §6.6.3 mandates that receivers treat multiple DMARC TXT records as if no record exists. Some DNS panels publish a fragmented record across two TXTs without warning. (3) DNS TTL not yet expired and a stale negative cache exists at the receiver. Verify with dig +short TXT _dmarc.example.com from an external resolver (e.g. dig @1.1.1.1) — if you see zero or two records, the problem is at your DNS panel; if you see one correct record, wait for the TTL.

How do I troubleshoot a single failing message from an aggregate report?

Aggregate (RUA) reports are sampled — they tell you which IP/result combinations are failing in aggregate, but they do not contain the original message. To debug a specific message: (1) identify the failing sender IP and result combination in the aggregate report; (2) check inside your sending estate (SaaS dashboards, on-prem MTA logs) for a message sent from that IP during the report-date window; (3) capture the full raw RFC 5322 headers — From:, DKIM-Signature:, Authentication-Results:, Return-Path:; (4) feed the headers into DMARC Analyzer's Email Header Analyzer (header_analyzer.php) which decodes SPF, DKIM, DMARC alignment, and the ARC chain for that specific message.

Why does my mail land in spam even though DMARC passes?

DMARC pass does not guarantee inbox placement. DMARC only verifies that the From: header domain is authorized; receivers still apply content-based spam scoring, reputation scoring, engagement scoring, and provider-specific signals. Pass plus poor reputation equals spam folder. Diagnostic checklist: (1) sending IP reputation (RBL/DNSBL listings — use the Blacklist Checker); (2) sender domain reputation (Google Postmaster Tools, Microsoft SNDS); (3) authenticated FBL signals (high spam complaint rate); (4) reverse DNS / PTR record matches the HELO hostname; (5) BIMI deployed and a valid VMC published; (6) content triggers (excessive caps, suspicious links, missing List-Unsubscribe header).

What is the difference between SPF temperror and SPF permerror?

SPF temperror is a TRANSIENT failure (DNS server returned SERVFAIL or a timeout) — the receiver may retry and SPF may eventually pass. Most receivers treat temperror as neutral, meaning DMARC falls back to DKIM. SPF permerror is a PERMANENT failure (record syntactically invalid, exceeded 10-lookup limit, contains a deprecated mechanism like ptr) — every recipient returns permerror until you fix the record. Permerror is a DMARC-fail signal because it indicates the sender owner published a broken record. Diagnose with: dig +short TXT example.com | grep spf1 plus an online SPF validator that counts lookups (we recommend running the Domain Security Checker at domain_checker.php).

Why does forwarded mail fail DMARC after I enable p=reject?

Forwarding breaks SPF (the forwarding server's IP is not in the original sender's SPF record) and can break DKIM (mailing lists modify the body, breaking the body hash). Once you publish p=reject, every forwarded copy that fails both SPF and DKIM alignment is refused — affecting users who forward from corporate to personal mailboxes, mailing list subscribers, and security gateways with mail rewriting. Three remediations: (1) deploy ARC (RFC 8617) so the forwarding server can preserve the original authentication result for downstream receivers; (2) ask the forwarding service to use SRS (Sender Rewriting Scheme) so SPF still aligns; (3) accept that mailing-list forwarding is a known-failing path under strict DMARC and educate users to subscribe with personal addresses for high-value list traffic.

13. Related guides

• DMARC explained — the central DMARC primer covering the broader DMARC ecosystem, aggregate-report XML schema, and mailing-list / forwarding interactions.
• DMARC record tags explained — every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) with syntax, defaults, and interaction rules.
• DMARC myths and misconceptions debunked (the TROUBLESHOOTING-MYTH-RESOLUTION companion to this diagnostic playbook) — the TROUBLESHOOTING-MYTH-RESOLUTION companion documenting the 18 most common DMARC mental-model ERRORS whose RECURRING TROUBLESHOOTING SYMPTOMS this playbook diagnoses at the protocol-layer but whose ROOT CAUSE often resolves to a defender- side myth rather than a protocol-layer bug. Where THIS playbook documents the 7 canonical DMARC-fail diagnostic patterns in protocol-precise terms (Pattern 1 alignment failure decode, Pattern 2 SPF forwarding break, Pattern 3 DKIM selector typo, Pattern 4 SPF lookup-limit overrun, Pattern 5 ARC-seal absence, Pattern 6 Authentication-Results parse edge cases, Pattern 7 receiver-specific quirks), the myths-and-misconceptions spoke documents the 18 RECURRING MYTHS whose specific instances appear AS Pattern 1-7 troubleshooting cases: (i) Pattern 1 alignment failures often resolve to the myth "DMARC alignment and DKIM signing are the same" — operator signed with ESP's d= domain not their own, sees dkim=pass + aligned=false in every row; (ii) Pattern 2 SPF forwarding breaks often resolve to "My ESP/forwarder will just handle DMARC for me" — operator didn't deploy ARC and now sees legitimate-mail false positives at every forwarder hop; (iii) Pattern 4 SPF lookup-limit overruns often resolve to "M365 SPF include is just 'add spf.protection.outlook.com'" — that single include consumes 3 of the 10 budget slots before any third-party-sender is added; (iv) recurring "DMARC blocks all phishing" complaints when the operator sees display-name spoofing post-p=reject resolve to the myth "DMARC blocks all phishing" — alignment is evaluated against the From: address domain not display-name phrase; (v) recurring "p=none is doing nothing" frustration resolves to the myth "p=none means DMARC is off" — Phase 3 is where the sender-inventory empirical evidence is built that the operator needs BEFORE Phase 4-5; (vi) recurring "I went straight to p=reject and everything broke" resolves to "I'll just go straight to p=reject" — the multi-phase ramp exists precisely to prevent this outcome. Read THIS troubleshooting page WITH the myths-and-misconceptions spoke when a recurring failure-pattern resists protocol-level fixes: the underlying defect is often a defender- side mental-model error rather than a protocol-layer bug. Where THIS page documents the PROTOCOL-LAYER DIAGNOSTIC FLOW, the myths-and-misconceptions spoke documents the 18 DEFENDER-SIDE MENTAL-MODEL ERRORS that the protocol-layer diagnostic flow repeatedly traces back to as the actual root cause.
• DNS propagation explained (the #1 root cause of "I published the record but it's not visible / not working") — the troubleshooting reference for the single most-reported operator complaint: "I published the DMARC record yesterday but the dashboard still shows the old record" / "I added DKIM but dig still returns NXDOMAIN" / "I changed p=none to p=quarantine last night but Gmail is still treating it as p=none". DNS propagation is not a wave: it is the gradual aging-out of cached records across millions of recursive resolvers, governed by the per-record TTL (RFC 1035 §3.2.1 + RFC 2181 §8) plus the resolver's own minimum and maximum cache caps — which means a record published at the authoritative nameservers takes anywhere from seconds (if all recursive caches are cold) to days (if the previous record had a multi-day TTL and the most recent lookup happened just before the change) to be visible at every recursive resolver that will evaluate the next message. The propagation reference documents the diagnostic workflow: dig / kdig directly against the authoritative nameservers (e.g. dig _dmarc.example.com TXT @ns1.your-dns-provider.com) to confirm the change has been published, then dig against multiple geographically diverse recursive resolvers (1.1.1.1 / 8.8.8.8 / 9.9.9.9) with the +norecurse flag to confirm what each recursive cache currently believes, then the web-based propagation checker (whatsmydns.net or similar) for the global recursive-cache snapshot. It also documents the resolver-cache-cap quirks that surprise operators: Cloudflare's 1.1.1.1 enforces a minimum negative-cache TTL of 300 seconds even when the SOA minimum is lower, Google's 8.8.8.8 caps all TTLs at 21 600 seconds (6 hours) regardless of authoritative value, and some corporate / ISP resolvers cap the minimum at 1800 seconds — all of which mean an emergency-rollback record change will NOT be visible everywhere within the TTL window you expect. Read this when any operator complaint contains the phrase "I just published" or "I changed it but it's still showing the old value" — propagation is almost always the explanation.
• DMARC alignment explained — identifier alignment (the SPF/DKIM-domain-matches-From: rule) that determines DMARC pass/fail. The most-common DMARC fail mode (Pattern 1) is an alignment failure.
• DKIM alignment with DMARC — the TROUBLESHOOTING-DKIM-FAIL-SYMPTOM- RESOLUTION-TO-DKIM-ALIGNMENT-CONTRACT companion to this DMARC symptom-driven debugging reference. Where THIS page documents the eight-pattern symptom- driven DMARC-fail diagnostic ladder (Pattern 1 alignment-failure, Pattern 2 ESP-cohabitation-d=-misalignment, Pattern 3 mailing-list ARC-break, Pattern 4 subdomain-policy gap, Pattern 5 DNS-propagation lag, Pattern 6 SPF- lookup-overlimit cascade, Pattern 7 forwarder-induced SPF-break, Pattern 8 cousin-domain look-alike), the DKIM-alignment-with-DMARC spoke documents the PER-MODE BYTE-SHAPE EVALUATION CONTRACT every Pattern-1 / Pattern-2 / Pattern-3 root-cause diagnosis resolves to at the DKIM-side identifier-alignment- evaluation layer: strict-alignment (adkim=s) requires byte-identical d=<domain> vs Header-From-domain match; relaxed-alignment (adkim=r, the DMARC default) requires Organizational- Domain match per the PSL-anchored eTLD+1 algorithm (sub.example.com d= aligns with example.com Header-From under relaxed but not strict). Concretely the DKIM-alignment-with-DMARC spoke documents per-mode dkim= verdict emission in Authentication-Results, per-mode DMARC RUA-aggregate-report dkim_aligned column attribution, per-mode operator decision matrix when to publish adkim=s vs adkim=r given subdomain-vs-apex signing topology + ESP-cohabitation pattern + cousin-domain look-alike defense posture, and per-mode false-positive blast-radius profile during a DKIM-fail debugging session. Without the DKIM- alignment-with-DMARC spoke a troubleshooter reading THIS page recognises the symptom ("dkim=pass but DMARC fails"), but lacks the canonical per-mode evaluation-contract reference required to resolve WHY the per-message d= tag vs Header-From-domain evaluation produced the unaligned verdict the RUA-aggregate-report row materialises — this link closes that symptom-to-evaluation-contract resolution gap at the DKIM-side identifier-alignment diagnostic layer.
• DMARC policy rollout — the operational migration from p=none through p=quarantine to p=reject. Most troubleshooting happens during the rollout journey.
• DMARC deployment checklist — the GREEN-PATH operational reference for first-time DMARC publication; THIS troubleshooting page is the RED-PATH diagnostic companion when a checklist step fails in the field. Read the deployment- checklist spoke FIRST when authoring a new DMARC record from scratch — it documents the pre-flight sender inventory step, the SPF + DKIM prerequisite verification, the baseline RUA-stream instrumentation, and the post-publication monitoring cadence that, when followed correctly, prevents the most common DMARC-deployment failure modes documented in §3-§8 of THIS page (missing receiver-side adoption of the published policy, RUA-reports not arriving, forwarders breaking SPF + missing DKIM signing, multi-domain alignment failure on subdomains the operator forgot to inventory). The cross-link is bidirectional: many recurring DMARC-fail troubleshooting cases traced through this page resolve to a skipped checklist step rather than a protocol-design gap — read the deployment- checklist alongside this page when a recurring failure pattern in the RUA stream resists protocol-level fixes, because the actual root cause is often a missing inventory entry from the pre-flight phase.
• DMARC policy modes — p=none vs p=quarantine vs p=reject — the head-to-head COMPARISON of the three DMARC enforcement values. Read this when an operator asks "why did p=reject break my legitimate mail": the COMPARISON page documents the per-receiver SMTP rejection codes (Gmail 550 5.7.26, Microsoft 365 550 5.7.509, Yahoo 553 5.7.1) and the rollout-skipping footgun that produces self-inflicted DMARC outages — the most-asked DMARC operational question.
• DMARC attacker bypass — the residual-attack-surface companion catalogue to this protocol-fail diagnostic playbook — the RESIDUAL-ATTACK-SURFACE companion catalogue documenting the eight structurally- distinct attacker techniques that bypass DMARC at p=reject WITHOUT producing any DMARC-fail troubleshooting symptom in the RUA stream — the diagnostic blind spot this troubleshooting playbook does NOT see. Where THIS playbook diagnoses the SEVEN canonical protocol-fail patterns visible in the aggregate-report XML (alignment failure, SPF forwarding break, DKIM selector typo, SPF lookup-limit overrun, ARC-seal absence, Authentication-Results parse edge cases, receiver-specific quirks — all observable as policy_evaluated.dkim=fail / policy_evaluated.spf=fail rows in the daily RUA delivery), the attacker- bypass spoke catalogues the EIGHT BYPASS TECHNIQUES that produce NO RUA evidence at all because they NEVER trigger DMARC evaluation against the victim's domain: (i) lookalike-domain registration (attacker registers a Unicode IDN homograph or near-miss ASCII variant — DMARC evaluates the LOOKALIKE domain's policy, which the attacker controls), (ii) display- name spoofing (the visible "From: CEO <attacker@gmail.com>" pattern where the From-header phrase carries the impersonation but the parenthesised addr-spec belongs to the attacker — DMARC evaluates the attacker's gmail.com identifier, which passes), (iii) compromised legitimate sender (attacker takes over a legitimately-aligned ESP-tenant or partner-domain account and sends from infrastructure that already passes DMARC at p=reject), (iv) subdomain takeover (attacker discovers an orphaned CNAME pointing at a deprovisioned cloud resource, registers the dangling target, and sends from the subdomain whose DMARC policy inherits the organisational parent — no DMARC-fail because the message is genuinely aligned), (v) Reply-To injection (the visible From: passes DMARC alignment but Reply-To points at attacker-controlled infrastructure — the reply path is attacker-controlled while the original message produces a green RUA row), (vi) ARC-Authentication-Results chain-of-custody trust forgery (intermediate-trusted forwarder forges an ARC seal that compensates for broken SPF / DKIM under forwarding — receiver-side ARC-trust policy ALLOWS the alignment- fail-to-pass override, no DMARC-fail row), (vii) mailing-list amplification attack (attacker enrols victim domain on a list that strips and re-signs with its own DKIM — list re-emission passes DMARC against the LIST's domain, not the original sender), (viii) third-party-vendor compromise (attacker compromises an ESP-tenant the victim authorises via include: / DKIM key delegation and inherits the ESP's alignment authority). Read the attacker-bypass spoke WITH this troubleshooting playbook when an operator reports "we are at p=reject but phishing complaints keep coming and the RUA is clean" — the answer is the eight-technique catalogue the attacker- bypass spoke documents, which by construction produce NO diagnostic symptom this troubleshooting playbook can surface from the aggregate-report XML alone.
• Business Email Compromise (BEC) — the FINANCIAL-FRAUD-OUTCOME-OPERATIONAL- COMPANION to THIS DMARC troubleshooting diagnostic playbook. Where THIS page documents the seven canonical protocol-fail patterns visible in the aggregate-report XML (alignment failure, SPF forwarding break, DKIM selector typo, SPF lookup-limit overrun, ARC-seal absence, Authentication- Results parse edge cases, DMARC-record- syntax errors), the business_email_compromise spoke documents the SIX BEC VARIANTS whose RUA-diagnostic-signature this playbook's per-symptom diagnose-and-fix sequence catalogues — and which the DMARC-protocol- fail diagnostic is the FIRST forensic- evidence-collection step for. Four structurally-distinct DMARC-troubleshooting- as-BEC-incident-response operational classes the spoke covers that THIS troubleshooting reference intentionally elides: (i) per-BEC-variant the canonical DMARC-symptom signature this troubleshooting page diagnoses — CEO fraud / invoice fraud / payroll diversion / gift-card scam / M&A fraud / VEC each produce a distinctive DMARC-fail-pattern signature in the aggregate-report stream that THIS page's decision tree resolves to specific root causes; (ii) BEC-incident-response diagnostic-evidence preservation prerequisite — the FBI Financial Fraud Kill Chain playbook documented on the BEC spoke REQUIRES preserving the raw aggregate-report row evidence BEFORE this troubleshooting page's remediation steps are applied (lest the remediation step ALTER the DMARC publish state and destroy the forensic evidence the incident-response playbook depends on); (iii) BEC- defense-readiness as DMARC-protocol-health upstream gate — the BEC spoke documents the SIX-LAYER PROACTIVE defense stack of which "publish-and-maintain DMARC p=reject" is the single most operationally-valuable application-layer defense; THIS troubleshooting playbook is the operational discipline that maintains that defense over time; (iv) BEC FBI-IC3 cost-statistic executive- sponsorship framing — the BEC spoke catalogues BEC vs ransomware cost statistics that justify the executive sponsorship needed to fund the systematic DMARC operational discipline THIS troubleshooting reference presupposes; without executive sponsorship, the diagnostic decision tree this page documents is operationally orphaned. Required reading once an operator using this troubleshooting page diagnoses a suspected fraudulent message and needs to cross-reference the BEC-variant attacker-technique catalogue for incident-response classification.
• DMARC aggregate (RUA) reports — the daily XML stream that surfaces every DMARC failure for inventory and root-cause analysis.
• DMARC monitoring discipline — the OBSERVABILITY-CADENCE-COMPANION documenting the daily-weekly-quarterly monitoring rhythm that produces the empirical RUA-stream signals every protocol-fail diagnostic pattern catalogued on THIS troubleshooting page is REACTIVELY TRIGGERED by. Where THIS playbook documents the SEVEN canonical DMARC-fail diagnostic patterns (Pattern 1 alignment failure, Pattern 2 SPF forwarding break, Pattern 3 DKIM selector typo, Pattern 4 SPF lookup- limit overrun, Pattern 5 ARC-seal absence, Pattern 6 Authentication-Results parse edge cases, Pattern 7 receiver-specific quirks) the operator pursues AFTER an observation event flags the failure, the DMARC-monitoring spoke documents the FOUR canonical observation-event classes whose recurring pattern in the RUA stream is what BRINGS each diagnostic pattern to the operator's attention in the first place: (i) daily-failure-row-count delta observation — the operator's monitoring dashboard reports a sudden spike in policy_evaluated.dkim=fail / policy_evaluated.spf=fail row count between consecutive UTC-day RUA batches, which is the canonical TRIGGER for the Pattern 1 alignment-failure decode-and-fix sequence THIS page documents; (ii) per-source-IP failure-attribution observation — the operator's monitoring view groups failures by source_ip and surfaces a new high-volume sender-IP whose alignment never aligned from day one, which is the canonical TRIGGER for the Pattern 2 SPF-forwarding- break root-cause-resolution sequence THIS page documents; (iii) RUA-arrival- cadence anomaly observation — the operator's monitoring instrumentation reports a multi-day gap in arriving aggregate reports (no reports from Microsoft 365 in 72 hours, partial coverage from Yahoo), which is the canonical TRIGGER for the publisher-side rua= tag addressing decode-and-fix sequence THIS page documents in §3 ("RUA reports not arriving"); (iv) policy-distribution ramp observation — the operator's monitoring report compares the operator- published p= value against the policy_evaluated.disposition column in each RUA-row, which is the canonical TRIGGER for the rollout-blocker decision-branching sequence THIS page documents when receiver-side adoption lags the publisher-side policy ramp. Read the DMARC-monitoring spoke WITH this troubleshooting page as a cause-and-effect pair: the monitoring spoke documents the OBSERVABILITY-CADENCE that PRODUCES the empirical evidence every diagnostic pattern on THIS page is constructed to consume, and this troubleshooting page documents the RESOLUTION-PATH every monitoring observation eventually flows into. Where THIS page is the REACTIVE diagnostic playbook the operator opens when something breaks, the monitoring spoke is the PROACTIVE observability-discipline reference that catches the break before any operator complaint reaches the inbox.
• DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery (the TROUBLESHOOTING-PIPELINE-CONSUMER companion to this DMARC-fail diagnostic playbook) — the TROUBLESHOOTING-PIPELINE-CONSUMER companion documenting the END-TO-END infrastructure path that puts the aggregate- report XML stream THIS troubleshooting page consumes in front of the operator: receiver- side report generation cadence (Gmail 24-hour UTC-aligned batch, Microsoft 365 hourly rolling window, Yahoo 24-hour UTC-aligned batch, Mail.ru 24-hour UTC-aligned batch, each emitting a per-domain per-day RUA report with one record block per source_ip × From:-domain × identifier-alignment combination), publisher-side rua= tag addressing (the comma-separated mailbox list whose external-domain entries require a _report._dmarc.example.com delegation record per RFC 7489 §7.1, whose size limit (!10m URI suffix, bytes), whose maximum mailbox count (2 per receiver per RFC 7489 §6.2.6), and whose IDN encoding rules trip the most-common publisher misauthoring patterns), mailbox-side IMAP / Microsoft Graph ingestion (the imap_fetch.php / ImapFetcher / GraphFetcher ingestion path that polls the configured RUA mailbox, downloads the application/zip or application/gzip attachment, unwraps to the inner aggregate-report XML, and dispatches to the parser), parser-side XML-to-row decomposition (DmarcParser walks the RFC 7489 §7.2.1 XSD-validated record blocks, extracts per-source_ip policy_evaluated.dkim/spf verdicts, mints rows in dmarc_records, indexes by dmarc_reports.id), and ingestion-failure failure modes (RUA mailbox misconfigured, IMAP credential expired, external-domain delegation missing, zip corruption, XML schema-validation failure). Read THIS troubleshooting page WITH the reporting-pipeline reference when an operator reports "I published rua= two weeks ago but the dashboard shows zero reports" — the diagnostic flow starts at the publisher-side rua= tag and walks the pipeline reference's stages in order until the break is located. Where THIS page documents PROTOCOL-LAYER DMARC-fail decode methodology (alignment failure decode, SPF lookup-overrun, DKIM selector typo, ARC-seal absence, Authentication-Results parse edge cases), the reporting-pipeline spoke documents the INFRASTRUCTURE-LAYER empty-stream and parse-failure diagnostic path that produces the empirical evidence every protocol-layer decode in §3-§8 of this page consumes.
• Email authentication explained — the cluster-intro pillar covering the full SPF + DKIM + DMARC + ARC + BIMI + MTA-STS + TLS-RPT + CAA ecosystem.
• Email authentication glossary — definitions for every term-of-art used on this page (5321.From, 5322.From, permerror, canonicalization, AUID, organizational domain, PSL, ARC chain).
• Email security glossary — DEBUGGING-THREAT-VOCABULARY for source_ip triage when distinguishing legitimate-misconfiguration vs malicious-spoofing — the DEBUGGING-THREAT-VOCABULARY companion to this DMARC troubleshooting playbook for the operator population reaching the attribution-correctness decision point in source_ip triage. Where THIS page documents DMARC-fail decode methodology in infrastructure-agnostic protocol terms (SPF lookup overrun, DKIM selector typo, ARC-seal absence, Authentication-Results parse edge cases), the email-security glossary documents the THREAT-VOCABULARY the operator needs at the moment they encounter an unrecognised source_ip row in their RUA stream and must decide whether the row is (a) legitimate but misconfigured (forwarder hop, ESP onboarding, new mail flow) — the protocol-debugging path documented on this page — or (b) malicious — a different attribution path that uses the threat-vocabulary the glossary documents: spear phishing (targeted attacker reconnaissance signature in From-header construction), whaling (CEO/executive-impersonation signature in display-name vs envelope-domain mismatch), lookalike domain (Unicode- homoglyph / typo-squatting / TLD-swap attack signature in header_from organizational-domain analysis), account-compromise BEC (legitimate-sender authentication-pass signature with attacker-content payload), APT (well-resourced adversary class behind sophisticated DKIM-replay / ESP-account-takeover attacks), vendor invoice fraud (supply-chain compromise signature in accounts-payable-bound mail flow). Read the email-security glossary when this troubleshooting playbook's protocol- debugging path is exhausted and the attribution question shifts from "what protocol error caused this fail" to "is this fail attacker-generated and which threat-class is it" — the glossary is the authoritative reference for the threat-class taxonomy that determines whether the next step is incident-response escalation, vendor-management notification, or legitimate-sender misconfiguration remediation.
• SPF explained — Sender Policy Framework (RFC 7208). Includes the 10-DNS-lookup limit and flattening strategies.
• SPF DNS-TXT-record byte syntax — the DMARC-FAIL-SYMPTOM-DRIVEN-DEBUGGING- AT-FOUR-SPF-BYTE-SYNTAX-ROOT-CAUSE-CLASSES diagnostic companion to this DMARC troubleshooting guide. Where THIS page is the symptom-driven debugging reference for DMARC-fail outcomes as a WHOLE (RUA decoding, alignment-failure root-cause analysis, canonical DMARC failure patterns), the SPF-DNS-syntax spoke is the BYTE-GRAMMAR-REFERENCE diagnostic for SPF-AUTHORING-ERROR ROOT CAUSES — one of the highest-frequency operator-encountered SPF misconfiguration patterns the troubleshooting playbook diagnoses downstream. The DMARC-TROUBLESHOOTING- DRIVES-OPERATOR-TO-SPF-BYTE-SYNTAX-REFERENCE cross-reference establishes FOUR structurally-distinct SPF-byte-syntax root-cause classes the troubleshooting playbook surfaces as DMARC-fail symptoms in the RUA aggregate-report stream: (i) v=spf1 version-prefix typos producing systematic spf=permerror across all senders — operators frequently publish v=spf 1 (with embedded space), v=SPF1 (uppercase violating the RFC 7208 §4.5 lowercase convention for version-prefix), or bare spf1 (missing the v= tag prefix entirely); receiver-side SPF evaluators reject these as malformed and return permerror, which manifests in RUA aggregate data as a systematic spf=permerror verdict across 100% of the publisher's outbound stream — a high-signal symptom the troubleshooting playbook decodes as a root-level SPF-record authoring error rather than a per-sender misconfiguration; (ii) qualifier byte-malformation producing undefined receiver-side behaviour — operators publishing + all (with embedded space between qualifier and mechanism), -Al (missing letter), or bare all (missing qualifier entirely) trigger receiver-side parser divergence: some receivers return permerror; some default to the implicit ?all neutral qualifier per RFC 7208 §4.7 (which produces undefined-result behaviour, NOT the operator's intended -all failure verdict); the troubleshooting playbook detects this class as a SPF-RECORD-AUTHORING-DEFECT whose root-cause requires the byte-syntax reference to resolve; (iii) per- mechanism token whitespace/colon errors producing per-mechanism evaluation failures — operators publishing ip4: 1.2.3.4 (with space after colon), include: example.com (with space after colon), or ip4:1.2.3.4/ (with trailing slash absent CIDR-prefix length) all violate RFC 7208 §5 per-mechanism byte-grammar, producing permerror at the failing mechanism's evaluation step; the troubleshooting playbook surfaces this as a SELECTIVE per-mechanism failure (different from class (i)'s whole-record-permerror) whose root-cause diagnosis requires the byte-syntax reference's per-mechanism tokenization rules; (iv) 255-byte TXT-string fragmentation errors producing DNS-resolver truncation or per-resolver handling divergence — RFC 1035 §3.3.14 constrains each TXT-record string to 255 bytes maximum; operators publishing a single 256-byte string (a common operational defect when consolidating nested includes into a single record) trigger DNS-resolver truncation OR per-resolver handling divergence — some resolvers concatenate multi-string TXT records, some return only the first string, some return servfail; the troubleshooting playbook decodes this as a DNS-LAYER-INTERACTION defect whose per-resolver-handling impact the byte-syntax reference documents at the canonical per-string fragmentation boundary. Read the SPF-DNS-syntax spoke when the troubleshooting playbook's RUA decoder surfaces spf=permerror as the diagnostic verdict — the spoke is the canonical next-step root-cause reference whose byte-grammar rules determine which of the four classes the operator's defect belongs to.
• include: vs ip4: vs a: vs mx — the SPF-MECHANISM-MISCONFIGURATION-DIAGNOSTIC companion to this DMARC troubleshooting guide. Where THIS page is the symptom-driven debugging reference for DMARC-fail outcomes as a WHOLE (RUA decoding, alignment-failure root-cause analysis, canonical DMARC failure patterns), the include-vs-ip4-vs-a-vs-mx spoke is the focused per-mechanism-class diagnostic reference for SPF-RECORD- AUTHORING ERRORS — one of the highest- frequency operator-encountered SPF misconfiguration patterns the troubleshooting playbook diagnoses. The spoke catalogues the canonical mechanism- choice ERRORS — over-broad ip4:0.0.0.0/0 wildcards (universal-pass anti-pattern that breaks DMARC's anti-spoofing guarantee), stale ip4: blocks (frozen at authoring-time, no longer reflect the sender's current IP set — produces SPF=fail rows in aggregate reports for the LEGITIMATE-but-rotated sender IPs), misuse of a: for a CDN-pooled hostname (the A-record-identified IPs rotate faster than the SPF cache), misuse of mx: for a domain whose MX hosts are inbound-only (not outbound — the MX-resolved IPs cannot produce SPF=pass for outbound mail because outbound mail does not originate from those IPs), redundant include: chains that cumulative-cost over the 10-lookup limit (producing the permerror-on-overlimit failure DOCUMENTED in help_spf_permerror_vs_temperror.php), and missing include: tokens for newly-onboarded SaaS senders (producing SPF=fail rows in aggregate reports for the newly-onboarded sender IPs that never made it into the SPF record). Read the include-vs-ip4-vs-a-vs-mx spoke when triaging a high-volume spf=fail pattern from aggregate-report data in scenarios where the failing IPs are KNOWN LEGITIMATE senders — the mechanism-choice diagnostic in the spoke is the canonical next step in the diagnostic decision tree AFTER the troubleshooting playbook has narrowed the root cause to SPF-record- authoring rather than transport, alignment, or third-party-sender re-signing.
• SPF for Microsoft 365 — the M365-TENANT-SPF-MISCONFIGURATION-DIAGNOSTIC companion to this DMARC troubleshooting guide. Where THIS page is the cluster-spanning symptom-driven debugging reference for DMARC-fail outcomes as a WHOLE (RUA decoding, alignment-failure root-cause analysis, the canonical DMARC failure patterns), the SPF-for-M365 spoke is the focused per-platform-class diagnostic reference for the M365-tenant- specific SPF misconfiguration patterns that dominate the DMARC-fail decoded-RUA roster for any operator running an M365 tenant. The spoke catalogues the canonical M365-tenant SPF-authoring ERRORS that surface as spf=fail rows in aggregate reports — missing or stale include:spf.protection.outlook.com baseline token (the entire M365 outbound envelope produces SPF=fail), accidental include:-chain cumulative-cost overruns when M365 operators bolt on secondary SaaS-sender includes without flattening (M365's own include consumes ~3 lookups of the 10-lookup budget, leaving 7 for secondary senders — a common-misconfiguration overrun), hybrid-Exchange-on-prem hostname omissions (on-prem Edge / Exchange Server outbound hostnames must be added as explicit ip4: or a: tokens because they are NOT covered by the Microsoft-managed spf.protection.outlook.com include — omitting them produces spf=fail for legitimate on-prem-routed mail), +all qualifier degradation (a universal-pass anti-pattern published by misinformed M365 admins that breaks DMARC's anti-spoofing guarantee), third-party SMTP-AUTH-from-outside-M365 submission gap (third-party tools authenticating to M365 SMTP from outside the M365 IP envelope produce SPF=fail because spf.protection.outlook.com only covers Microsoft-managed outbound IPs), and the Direct-Send coverage boundary (M365 Direct Send routes mail through M365 outbound IPs and IS covered by the include, but third-party SMTP-AUTH submission is NOT). Read the SPF-for-M365 spoke when triaging a high-volume spf=fail pattern from aggregate-report data on an M365-tenant — the M365-specific authoring diagnostic in the spoke is the canonical next step in the diagnostic decision tree AFTER the troubleshooting playbook has narrowed the failing IP-block to the M365 outbound envelope or to an M365-adjacent on-prem hybrid topology.
• SPF forwarding issues (the second-hop break) — the symptom-to-root-cause diagnostic reference for the forwarder-mediated SPF-failure pattern this page diagnoses — the FORWARDER-SECOND-HOP-SPF-BREAK diagnostic companion to this DMARC troubleshooting guide. Where THIS page is the symptom-driven debugging reference for DMARC-fail outcomes as a whole (RUA decoding, alignment-failure root-cause analysis, the canonical DMARC failure patterns), the forwarding-issues spoke is the focused per-forwarder-class diagnostic reference for ONE of the highest- frequency operator-encountered DMARC-fail patterns: the legitimate-sender + forwarder-second- hop SPF break, which surfaces as a DMARC-fail row in aggregate reports with the diagnostic-fingerprint signature spf=fail + dkim=pass + aligned=true (DKIM-only) or, when the forwarder ALSO breaks DKIM (Mailman pre-1980 list-footer injection), the full spf=fail + dkim=fail + aligned=false failure pattern. Read the forwarding-issues spoke when the symptom-to-root-cause analysis on THIS page narrows a DMARC-fail cluster to the forwarder- topology root cause, and you need the per-forwarder-class catalogue (corporate mailing list, vacation .forward, MLM expander, alumni-alias, .edu redirect) plus the three forwarder-survival fixes (SRS, ARC, DKIM-only DMARC alignment) documented on the forwarding-issues spoke to confirm WHICH fix applies to each diagnosed forwarder topology before authoring the remediation commit.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the SPF-PERMERROR-#1-ROOT-CAUSE- DIAGNOSTIC-LADDER companion to this DMARC troubleshooting guide. Where THIS page is the symptom-driven diagnostic reference for DMARC-fail outcomes as a whole (RUA decoding, alignment-failure root-cause analysis, the canonical DMARC failure patterns), the SPF- lookup-limit spoke is the OPERATIONAL DEEP-DIVE on the OPERATIONALLY-MOST- COMMON DMARC-fail root cause across production environments — the cumulative include-cascade overrun of the RFC 7208 §4.6.4 10-DNS-query budget that surfaces as SPF permerror in Authentication-Results AND drives the downstream DMARC-fail cascade the operator triages from THIS page's symptom catalogue. Four structurally- distinct DMARC-TROUBLESHOOTING-VS-SPF- LOOKUP-LIMIT diagnostic-ladder classes the spoke covers that THIS troubleshooting reference intentionally elides: (i) SPF permerror as DMARC-fail root cause — diagnostic ladder entry point — when THIS page's symptom catalogue diagnoses an SPF permerror outcome in RUA evidence rows, the SPF-lookup- limit spoke is the canonical diagnostic-ladder entry point because ≥80% of production SPF permerrors are caused by the lookup-limit overrun (the remaining ~20% split across malformed-syntax, multiple-record, and unsupported-mechanism causes that THIS troubleshooting page also documents); (ii) lookup-audit diagnostic workflow with concrete tooling — the spoke documents the operator-side lookup- audit workflow using dig +short TXT <domain> to retrieve the raw SPF record, followed by recursive include- expansion via Kitterman's SPF Surveyor / spf-tools-perl / EmailToolTester SPF lookup counter to compute the precise cumulative lookup cost the receiver's evaluator would observe; (iii) void-lookup secondary-cap diagnostic for stale includes — the spoke documents the RFC 7208 §4.6.4 secondary cap that THIS troubleshooting guide's symptom catalogue may surface as an unexplained permerror despite a lookup-count under 10 — the void- lookup secondary cap fires when more than 2 lookups return NXDOMAIN / NoData, typically caused by stale include tokens pointing at deleted vendor DNS records that escape the ordinary lookup-count audit; (iv) four-remediation-path decision-framework — the spoke documents the operator- recommended order of remediation (lookup-audit → subdomain delegation → sender consolidation → monitored SPF flattening) that THIS troubleshooting guide's permerror-symptom diagnosis must terminate at. Required reading once an operator running THIS troubleshooting guide's diagnostic playbook reaches an SPF permerror symptom in the RUA evidence stream — the spoke's lookup-audit workflow + budget-overrun-remediation framework is the canonical next step in the diagnostic ladder.
• SPF PermError vs TempError — the diagnostic-workflow reference for the two SPF-failure result codes — the focused per-error-code diagnostic companion to THIS DMARC troubleshooting guide. Where THIS page is the symptom-driven diagnostic reference for DMARC-fail outcomes as a whole (RUA decoding, alignment-failure root-cause analysis, the canonical DMARC failure patterns), the permerror-vs-temperror spoke is the focused per-code reference on the two SPF-failure result codes (RFC 7208 §2.6.7 PermError + §2.6.8 TempError) that propagate into DMARC's policy_evaluated/spf=fail verdict via the SPF-component auth_results/spf/result field. The spoke distinguishes the PermError verdict (record-grammar violations, 10-DNS-lookup limit per §4.6.4, macro-expansion failures per §7 — all permanent failures requiring operator-side record edits) from the TempError verdict (DNS resolver timeouts, SERVFAIL responses, transient name-resolution failures — likely self-resolving). Critical when this troubleshooting guide's DMARC-fail-with-SPF-component-failed diagnostic branch needs to distinguish "the operator's SPF record is broken — fix the grammar or shed includes" (PermError) from "the receiver's DNS resolver had a transient outage — investigate only if it persists across many reporting intervals" (TempError). Receiver treatment differs: Gmail and Microsoft both fail-open on TempError to avoid delivery loss but treat PermError as a hard SPF-fail feeding DMARC evaluation.
• SPF qualifiers explained (+ / — the QUALIFIER-MISCONFIGURATION-ROOT-CAUSE diagnostic companion to this DMARC troubleshooting guide. Where THIS page documents the symptom-driven diagnostic ladder for DMARC-fail outcomes (Pattern 1 SPF-alignment failure, Pattern 2 envelope- domain mismatch, Pattern 3 DKIM-alignment failure, etc.), the qualifiers-explained spoke is the focused authoring-decision reference for the single-character RFC 7208 §4.6.2 qualifier-prefix grammar (+ / - / ~ / ?) whose misconfiguration is itself a documented root cause of the SPF-alignment-failure pattern this troubleshooting guide diagnoses. Four operationally-distinct qualifier-misconfiguration root-cause classes the spoke catalogues that the troubleshooting ladder enumerates: (i) +all universal-pass misconfiguration — an operator who typed +all believing it is a "permissive default" has published a record that explicitly authorises EVERY IP on the internet to send mail as their domain; DMARC-fail-via-SPF outcomes effectively disappear because every envelope-sender IP passes the SPF check, masking the underlying spoofability of the domain at the receiver side — the canonical "DMARC says PASS but my domain is being spoofed" symptom this troubleshooting guide must resolve to a +all root cause; (ii) ?all neutral-terminator ambiguity — an operator who typed ?all has published a record semantically equivalent to publishing no SPF record at all per RFC 7208 §2.6.2; the troubleshooting guide must distinguish "no SPF record published" from "?all record published" — the receiver-side outcome is identical but the RUA-evidence stream shows different auth_results/spf records; (iii) ~all soft-fail-only deployment — an operator who typed ~all has published an advisory- only record; the receiver SHOULD accept the message and flag it in the Authentication-Results header but is not required to reject; this troubleshooting guide's Pattern 1 SPF-alignment-failure diagnostic branch must enumerate the ~all-vs-deliverability-cost decision the operator faces when moving from ~all to -all; (iv) missing tail qualifier (no all mechanism) — an operator who omitted the trailing all-mechanism qualifier has published a record that explicitly defaults to ?all per RFC 7208 §4.7, the equivalent of (ii) above but produced by omission rather than commission. Read the qualifiers-explained spoke when the troubleshooting ladder's Pattern 1 / Pattern 2 SPF-component- failure root-cause branch surfaces an anomalous DMARC-fail outcome that does not match the documented SPF-mechanism misconfiguration patterns — the spoke is the canonical authoring-decision reference for resolving the SPF-alignment-failure root cause to the per-record qualifier-prefix decision the operator made (or omitted) when authoring the domain's apex SPF record.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). Canonicalization modes, body hash, selector management, key rotation.
• DKIM best practices — the 15-PER-SELECTOR-DKIM-AUTHORING-RULES- AS-PATTERN-3-ROOT-CAUSE-PREVENTION-DISCIPLINE companion to this DMARC troubleshooting guide. Where THIS page is the symptom-driven diagnostic reference for DMARC=fail outcomes (RUA decoding, the 7 canonical DMARC failure patterns, the Pattern 3 DKIM-alignment-failure diagnostic ladder), the DKIM-best-practices spoke documents the 15 UPSTREAM per-selector DKIM-authoring rules whose per-rule publisher- side compliance is the LOAD-BEARING PRE- FAILURE PREVENTION DISCIPLINE every Pattern 3 diagnostic-ladder root-cause this page documents traces back to. The 15-PER- SELECTOR-DKIM-AUTHORING-RULES-AS-PATTERN-3- ROOT-CAUSE-PREVENTION-DISCIPLINE cross- reference establishes FOUR structurally- distinct per-best-practice-rule-to-Pattern-3- diagnostic-ladder-root-cause mapping dimensions: (i) 2048-bit RSA minimum + dual k=rsa / k=ed25519 publication per RFC 8301 §3 + RFC 8463 as upstream pre-failure prevention discipline for the canonical Pattern 3 root cause "RSA key-size rejection at modern Microsoft / Google receivers" — selectors publishing pre-2018 1024-bit RSA keys produce Pattern 3 (DKIM-alignment failure) symptoms at modern receivers that have tightened minimum-accepted RSA key-length to 2048 bits, surfacing as dkim=fail (insufficient key strength) in the receiver-side Authentication-Results header; the best-practices spoke documents Rule 1 (2048-bit RSA minimum) and Rule 2 (dual- publish k=rsa + k=ed25519) as the canonical upstream pre-failure prevention discipline whose pre-emptive compliance forecloses this Pattern 3 root cause; (ii) c=relaxed/relaxed canonicalization per RFC 6376 §3.4.4 + §3.4.5 as upstream pre-failure prevention discipline for the canonical Pattern 3 root cause "body-hash mismatch from forwarder-injected footer / list-server whitespace rewrite / MIME re-encoding" — selectors publishing c=simple/simple canonicalization produce Pattern 3 body-hash-mismatch failures at every mailing-list / auto-forwarder / in-transit relay that performs benign whitespace normalisation, footer injection, or MIME-Content-Transfer-Encoding re-encoding; the best-practices spoke documents Rule 5 (c=relaxed/relaxed) as the canonical upstream pre-failure prevention discipline whose pre-emptive compliance tolerates the canonical forwarder-injected whitespace edits the Pattern 3 body-hash- mismatch diagnostic ladder traces every forwarder-class root cause to; (iii) STRICT prohibition of stale t=y testing-flag past the 24-72h burn-in window as upstream pre-failure prevention discipline for the canonical Pattern 3 root cause "DMARC-via-DKIM silently disabled" defect class — selectors with the t=y testing flag still published after the burn-in window cause every receiver to disregard the DKIM verdict for DMARC-alignment evaluation purposes per RFC 6376 §3.6.1, producing Pattern 3 symptoms where dkim=pass verdicts in Authentication-Results are SILENTLY ignored by DMARC evaluation — the most DECEPTIVE Pattern 3 root cause class because the receiver-side DKIM verification SUCCEEDS while DMARC evaluation FAILS; the best- practices spoke documents Rule 9 (t=y burn-in cap then REMOVE) as the canonical upstream pre-failure prevention discipline whose violation produces this DECEPTIVELY-SILENT Pattern 3 class; (iv) STRICT prohibition of the l= body-length tag as upstream pre-failure prevention discipline for the canonical Pattern 3 root cause "replay-attack body-content manipulation" defect class — selectors publishing a non-zero l= body-length tag expose the operator to the replay-attack class where attackers append unsigned body content past the signed-body cutoff while preserving the original dkim=pass verdict; the best-practices spoke documents Rule 8 (STRICT l= prohibition) as the canonical upstream pre-failure prevention discipline whose violation produces the replay-attack class of Pattern 3 symptoms (genuinely-signed but body-content- manipulated messages bypassing the receiver- side cryptographic verification). Read THIS DMARC-troubleshooting guide WITH the DKIM- best-practices spoke when the Pattern 3 diagnostic ladder narrows down to a specific DKIM-leg root cause: the troubleshooting page documents the symptom-driven REACTIVE diagnostic ladder, the best-practices spoke documents the 15 PER-SELECTOR PUBLISHING RULES whose pre-emptive compliance forecloses every Pattern 3 root cause this page enumerates.
• DKIM replay attacks (RFC 6376 §8.6) — the DKIM-REPLAY-ATTACK-DIAGNOSTIC- LADDER companion to this symptom-driven DMARC troubleshooting guide. Where THIS page documents the 7 canonical DMARC- fail diagnostic patterns the operator's RUA stream surfaces (and their respective root-cause attribution ladders), the replay-attacks spoke documents an ORTHOGONAL diagnostic class — the RFC 6376 §8.6 DKIM-REPLAY-ATTACK pattern whose RUA signal is DMARC=PASS (not fail) but from a source-IP the publisher does NOT recognize as legitimate egress infrastructure — at FOUR DMARC-troubleshooting-vs-replay- attack diagnostic dimensions: (i) DMARC=pass-from-unknown-IP diagnostic entry point — the operator surfaces the symptom as an anomalous RUA aggregate-report row reading disposition=none + dkim=pass + spf=fail (or omitted) + source_ip not on the publisher's known-egress IP-pool inventory the spoke documents attributing to the replay-attack root-cause class rather than to KPI 5 (distinct sending sources) baseline drift; (ii) per-Message-ID replay-count correlation against the publisher's known-egress audit log — the replay-attacks spoke documents the operator-side per-Message-ID correlation discipline for detecting the captured-and-re- injected variant by matching the RUA per-message Message-ID against the publisher's own outbound mail-flow audit log; (iii) per-key- lifetime rotation-cadence root-cause attribution — the spoke documents the per-key-lifetime replay-window attribution discipline (M365 Rotate-DkimSigningConfig per-quarter, Workspace operator- managed manual rotation) the operator applies to determine which per-key signing-identity the attacker's captured variant exploits; (iv) narrow-signing-scope and RFC 6376 x=-tag remediation ladder — the spoke documents the per-signing-scope narrowing (signed List-Unsubscribe URIs, signed Content-Type, signed Subject:) and x=-tag signature- expiration remediation ladder the operator applies as the per-incident per-key replay-attack closure procedure. Pair this DMARC troubleshooting guide (the symptom- driven DMARC=fail diagnostic ladder) with the replay-attacks spoke (the orthogonal DMARC=pass-from-unknown-IP diagnostic pattern attributable to the replay-attack vector) for the complete picture of DMARC-pass-row verification when the source-IP anomalous-attribution diagnostic applies.
• DKIM troubleshooting — the symptom-driven DKIM-failure diagnostic companion — the DKIM red-path counterpart to this DMARC troubleshooting guide. Where this page is the symptom-driven diagnostic reference for DMARC=fail outcomes (RUA decoding, alignment-failure root-cause analysis, the 7 canonical DMARC failure patterns), the DKIM troubleshooting spoke is the symptom-driven diagnostic reference for the underlying DKIM=fail leg that triggers most DMARC alignment failures. Concretely: when this page documents Pattern 3 (DKIM-alignment failure with SPF-alignment also failing), the operator's next investigation step is identifying which of the 12+ canonical DKIM-failure sub-causes is in play (selector NXDOMAIN, selector-name mismatch, public-key truncation past the 255-byte character-string boundary, TXT-vs-CNAME selector record-type mismatch, propagation-window mismatch, body-hash mismatch from forwarder-injected footer / list-server whitespace rewrite / MIME re-encoding, header canonicalization drift, signature algorithm rejection at receiver, wallclock-skew dkim=temperror, RSA key-size rejection at modern Microsoft / Google receivers, ED25519-key-rejection at legacy DKIM verifiers, key-rotation overlap-window misconfiguration). The DKIM troubleshooting spoke organises each sub-cause into the symptom→cause→fix diagnostic ladder operators need to drive a stuck DMARC=fail incident from "DKIM leg failed" to "DKIM leg passing again" within a single remediation cycle. Pair this page (the DMARC-layer diagnostic cluster) with the DKIM troubleshooting spoke (the DKIM-layer diagnostic cluster) when the DMARC=fail investigation narrows down to a specific DKIM-leg failure mode — the two pages form the symmetric protocol-cluster troubleshooting pair operators iterate between during a remediation campaign.
• DKIM selectors explained — the TROUBLESHOOTING-PATTERN-3-DKIM- SELECTOR-TYPO-AND-ROTATION-WINDOW-ROOT- CAUSE-RESOLUTION companion to this DMARC troubleshooting reference. Where THIS page documents the 7 canonical DMARC-fail diagnostic patterns including Pattern 3 (DKIM selector typo / selector NXDOMAIN / per-rotation-window selector mismatch), the DKIM-selectors-explained spoke is the PER-PROVIDER SELECTOR-NAMESPACE CATALOGUE companion documenting the canonical per-platform selector-name values (Microsoft 365 selector1 / selector2, Google Workspace google._domainkey, SendGrid random-hex per-customer selectors, Mailchimp k1._domainkey / k2._domainkey, AWS SES unique-per-domain hash selectors) the Pattern 3 diagnostic ladder cross- references to identify the root-cause sub-class. Four PATTERN-3-DIAGNOSTIC-VS- SELECTOR-NAMESPACE cross-correlation dimensions the selectors-explained spoke documents: (i) selector-NXDOMAIN root-cause class — when the receiver-emitted RUA row carries auth_results/dkim/result=permerror and the verifier's selector lookup returns NXDOMAIN, the selectors- explained spoke catalogues the canonical per-platform NXDOMAIN root causes (operator typed selector1 as seletor1 in the DKIM-Signature header, operator retired the selector but the publisher still signs with it, operator's publisher-side ESP rotated selectors without notifying the publisher) so the Pattern 3 ladder can route the symptom to the right remediation; (ii) per-rotation-window selector mismatch root-cause class — when the receiver-emitted RUA row shows transient dkim=permerror bursts corresponding to selector- rotation events, the selectors- explained spoke documents the dual- selector overlap-window publication discipline (publish the new selector 24h+ before rotating the signer, leave the old selector in DNS for at least 2x the longest TTL after rotation) the Pattern 3 ladder routes the symptom to as the root-cause-attribution; (iii) per-platform selector-naming- convention misalignment root-cause class — when the operator's publisher-side ESP automation uses a different selector-naming convention than the per-platform canonical value (e.g., the operator hand-publishes dkim._domainkey while Microsoft 365 EOP signs with selector1._domainkey.<tenant>.onmicrosoft.com), the selectors-explained spoke is the canonical reference the Pattern 3 ladder routes the symptom to for the per-platform-correct selector value; (iv) per-platform-managed vs operator-published selector custody root-cause class — the selectors-explained spoke documents which platforms manage the selector TXT publication on the operator's behalf vs which require operator-side manual publication, resolving the Pattern 3 root cause that operators frequently arrive at as "I never published this selector but the receiver is rejecting it for permerror" when actually the platform's .onmicrosoft.com / .gappssmtp.com / .amazonses.com platform-managed selector is the one being verified — the symptom resolves to the operator-vs-platform selector custody confusion the spoke catalogues. Pair this troubleshooting page (the protocol-layer diagnostic flow) with the DKIM-selectors- explained spoke (the per-provider selector-namespace catalogue) when Pattern 3 surfaces a DKIM-selector- related dkim=permerror / dkim=temperror root cause — the selectors-explained spoke is the load-bearing namespace-vocabulary substrate the Pattern 3 diagnostic ladder consults to attribute the per-row symptom to a specific publisher-side selector-publication configuration regression.
• DKIM canonicalization explained (simple vs relaxed) — the byte-level header-and-body normalisation algorithm that is the root cause of the canonical DKIM-troubleshooting symptom: DKIM-Signature header verifies the cryptographic signature but the body-hash bh= tag mismatches because a forwarder injected a footer, an MTA re-encoded the body, or a mailing-list manager (Mailman 3 non-MUNGE / Discourse / Google Groups) rewrote whitespace between signing and verification. The canonicalization page documents the four possible c= values (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) with the full RFC 6376 §3.4.1–§3.4.4 algorithm definitions and a decision matrix mapping each canonicalization choice to the forwarder-survivability tradeoff. Pair this troubleshooting guide (the symptom catalogue) with the canonicalization page (the algorithm-level root cause) when diagnosing the "DKIM signature verifies but body hash mismatches" pattern — almost always solved by setting c=relaxed/relaxed at the signer and avoiding the l= partial-body-length tag (§3.5) which the page documents as the single most-dangerous canonicalization- adjacent knob in the spec (lets attackers APPEND content past the signed prefix while the signature still verifies).
• DKIM failure verdicts explained — the VERDICT-DECODE companion to this symptom-driven troubleshooting page. Where the DKIM-troubleshooting spoke linked above organises DKIM failures by SYMPTOM (selector NXDOMAIN, body-hash mismatch, key-rotation overlap, etc.) and where THIS page maps DMARC-fail outcomes onto the seven canonical DMARC failure patterns, the verdict-decode spoke is the per-RFC-6376-§3.9 / per-RFC-8601- §2.7.1 reference for what each Authentication-Results dkim= value MEANS and which diagnostic step it calls for: dkim=none (no DKIM-Signature header at all — the signer never signed), dkim=neutral (verifier deliberately abstained — RFC 8601 §2.7.1 (3) "considered insufficient"), dkim=pass (the cryptographic baseline — verify still triggers DMARC-fail via alignment-fail), dkim=fail (signature cryptographically invalid — unpack the per-cause table to identify which of the 12+ canonical sub-causes produced it), dkim=policy (RFC 8601 §2.7.1 (6) "DKIM-Signature rejected for local policy reasons" — the body-length-limit / weak-key / wallclock- skew / disallowed-canonicalization local- policy rejections), dkim=temperror (DNS resolver transient failure on the selector lookup — wait one report interval then retry), dkim=permerror (key parsing or signature-header syntax permanently broken — operator-side fix required). Read the verdict-decode catalogue when this troubleshooting guide's Pattern 3 (DKIM-alignment failure) diagnostic branch narrows to a specific auth_results/dkim/result=X XML row in the aggregate-report stream — the verdict-decode catalogue is the canonical operator translation from "raw verdict keyword in the aggregate-report XML" to "diagnostic next step for that verdict class".
• DKIM cryptography basics — the SYMPTOM-DRIVEN-DMARC-TROUBLESHOOTING- LADDER-PATTERN-3-DKIM-ALIGNMENT-FAILURE- DIAGNOSTIC-ROOT-CAUSE-RESOLVES-TO-PUBLISHER- SIDE-CRYPTOGRAPHIC-FOUNDATION-FAILURE-CLASS companion reference. Where THIS page is the symptom-driven debugging guide that maps DMARC-fail aggregate-report rows onto the seven canonical DMARC failure patterns (including Pattern 3 DKIM-alignment-failure and the upstream DKIM-verification-failure sub-class that feeds it), the crypto-basics spoke is the PUBLISHER-SIDE CRYPTOGRAPHIC- FOUNDATION canonical reference documenting the FOUR root-cause classes the Pattern 3 diagnostic branch resolves to when the DKIM verifier surfaces a per-message dkim=fail or dkim=permerror verdict at the receiver: (i) RSA-key-size-discipline failure (RFC 8301 deprecates RSA-1024 and SHA-1 — pre-2018 keypairs that survived the deprecation window produce per- receiver per-policy dkim=policy rejections at strict verifiers and downgrades to dkim=neutral at permissive ones, breaking the alignment evaluation), (ii) hash-algorithm-discipline failure (the per-signer a=rsa-sha1 publication that RFC 8301 §3 deprecates — every modern verifier rejects the signature with a permerror / policy verdict, collapsing the DKIM-alignment- evaluation path the Pattern 3 ladder relies on), (iii) canonicalization- algorithm-choice failure (the per-publisher c=simple/simple vs c=relaxed/relaxed choice whose mismatch with per-forwarder header- and-body modification produces per-message body-hash mismatches that surface as dkim=fail at the receiver — the Pattern 3 "DKIM-fail on forwarder-hop" diagnostic resolves to a canonicalization-choice root-cause that the crypto-basics spoke catalogues at the per-canonicalization-mode survival- probability granularity), (iv) private- key-custody-discipline failure (per- publisher rotation-window overlap-vs- cutover discipline whose collapse produces transient dkim=permerror across a rolling window during the rotation — the Pattern 3 "intermittent DKIM-fail on selector A but not selector B" diagnostic resolves to a custody-and-rotation-discipline root- cause the crypto-basics spoke catalogues as a per-rotation-event operator-hygiene invariant). Read the crypto-basics spoke when THIS troubleshooting guide's Pattern 3 diagnostic ladder bottoms out on a per-message dkim=fail / dkim=permerror / dkim=policy verdict whose receiver-side aggregate-report row cannot be further decomposed without the publisher-side cryptographic- foundation reference the crypto-basics page documents in RFC-precise terms.
• ARC (Authenticated Received Chain) explained — RFC 8617: the standard that preserves original DMARC verdicts across forwarding hops. The remediation for Pattern 6.
• BIMI explained — Brand Indicators for Message Identification. BIMI deployment also requires resolving DMARC failures.
• BIMI Verified Mark Certificates (VMC and CMC) — the BIMI-DISPLAY-FAILURE-ROOT-CAUSE- TRACES-THROUGH-DMARC-AUTHENTICATION- FAILURE-TROUBLESHOOTING-LADDER-TO-VMC- VALIDITY companion reference. Where THIS page is the symptom-driven debugging reference for DMARC-fail outcomes (the Pattern 1 SPF-alignment- failure / Pattern 2 DKIM-alignment- failure / Pattern 3 SPF-or-DKIM- verification-failure / Pattern 4 organisational-domain-mismatch / Pattern 5 ARC-chain-break / Pattern 6 forwarder-rewrite decision ladder), the BIMI-certificates spoke documents the VMC/CMC X.509 trademark-bound certificate whose MUA-side display failure modes STRUCTURALLY EXTEND the DMARC-failure symptom catalogue this page documents into the brand-display layer where DMARC-pass is necessary but not sufficient, across four VMC- layer diagnostic root-cause dimensions: (i) BIMI-display-failure symptom at the MUA (Gmail / Apple Mail / Yahoo / Fastmail / Outlook with BIMI support) almost always traces FIRST through the DMARC-fail troubleshooting ladder THIS page documents — Pattern 1 / Pattern 2 / Pattern 3 must each be RULED OUT before VMC-validity / SVG-hash- binding / MVA-trademark-evidence- gate failure modes become candidate root-causes, (ii) post-DMARC-pass BIMI-display failures branch into VMC-validity diagnostics (VMC expiry, CA revocation, intermediate- cert chain failure, MVA trademark- evidence withdrawal) that operators triage via openssl / curl / BIMI Group validator tooling rather than the DMARC-RUA ingestion pipeline THIS page documents — the diagnostic toolchain bifurcates at the post- DMARC-pass branch point, (iii) the VMC SVG-hash-binding cross-domain check (the cert embeds a hash of the SVG bytes the BIMI l= tag points to, validated at MUA render time) produces a per-cohort receiver-side display-failure signature DISTINCT from DMARC-fail — operators MUST cross-reference their BIMI l= URL's SVG-byte-hash against the VMC's embedded hash via the BIMI Group validator before reaching for the DMARC-fail diagnostic ladder, and (iv) the per-receiver BIMI evaluator applies its own DMARC-pass-rate-per- source_ip threshold (typically ≥99% across rolling 90 days) that is observable in the DMARC-RUA stream but is a DOWNSTREAM consumer of the Pattern 1-6 troubleshooting verdicts THIS page produces — a DMARC-pass-rate sub-threshold receiver cohort produces BIMI-non-display without producing any of the Pattern 1-6 actionable signals. Read the BIMI-certificates spoke alongside this DMARC-troubleshooting reference when triaging a BIMI- display-failure symptom — the Pattern 1-6 ladder THIS page documents is the FIRST diagnostic layer to clear, and only after every Pattern is RULED OUT does the diagnostic workflow transition into the VMC-validity / SVG-hash-binding / MVA-trademark-evidence-gate root- cause classes the BIMI-certificates spoke documents.
• MTA-STS explained — SMTP transport security.
• MTA-STS policy file syntax — the MTA-STS-MISAUTHORING-DIAGNOSTIC byte-level companion to this DMARC troubleshooting guide. Where THIS page is the symptom-driven debugging reference for DMARC-fail outcomes as a WHOLE — including the cross-protocol TRANSPORT-SECURITY-FAILURE class (MTA-STS / TLS-RPT failures that surface as inbound-delivery damage invisible to DMARC aggregate reports because aggregate reports only cover outbound authentication) — the mta-sts-policy-syntax spoke is the focused per-policy-file-grammar diagnostic reference for ONE of the operator-encountered MTA-STS misauthoring patterns the troubleshooting playbook diagnoses. The spoke catalogues the canonical byte-level POLICY-FILE ERRORS that cause enforcing-receiver MTA-STS policy-validation or policy-discovery failures — missing version: STSv1 tag (policy-validation-failure), missing terminal CRLF on the last mx: directive (policy- parsing-failure), incorrect max_age: value outside the RFC 8461 §3.2 valid range (policy- validation-failure), typo'd mx: pattern that fails to match the receiver-resolved MX hostnames (policy-validation-failure), non-HTTPS hosting of the policy file at the /.well-known/mta-sts.txt path (policy-discovery-failure), missing _mta-sts.<domain> TXT record advertising the policy id (policy-discovery-failure), and stale cached policy after a transition from mode: testing to mode: enforce (operator forgot to bump the policy id in the _mta-sts.<domain> TXT record). Read the mta-sts-policy-syntax spoke when triaging a TLS-RPT-reported MTA-STS-failure-mode whose root cause is a byte-level error in the published policy file rather than an MX- misconfiguration or certificate-chain failure — the byte-level grammar diagnostic in the spoke is the canonical next step in the diagnostic decision tree AFTER the troubleshooting playbook has narrowed root-cause to MTA-STS-policy-file-authoring rather than DMARC-authentication, alignment, or transport-encryption-negotiation per se.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460).
• TLS-RPT record syntax (RFC 8460 §3) — the DMARC-TROUBLESHOOTING-DIAGNOSTIC- LADDER-PARALLEL-WITH-TLS-RPT-RECORD- PUBLICATION-FAILURE-LADDER companion to this DMARC troubleshooting reference. Where THIS page documents the DMARC diagnostic ladder (no aggregate reports arriving → DMARC TXT RR unpublished or rua= tag absent; receiver-side dmarc=permerror → DMARC TXT-RR sentinel typo or invalid tag-value byte-grammar; receiver-side dmarc=temperror → authoritative-nameserver transient outage; per-domain authentication- verdict drift → SPF/DKIM alignment misconfiguration), the TLS-RPT record- syntax spoke is the RFC 8460 §3 TLS- RPT TXT-RR byte-grammar publication- discipline companion whose publisher- side failure-mode ladder mirrors the DMARC publisher-side failure-mode ladder THIS troubleshooting reference documents. The DMARC-TROUBLESHOOTING- DIAGNOSTIC-LADDER-PARALLEL-WITH-TLS-RPT- RECORD-PUBLICATION-FAILURE-LADDER cross-reference establishes FOUR structurally-distinct publisher-side DNS-RR failure-mode dimensions: (i) no-RR-published failure-mode parallel — DMARC silently produces no aggregate reports when _dmarc.<policy-domain> TXT RR is unpublished or rua= tag absent (the publisher's intent to receive reports collapses entirely with no error surfaced); TLS-RPT silently produces no transport-failure reports when _smtp._tls.<policy- domain> TXT RR is unpublished or rua= tag absent (the same silent-failure mode the DMARC ladder documents); both protocols share the publisher-side-silent-no-RR- publication failure-mode and require the operator's proactive DNS-publication audit as the diagnostic entry-point; (ii) sentinel-token-typo failure-mode parallel — DMARC receiver-side dmarc=permerror verdict surfaces when the v=DMARC1 sentinel is misspelled (v=DMRAC1, v=DMARC2, or missing leading v=); TLS-RPT publication-collapse surfaces when the v=TLSRPTv1 sentinel is misspelled (v=TLSRPT1, v=TLSRPTv2, or missing leading v=) per RFC 8460 §3.1 receiver-side parser-dispatch contract; both protocols' sentinel- token-typo failure-mode is publisher- side-fixable AND surfaces identically at the receiver-side parser-dispatch boundary; (iii) tag-value-byte- grammar-typo failure-mode parallel — DMARC rua= tag with invalid URI scheme (rua=mailtoo:reports@example.com instead of rua=mailto:...) produces receiver-side report-target- unreachable silent failure; TLS-RPT rua= tag with invalid URI scheme (the same mailtoo: typo, or https: missing the host) produces the SAME receiver-side report-target-unreachable silent failure per RFC 8460 §3.2 normative contract; both protocols share the tag-value-byte-grammar-typo failure- mode where the publisher's INTENDED reporting contract collapses silently and the operator must proactively validate via a tag-list-parser audit-tool; (iv) DNSSEC-pairing- omission failure-mode parallel — DMARC publication without DNSSEC exposes the operator to the _dmarc.<policy-domain> TXT-RR cache-poisoning attack where an attacker substitutes their own rua=mailto:attacker@evil receiver and harvests the publisher's aggregate-report traffic; TLS-RPT publication without DNSSEC exposes the operator to the SAME _smtp._tls.<policy- domain> TXT-RR cache-poisoning attack where an attacker substitutes their own rua=mailto:attacker receiver and harvests the publisher's TLS-failure-report traffic (per RFC 8460 §6 normative security consideration); both protocols share the DNSSEC-pairing-omission failure- mode where the publisher's INTENDED report-target attribution can be silently hijacked at the DNS-resolver layer below the protocol-evaluation layer. Pair this page (the DMARC diagnostic-ladder reference) with the TLS-RPT record-syntax spoke (the RFC 8460 §3 TLS-RPT TXT-RR byte-grammar publication-discipline reference) when an operator triages "no reports arriving" or "reports going to wrong mailbox" symptoms and needs to apply the same no-RR-publication / sentinel- token-typo / tag-value-byte-grammar- typo / DNSSEC-pairing-omission diagnostic ladder across BOTH the DMARC TXT-RR and TLS-RPT TXT-RR publication layers — the diagnostic ladder cross-applies one-for-one because both protocols share the same publisher- side-publishes-tag-list-TXT-RR / receiver-side-discovers-via-underscore- prefixed-sub-label DNS-publication topology.
• TLS-RPT JSON report format — the TLS-RPT-REPORT-FORMAT-COMPLEMENTS- DMARC-TROUBLESHOOTING-AT-TRANSPORT-LAYER companion to this DMARC-troubleshooting decision-tree. Where THIS page documents the seven canonical DMARC failure patterns traced back to SPF / DKIM / alignment root causes (the application-layer protocol failures THIS spoke catalogues), the TLS-RPT report-format spoke documents the RFC 8460 §4 JSON schema operators consult when the troubleshooting workflow encounters a CLASS of failure THIS page's decision tree CANNOT explain: when mail FAILED at the TLS-handshake step BEFORE the receiving MTA could ever evaluate DMARC (a transport-layer failure rather than an authentication failure). The TLS-RPT-REPORT-FORMAT-COMPLEMENTS-DMARC- TROUBLESHOOTING-AT-TRANSPORT-LAYER cross-reference establishes five specific troubleshooting-to-TLS-RPT-field mappings the diagnostic workflow consumes: (i) total-successful-session-count vs total-failure-session-count tells operators the transport-layer success rate at the receiver BEFORE any DMARC evaluation could even happen — when DMARC reports show "no record" from a high-volume receiver, the TLS-RPT summary object confirms whether the connection ever completed; (ii) failed-session-count per failure-details[] entry tells operators the per-failure-mode volume — when the troubleshooting decision tree cannot locate the alignment failure, the per-mode failure-session-count tells operators WHICH transport-layer mode dominates and whether to escalate from DMARC-tier troubleshooting to MTA-STS / DANE / certificate / DNS-rotation investigation; (iii) the result-type enum (12 RFC 8460 §4.3 values) maps each failure to a specific transport-layer root cause distinct from DMARC failures — starttls-not-supported, certificate-host-mismatch, certificate-not-trusted, certificate-expired, validation-failure, sts-policy-fetch-error, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required, and sts-policy-invalid — each route the troubleshooting workflow to a different remediation than the DMARC SPF / DKIM / alignment branches on THIS page; (iv) the sending-mta-ip + receiving-mx-hostname fields narrow the diagnosis to a specific sender-side outbound MTA and a specific receiver-side MX target — a precision the DMARC reports' source_ip attribution alone cannot match because DMARC source_ip is the source from the receiver's perspective at the APPLICATION-layer post-MTA-receipt; (v) the report-id + date-range fields scope the diagnostic window — operators triaging "DMARC report shows compliance drop on day X" can correlate against the TLS-RPT report covering the SAME date-range to see whether the underlying cause was transport-layer rather than authentication-layer. Read THIS page when the failure is at the SPF / DKIM / alignment layer; read the TLS-RPT report-format spoke when the failure is at the TLS handshake / cert validation / MTA-STS policy fetch / DANE TLSA layer — one protocol step before DMARC even starts evaluating.
• DANE for SMTP (RFC 7672) explained - the DANE-TLSA-VALIDATION-FAILURE-AS- TRANSPORT-LAYER-EVIDENCE-STREAM-ROOT- CAUSE-CLASS companion to this DMARC troubleshooting decision-tree. Where the sibling TLS-RPT-report-format entry ABOVE documents the RFC 8460 §4 JSON schema operators consult when correlating "missing DMARC report from receiver X" with TLS- handshake failures one protocol layer below DMARC, the dedicated DANE deep-dive documents the DANE-specific TLSA-validation failure- mode catalogue that produces the most operationally-load-bearing DANE-specific DMARC-troubleshooting symptom class: DANE-validating receivers (typically the IronPort cohort, the on-prem M365 hybrid cohort with DANE enabled since 2022, the German DE-Mail cohort, and various DNSSEC-anchored receiver populations) permanent-5xx-reject messages on TLSA- validation failure with NO non-enforcing testing-mode fallback - producing a structurally-distinct DMARC-troubleshooting evidence channel at FOUR DANE-failure-mode dimensions: (i) TLSA-record-payload- misauthored (wrong cert-hash, wrong usage field, wrong selector-value) producing PERMANENT 5xx-rejection at every DANE- validating receiver from the moment the TLSA record's TTL expires through the recursive-resolver fleet - this is the single highest-stakes operator-side TLSA- misauthoring failure mode and surfaces in DMARC troubleshooting as "RUA aggregate report from receiver X went from N rows per day to ZERO with no apparent SPF/DKIM/ alignment change"; the DANE deep- dive documents the per-TLSA-field validation failure-mode catalogue; (ii) DNSSEC- chain-validation-failure cascading to TLSA- validation-failure (parent-zone DS-record rolled, DNSKEY-record TTL expired without republication, RRSIG record covering the TLSA-record-owner-name expired) producing TRANSIENT 4xx-deferral rather than permanent 5xx-rejection on DNSSEC-validating receivers - this is the structurally-distinct DANE failure mode from TLSA-payload misauthoring and surfaces in DMARC troubleshooting as "RUA aggregate stream from receiver X intermittent on a 4-12 hour cadence correlating with DNSSEC-chain re-validation windows"; the DANE deep-dive documents the DNSSEC-chain-vs-TLSA-validation failure decoupling discipline; (iii) cert-rotation-without-RFC-7671-§8- dual-TLSA-overlap producing TLSA-mismatch- at-DANE-validating-receivers (the publisher rotates the SMTP cert without publishing the new-cert-hash TLSA record N TTL-windows in advance) - this surfaces in DMARC troubleshooting as "RUA aggregate stream from DANE-validating receiver cohort collapsed coincident with cert-rotation cutover"; the DANE deep-dive documents the cert-rotation TLSA-overlap- publication choreography and its DMARC- troubleshooting signature; and (iv) DANE-deployment-prerequisite zone- DNSSEC-unsigning (the publisher's registrar revoked or expired DNSSEC at the parent zone-cut, the publisher's zone-DNSKEY-record was inadvertently removed, or the publisher's zone DNSSEC- signing automation broke) producing UNVERIFIABLE-DNSSEC-CHAIN-IGNORE-TLSA behaviour at receiver fleet - this surfaces in DMARC troubleshooting as "RUA aggregate stream from DANE-validating receivers showing partial mail-delivery on a receiver-by-receiver cadence as different receivers' DNSSEC-validating-resolver cohorts experience the DNSSEC-chain-failure at different cache-aging cycles"; the DANE deep-dive documents the DNSSEC- zone-state-as-DANE-prerequisite verification checklist. Read THIS page when the DMARC failure is at the SPF / DKIM / alignment layer; read the sibling TLS-RPT-report- format entry ABOVE when the failure is at the generic TLS-handshake / cert-validation / MTA-STS-policy-fetch layer; read the dedicated DANE deep-dive when the failure is specifically at the DANE TLSA-validation layer and the symptom catalogue points to one of the four DANE-specific failure modes above - the DANE spoke is the authoritative per-failure-mode root-cause diagnostic reference whose four DANE- specific evidence-stream signatures this DMARC troubleshooting playbook is the diagnostic-decision-tree consumer for.
• CAA records explained — Certification Authority Authorization (RFC 8659).
• DMARC for Google Workspace — Workspace-specific DKIM activation and Postmaster Tools.
• DKIM for Google Workspace (Gmail) — the WORKSPACE-TENANT-PER-DOMAIN-DKIM- PUBLICATION-AS-LOAD-BEARING-ROOT-CAUSE- ATTRIBUTION-AXIS companion to this DMARC-troubleshooting diagnostic-ladder reference. Where THIS page documents the symptom-driven DMARC-failure triage workflow (record-not-found, alignment-mismatch, SPF-permerror, DKIM-fail, forwarder body modifications, ARC-disabled inbound paths) and the per-row attribution decision tree the operator applies against the aggregate- XML evidence stream, the Workspace- DKIM spoke documents the per-Workspace- tenant DKIM-publication discipline whose byte-level publication status is the LOAD-BEARING root-cause attribution axis for Workspace-egress DMARC-fail rows. Three concrete troubleshooting- vs-Workspace-DKIM coupling points: (i) gappssmtp.com signing-identity DKIM-alignment-failure failure mode — the most common Workspace-egress DMARC-fail root-cause is the per-tenant DKIM signature being applied with the Workspace-internal <tenant>.gappssmtp.com identity (DKIM-pass but DKIM-alignment- fail) BEFORE the per-tenant operator has completed the Admin Console "Generate new record" workflow; the Workspace-DKIM spoke documents the per-tenant activation workflow that closes this gotcha, the LOAD-BEARING remediation step for the per-row symptom "dkim=pass + dkim-alignment- fail + From: header on org-domain"; (ii) per-tenant google._domainkey TXT- record absent / overwritten at the per-domain DNS zone — the per-tenant operator-controlled publication of the google._domainkey 2048-bit TXT record at the per-domain DNS zone is the LOAD-BEARING upstream Workspace-DKIM publication primitive; a per-row symptom of "dkim=none on every Workspace-egress message" most often roots to the per-domain DNS zone NOT publishing the google._domainkey TXT record (or publishing it with a rotated-but-not-replaced public-key body); the Workspace-DKIM spoke documents the per-tenant publication- verification workflow (the Admin Console "AUTHENTICATING EMAIL" status indicator + the dig +short TXT google._domainkey.<org-domain> verification) the troubleshooting operator runs to confirm the per-domain DNS-publication-axis is intact; (iii) per-tenant manual rotation cadence not exercised — when the per-tenant Workspace operator has not exercised the manual rotation cadence the per-tenant google._domainkey TXT record stays bound to the original key indefinitely; if the per-tenant operator has rotated the Admin Console key WITHOUT updating the per-domain DNS-zone TXT record, the per-row symptom is sustained dkim=permerror on every Workspace-egress message; the Workspace-DKIM spoke documents the per-tenant manual rotation discipline the troubleshooting operator applies as the root-cause attribution axis. Read the Workspace-DKIM spoke as the LOAD-BEARING root-cause attribution axis reference whenever this DMARC- troubleshooting workflow scopes a per- row Workspace-egress DMARC-fail triage.
• DKIM for Microsoft 365 — the M365-TENANT-PER-DOMAIN-DKIM- PUBLICATION-AS-LOAD-BEARING-ROOT-CAUSE- ATTRIBUTION-AXIS companion to this DMARC- troubleshooting workflow for operators whose aggregate-XML evidence stream surfaces M365-egress dmarc=fail rows. Where THIS page documents the symptom- driven DMARC-troubleshooting diagnostic ladder (Step 1 receiver-side raw RUA XML ingest → Step 2 per-source-IP grouping → Step 3 per-receiver disposition / SPF / DKIM result trichotomy → Step 4 per-row domain-alignment vs identifier-alignment attribution → Step 5 per-organization- boundary policy disposition reconstruction → Step 6 escalation-or-fix decision), the M365-DKIM spoke supplies the per-M365- tenant Defender DKIM-publication- discipline catalogue the per-row root- cause attribution at Step 4 materially depends on for M365-egress DMARC-fail rows. Three concrete troubleshooting-vs- M365-DKIM coupling points: (i) onmicrosoft.com signing-identity gotcha as the MOST-COMMON M365-egress DMARC- fail root-cause — when an M365 tenant has not yet flipped the Defender "Enable DKIM" toggle, M365 egress signs with the per-tenant <tenant>.onmicrosoft.com identity instead of the operator's domain; the per-row DKIM verdict in the aggregate-XML evidence stream is dkim=pass but DKIM- alignment against the RFC 5322 From: domain fails — producing a sustained per-receiver DMARC-fail rate the troubleshooting ladder must attribute to the M365-DKIM publication axis rather than to receiver-side handling; (ii) selector1 / selector2 CNAME absent OR overwritten at the per-domain DNS zone as the SECONDARY root-cause — the per-row root-cause attribution must distinguish "Defender toggle on, CNAMEs absent" (publication regression at the DNS zone) from "Defender toggle off, CNAMEs present" (Defender-activation regression) — both produce identical per-row aggregate-XML evidence-stream symptoms but require different fixes; (iii) Defender-toggle regression during tenant migration as the TERTIARY root-cause — tenant-to-tenant migrations (M&A divestiture, M365 → M365 GCC, custom-domain transfer) can silently flip the per-tenant Enable-DKIM toggle back to off; the M365-DKIM spoke documents the per-tenant Defender state the troubleshooting workflow needs as the root-cause attribution axis. Read the M365-DKIM spoke as the LOAD-BEARING root-cause attribution axis reference whenever this DMARC-troubleshooting workflow scopes a per-row M365-egress DMARC-fail triage.
• MTA-STS for Microsoft 365 — the M365-TENANT-PER-DOMAIN-MTA-STS- TRANSPORT-LAYER-PUBLICATION-AS-LOAD- BEARING-ROOT-CAUSE-ATTRIBUTION-AXIS companion to this DMARC-troubleshooting workflow for operators whose aggregate- XML evidence stream cross-references TLS-RPT JSON-aggregate ingestion surfaces M365-egress transport-layer delivery-failure symptoms. Where THIS page documents the symptom-driven DMARC-troubleshooting diagnostic ladder (Step 1 receiver-side raw RUA XML ingest → Step 2 per-source-IP grouping → Step 3 per-receiver disposition / SPF / DKIM result trichotomy → Step 4 per- row domain-alignment vs identifier- alignment attribution → Step 5 per- organization-boundary policy disposition reconstruction → Step 6 escalation-or- fix decision), the M365-MTA-STS spoke supplies the per-M365-tenant Exchange Online MTA-STS-publication-discipline catalogue the per-row transport-layer root-cause attribution materially depends on for M365-egress delivery- failure rows. Three concrete troubleshooting-vs-M365-MTA-STS coupling points: (i) premature enforce- mode promotion as the MOST-COMMON M365- egress transport-layer delivery-failure root-cause — when an M365 tenant promotes the per-tenant mta-sts.txt policy file from mode: testing to mode: enforce before TLS- RPT JSON-aggregate ingestion confirms a per-tenant steady-state zero-failure baseline, the per-row aggregate-XML evidence stream shows DMARC-policy- applied but the per-tenant TLS-RPT JSON-aggregate surfaces a per-receiver TLS-handshake-failure spike — the troubleshooting ladder must attribute the per-row delivery-loss to the M365- MTA-STS publication axis rather than to a DMARC-disposition-axis cause; (ii) mx: hostname-glob omission of *.mail.protection.outlook.com as the SECONDARY root-cause — the per-row root-cause attribution must distinguish "policy published but hostname-glob list does not include the Exchange Online canonical MX hostnames" (policy-file-content regression) from "policy file absent at HTTPS-policy- host" (HTTPS-publication regression) — both produce identical per-row TLS- handshake-failure symptoms but require different fixes; (iii) HTTPS- policy-host certificate expiration as the TERTIARY root-cause — the per-tenant mta-sts.<domain> HTTPS-policy-host certificate has a finite renewal cadence (typically 90 days for Let's Encrypt); expiration produces a per-receiver TLS-RPT JSON- aggregate certificate-host- mismatch or certificate- expired verdict that must be attributed to the per-tenant certificate-renewal-axis root-cause rather than to a policy-file-content regression. Read the M365-MTA-STS spoke as the LOAD-BEARING transport-layer root-cause attribution axis reference whenever this DMARC-troubleshooting workflow scopes a per-row M365-egress transport-layer delivery-failure triage cross-referenced against the per-tenant TLS-RPT JSON-aggregate evidence stream.
• MTA-STS for Google Workspace (Gmail) — the WORKSPACE-TENANT-PER-DOMAIN- MTA-STS-TRANSPORT-LAYER-PUBLICATION-AS- LOAD-BEARING-ROOT-CAUSE-ATTRIBUTION-AXIS companion to this DMARC-troubleshooting workflow for operators whose aggregate- XML evidence stream cross-references TLS-RPT JSON-aggregate ingestion surfaces Workspace-egress transport- layer delivery-failure symptoms. Where THIS page documents the symptom-driven DMARC-troubleshooting diagnostic ladder (Step 1 receiver-side raw RUA XML ingest → Step 2 per-source-IP grouping → Step 3 per-receiver disposition / SPF / DKIM result trichotomy → Step 4 per- row domain-alignment vs identifier- alignment attribution → Step 5 per- organization-boundary policy disposition reconstruction → Step 6 escalation-or- fix decision), the Workspace-MTA-STS spoke supplies the per-Workspace-tenant Gmail MTA-STS-publication-discipline catalogue the per-row transport-layer root-cause attribution materially depends on for Workspace-egress delivery-failure rows. Three concrete troubleshooting-vs-Workspace-MTA-STS coupling points: (i) premature enforce-mode promotion as the MOST- COMMON Workspace-egress transport-layer delivery-failure root-cause — when a Workspace tenant promotes the per-tenant mta-sts.txt policy file from mode: testing to mode: enforce before TLS- RPT JSON-aggregate ingestion confirms a per-tenant steady-state zero-failure baseline, the per-row aggregate-XML evidence stream shows DMARC-policy- applied but the per-tenant TLS-RPT JSON-aggregate surfaces a per-receiver TLS-handshake-failure spike — the troubleshooting ladder must attribute the per-row delivery-loss to the Workspace-MTA-STS publication axis rather than to a DMARC-disposition-axis cause; (ii) mx: hostname-glob omission of the five *.ASPMX.L.GOOGLE.COM hostnames as the SECONDARY root-cause — the per-row root-cause attribution must distinguish "policy published but hostname-glob list does not include the Gmail canonical MX hostnames" (policy-file-content regression) from "policy file absent at HTTPS-policy-host" (HTTPS- publication regression) — both produce identical per-row TLS-handshake-failure symptoms but require different fixes; (iii) HTTPS-policy-host certificate expiration as the TERTIARY root-cause — the per-tenant mta-sts.<domain> HTTPS-policy-host certificate has a finite renewal cadence (typically 90 days for Let's Encrypt); expiration produces a per-receiver TLS-RPT JSON- aggregate certificate-host- mismatch or certificate- expired verdict that must be attributed to the per-tenant certificate-renewal-axis root-cause rather than to a policy-file-content regression. Read the Workspace-MTA-STS spoke as the LOAD-BEARING transport- layer root-cause attribution axis reference whenever this DMARC- troubleshooting workflow scopes a per- row Workspace-egress transport-layer delivery-failure triage cross- referenced against the per-tenant TLS-RPT JSON-aggregate evidence stream.
• DMARC for Microsoft 365 — onmicrosoft.com signing failure mode + Set-DkimSigningConfig workflow.
• DMARC for Hybrid Exchange (on-prem + M365) — the hybrid-topology deep dive for Exchange-Online + Exchange-on-premises coexistence. Hybrid Exchange is the highest-incidence cause of two difficult-to-diagnose failure patterns documented on this page: (a) the dual-signer DKIM problem (both Exchange Online AND the on-prem Edge Transport sign with different keys, producing inconsistent d= domains in the Authentication-Results across the mail flow), and (b) Send Connector relay loops surfacing as NDR 5.4.6 (the Default Frontend Connector strips DKIM on inbound delivery before re-signing). Includes ARC sealing across the on-prem- to-cloud relay via Set-ArcConfig and the Centralized Mail Transport (CMT) migration path that eliminates the dual-signer problem entirely.
• DMARC for cPanel & Shared Hosting — shared-IP reputation, provider-bounce alignment failure, manual DKIM rotation.
• DMARC for shared hosting — the SHARED-HOSTING-TOPOLOGY-ROOT-CAUSE- CATALOGUE companion to this DMARC-fail symptom-driven debugging playbook for the operator population whose RUA-stream DMARC-fail rows trace to a Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP shared-hosting tenancy. Where THIS page catalogues the 7 canonical symptom-to-root-cause failure patterns across the SPF / DKIM / alignment / DNS / forwarding / mailbox-provider axes, the shared-hosting deployment spoke documents the FOUR SHARED-HOSTING-SPECIFIC ROOT-CAUSE FAMILIES whose per-tenant RUA-stream signatures THIS troubleshooting playbook's symptom-driven diagnostic ladder must trace to the shared-hosting topology as the load-bearing root cause: (i) shared- outbound-relay envelope-MAIL-FROM rewriting as policy_evaluated.spf=fail root cause — the per-tenant shared-hosting control-panel's outbound relay rewrites the envelope MAIL-FROM to bounces+<tenant-id>@<shared- relay-hostname> at relay-handoff time, structurally breaking SPF alignment with the tenant's protected From:-domain despite the per-tenant include:<hosting-vendor-pool> SPF record authorising the egress IP-pool; the shared-hosting spoke catalogues the per-control-panel (Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP) envelope-rewriting defaults the operator must enumerate as Pattern 1's shared- hosting-specific Pattern-1 sub-class root cause; (ii) co-tenant SPF / DKIM noise as RUA-attribution-dilution root cause for "DMARC-fail rows I cannot explain" — the per-tenant operator's RUA stream contains source_ip rows from the shared-relay IP-pool emitting mail for DOZENS of unrelated co-tenant domains, AND auth_results dkim-pass rows for selector + d= combinations the operator never configured; the shared-hosting spoke catalogues the per-tenant attribution-dilution diagnostic discipline this troubleshooting playbook's "diagnostic toolkit" section must layer on top of the canonical RUA-row analysis for shared-hosting tenants — the per- header_from filtering AND the per-selector-noise-exclusion workflow whose shared-hosting-specific signature the per-tenant operator's diagnostic ladder must enumerate distinctly from the dedicated-tenant baseline; (iii) shared-IP-pool reputation cross-contamination as Pattern 7's mailbox-provider-rejection root cause — the shared-hosting topology structurally pools the per-tenant outbound mail through the same shared-IP pool as 10s-to-100s of co-tenants, whose per-co-tenant spam-event or per-co-tenant compromised-mailbox event degrades the per-CIDR reputation at every major receiver simultaneously, surfacing in the per-tenant operator's RUA-stream as a per-receiver delivery-degradation pattern the canonical Pattern 7 mailbox-provider- specific diagnostic ladder traces to the shared-IP-pool root cause distinctly from the per-tenant DKIM / SPF / alignment per-tenant publisher-side root-cause families; (iv) provider-induced RUA-arrival cadence anomaly as Pattern 7's "RUA stream is silent" root cause for shared-hosting tenants — the shared-hosting provider's managed-mailbox infrastructure can structurally block legitimate inbound RUA mail from external receivers, producing multi-day gaps in the per-tenant aggregator's arriving aggregate reports whose canonical Pattern 7-adjacent diagnostic signature the shared- hosting spoke documents as the per-tenant RUA-mailbox-on-shared-hosting-infrastructure provider-induced single-point-of-failure whose multi-mailbox-redundancy publisher- side rua=-tag addressing discipline (shared-hosting-provider mailbox AND an external dedicated-provider fallback mailbox) the per-tenant operator must layer onto the canonical rua= single-mailbox publication discipline. Read THIS troubleshooting playbook for the protocol-neutral 7-pattern symptom-driven ladder; read the shared-hosting deployment spoke when an RUA-stream symptom traces to the per-tenant shared-hosting topology as the load-bearing root cause and the per-control-panel (Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP) per-tenant operator-empowerment-ceiling constraint is the operationally-binding attribute the diagnostic ladder's remediation step must accommodate.
• DMARC for transactional email — per-ESP misconfiguration diagnostic for SendGrid / Mailgun / SES / Postmark / SparkPost — the ESP-MISCONFIGURATION-DIAGNOSTIC companion to this DMARC troubleshooting playbook for the operator population whose DMARC-fail rows decode to ESP-side authoring errors. Where this page catalogues operator-encountered failure patterns at the DNS-record-authoring layer (DKIM selector typos, SPF lookup overruns, ARC-seal absence, Authentication- Results parsing edge cases), the transactional-email spoke catalogues the per-ESP-specific misconfiguration patterns that dominate the DMARC-fail roster for any operator delegating outbound mail to a third-party ESP: SendGrid CNAME-delegated DKIM key unrotated past the 12-month cryptographic-hygiene threshold, Mailgun region mismatch between EU and US sending endpoints producing inconsistent Return-Path subdomains, SES sandbox-vs- production sending-identity verification gap producing intermittent spf=softfail rows, Postmark transactional-stream-vs- broadcast-stream Return-Path divergence, SparkPost dedicated-IP-pool warmup-phase IP not yet enumerated in the operator's SPF record, multi-ESP DKIM selector collision where two ESPs both deploy s=mail._domainkey, ESP sub-account default SPF/DKIM not yet bound to the operator's custom sending identity, and the Return-Path-vs-From- header organizational-domain mismatch that drives aspf=fail rows across every ESP tier. Pair this troubleshooting playbook (the generic DMARC-fail decode) with the transactional-email spoke (the per-ESP misconfiguration catalogue) for the complete operator-debugging workflow on any domain whose outbound mail is wholly or partly delegated to a transactional-email ESP.
• DMARC forensic reports (RUF) — the TROUBLESHOOTING-PER-MESSAGE- FORENSIC-EVIDENCE-AS-GRANULAR-COMPLEMENT- TO-RUA-AGGREGATE-COUNTS companion reference. Where THIS page documents the GENERIC DMARC-FAIL DECODE WORKFLOW (over-budget SPF lookup-limit, broken DKIM signature verification, header- vs-envelope alignment failure, mailing- list footer modification, third-party- ESP misconfiguration), the forensic- reports spoke is the PER-MESSAGE- EVIDENCE-CAPTURE companion documenting how to consume the rare-but-precious RUF samples that complement RUA aggregate counts at the per-failed- message granularity level: RUA tells the operator "10,000 messages from source IP 192.0.2.1 failed DMARC alignment on 2026-05-21" (the daily volume aggregator across all messages from that source), RUF gives ONE redacted sample of those 10,000 messages showing the exact misalignment scenario (the specific From: domain that failed alignment, the missing-vs- present DKIM signature for that message, the SPF record state at the moment of evaluation, the Received: chain showing the forwarder hops the message traversed). RUF is the per- incident microscope; RUA is the daily volume aggregator. Together they form the COMPLETE FORENSIC + MONITORING STACK every operator needs for the diagnostic workflows §7-§10 of this page documents. Read the forensic- reports spoke alongside this page when an operator needs to drill from "what is this RUA failure-spike about?" (this page's diagnostic starting point) to "what specifically is the forensic wire-evidence for ONE message in that spike?" (the forensic-reports spoke's per-message evidence-capture protocol) — especially valuable on operator domains whose ruf= configuration successfully captures samples from the ~5% of receivers that implement RUF emission.
• SPF for Google Workspace — the WORKSPACE-TENANT-SPF- PUBLICATION-MISCONFIGURATION-AS- LOAD-BEARING-WORKSPACE-SPECIFIC- ROOT-CAUSE-CLASS-FOR-EVERY-DMARC- FAIL-SYMPTOM-CATALOGUED-HERE companion to THIS DMARC troubleshooting reference. Where THIS page documents the symptom- driven DMARC failure-mode diagnostic playbook (the dmarc=fail per-source- IP root-cause attribution branches, the p=quarantine- unexpected-quarantine root-cause tree, the p=reject- unexpected-reject root-cause tree, the missing-RUA root-cause tree, the SPF-fail-and-DKIM-pass-but- dmarc-still-fails alignment- misconfiguration root-cause branch), the SPF-for-Google- Workspace spoke is the WORKSPACE-TENANT-SPECIFIC ROOT- CAUSE REFERENCE documenting the per-tenant SPF publication- discipline whose misconfiguration is the load-bearing Workspace- specific root-cause class behind every per-Workspace-tenant DMARC- fail symptom the playbook traces at FOUR Workspace-specific-DMARC- troubleshooting-symptom-to-SPF- publication-root-cause dimensions: (i) "All Workspace outbound mail failing dmarc=fail per-source-IP across every Gmail- receiver" symptom root-cause = missing or wrong include:_spf.google.com in the per-tenant SPF publication — the SPF- for-Workspace spoke documents the canonical v=spf1 include:_spf.google.com ~all Workspace-tenant publication discipline whose absence is the load-bearing root cause of the "every per-source-IP Workspace message fails SPF and therefore fails DMARC" symptom the playbook's per-source-IP root- cause branch traces back; (ii) "spf=permerror on a Workspace tenant — 10-DNS-lookup ceiling exceeded" symptom root-cause = per-tenant SPF publication exceeding the RFC 7208 §4.6.4 10-DNS-lookup budget after include:_spf.google.com nested-cascade expansion — the SPF-for-Workspace spoke documents the per-tenant SPF cascade-flattening discipline and per-third-party-sender cascade budget-accounting whose budget-overflow is the load- bearing root cause of the playbook's spf=permerror- per-tenant root-cause branch (the include:_spf.google.com cascade alone consumes ~5 DNS lookups before any per-tenant third-party-sender cascade is appended); (iii) "Mail from per-tenant Workspace SMTP relay / mail-flow-connector smarthost failing SPF intermittently" symptom root- cause = per-tenant outbound gateway source-IP missing from the published include cascade — the SPF-for-Workspace spoke documents the per-tenant outbound- gateway IP-list publication discipline (per-tenant smarthost IP delegation, per-tenant per- third-party-sender include: cascade extension, per-tenant custom outbound-IP-range publication) whose IP-coverage gap is the load-bearing root cause of the playbook's per-source-IP intermittent SPF-fail symptom branch; (iv) "Per-Workspace-tenant subdomain marketing.<tenant> DMARC fails despite parent-domain SPF publication" symptom root-cause = missing per- subdomain SPF TXT record on the Workspace tenant — the SPF-for-Workspace spoke documents the per-tenant per-subdomain SPF publication discipline (per-tenant _spf.<subdomain> TXT publication, per-subdomain outbound-gateway delegation, per- subdomain third-party-sender cascade extension) whose absence is the load-bearing root cause of the playbook's per-subdomain DMARC-fail symptom branch — the sp=-tag-evaluation evaluator inherits the parent- domain SPF publication only when the subdomain has no explicit SPF TXT record, and when the subdomain does publish SPF the per-subdomain SPF-publication discipline the SPF-for-Workspace spoke prescribes is the load-bearing root-cause class behind the per-subdomain DMARC failure. Read THIS page when DIAGNOSING a per-message or per-source-IP DMARC-fail symptom on a Workspace tenant; read the SPF-for-Workspace spoke when AUDITING or REPAIRING the per- tenant SPF publication discipline whose misconfiguration is the playbook's load-bearing Workspace-specific root-cause class.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC results plus the alignment evaluation. Built on includes/EmailHeaderParser.php.
• Domain Security Checker — live DNS lookups for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA. Reports the exact SPF lookup count for the 10-DNS- lookup ceiling diagnosis.
• DNS Record Generator — generate syntactically-correct DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA records from a guided wizard.
• Blacklist Checker — check sending IPs against major RBLs / DNSBLs. Poor IP reputation drives spam-folder placement even with DMARC pass.
• Reverse DNS & PTR records — the IP-level outbound-identity proof. Missing or mismatched PTR is one of the highest-frequency causes of the "DMARC pass but message rejected anyway" pattern operators arrive at this page to diagnose. Gmail's 550-5.7.25 ("messages with multiple addresses or that don't have a valid PTR record") and Microsoft 365's 550 5.7.1 Service unavailable; Client host [IP] blocked are the canonical receiver responses when forward-confirmed-reverse-DNS (FCrDNS) validation fails — DMARC alignment can be passing on the message body while the TCP connection itself is being rejected at the receiver edge before the SMTP DATA phase. Read this when an operator reports "my Authentication-Results header shows dmarc=pass but the receiver still bounced my mail". The deep dive covers the FCrDNS validation rule (PTR(ip) = hostname AND A(hostname) = ip), shared-IP vs dedicated-IP PTR responsibility, the deprecated SPF ptr mechanism (RFC 7208 §5.5), and per-provider coordination patterns for AWS / Google Cloud / Azure / dedicated-IP ESPs.
• MX records explained — the TROUBLESHOOTING-RUA-MAILBOX-NOT- RECEIVING-REPORTS-AS-MX-MISCONFIG-ROOT- CAUSE-AND-DIAGNOSIS-LADDER companion to this DMARC failure-diagnosis playbook. Where THIS page documents the seven canonical DMARC-fail RUA-row diagnostic patterns (SPF root causes, DKIM root causes, alignment root causes, DNS-record- syntax errors, forwarding and mailing-list breakage, mailbox-provider-specific issues), the mx-records spoke documents the STRUCTURALLY-DISTINCT but CAUSALLY-LINKED diagnostic pattern that surfaces at the feedback-loop layer underneath the per- source-IP RUA aggregate-row patterns this page documents: the operator arrives at this troubleshooting page to diagnose a DMARC-fail row but the more fundamental complaint is that the operator sees NO RUA rows AT ALL — the rua=mailto:dmarc-rua@example.com tag is published, the receiver-side DMARC evaluation is happening, the receiver IS emitting per-receiver per-day aggregate reports, but the publisher's monitoring mailbox never receives them. Four MX-RR- MISCONFIG-AS-TROUBLESHOOTING-ROOT-CAUSE axes the mx-records spoke documents that complement this troubleshooting playbook: (i) "RUA mailbox sees zero aggregate reports" symptom as MX-NOT- PUBLISHED root cause — the operator published v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com but never published the apex MX RR on example.com (or the rua=mailto: sub-mailbox- delegation domain); receiver-side aggregate-report emission attempts to deliver the gzipped XML to the dmarc-rua@example.com mailbox but the per-receiver MX lookup returns NXDOMAIN (or a fallback A-record at the apex implicit-MX-fallback per RFC 5321 §5.1) and the receiver drops the report delivery attempt silently; the mx-records spoke documents the dig MX example.com diagnostic + the canonical NXDOMAIN-vs- no-MX-RR root-cause distinction; (ii) "RUA mailbox sees PARTIAL aggregate reports" symptom as MX-RR-PREFERENCE- ORDERING-MISCONFIG root cause — the operator published two MX RRs for load-balancing or failover but the lower- preference MX-EXCHANGE host is no longer accepting SMTP on port 25 (e.g. retired backup server, mis-configured firewall, TLS handshake failure due to expired certificate); receivers attempting the lower-preference fallback path receive connection failures and abandon the delivery attempt without retrying the higher-preference primary MX; the mx-records spoke documents the per-MX-EXCHANGE-host port-25-reachability-probe diagnostic + the per-receiver-side retry-backoff behaviour that explains why some receivers' aggregate reports arrive while others' do not; (iii) "RUA mailbox SUDDENLY stopped receiving aggregate reports" symptom as MX-RR-MIGRATION-WITHOUT-TTL-OVERLAP root cause — the operator migrated the RUA mailbox to a new receiver host but retired the old MX RR before the per- receiver DNS-cache TTL expired, leaving per-receiver MX caches resolving to the retired host that is no longer accepting SMTP; the mx-records spoke documents the rollover-with-TTL-overlap migration procedure (publish second MX RR at lower preference, verify ingestion at second MX during TTL window, retire first MX after TTL+slack expiry) that prevents the per-DNS-TTL ingestion-gap symptom; (iv) "RUA mailbox SOMETIMES misses aggregate reports from specific receivers" symptom as MX-EXCHANGE-FCrDNS-MISMATCH- OR-MX-EXCHANGE-IS-IP-ADDRESS-LITERAL root cause — the MX RR's EXCHANGE field points to a hostname whose forward A/AAAA RR resolves correctly but the receiver-side FCrDNS check (compare PTR-RR of resolved IP to the MX-EXCHANGE hostname) fails, OR the MX-EXCHANGE field contains an IP-address-literal per RFC 5321 §2.3.5 violation; per-receiver MX- evaluation rules vary (some receivers accept FCrDNS mismatches with reduced priority, others reject the delivery attempt entirely); the mx-records spoke documents the canonical FCrDNS-paired- forward-record verification discipline (publish A/AAAA RR matching the PTR-RR target on the MX-EXCHANGE host) and the RFC 5321 §2.3.5 IP-literal-prohibition compliance checklist. Pair this DMARC troubleshooting page (the symptom-to-root- cause diagnostic ladder for DMARC-fail RUA-row patterns) with the mx-records spoke (the apex MX-RR-publication-and- availability discipline reference) for the complete RUA-mailbox-deliverability- AND-DMARC-fail-row-diagnostic posture every operator needs when the troubleshooting question is "where ARE my aggregate reports?" rather than "why is THIS aggregate report row dmarc=fail?".
• DMARC for SaaS senders — the MULTI-TENANT-PLATFORM-CUSTOMER-DOMAIN-RUA-ROW-PATTERN-CATALOGUE-AND-PER-PLATFORM-REMEDIATION-COOKBOOK companion to this DMARC-troubleshooting diagnostic-workflow reference. Where THIS page documents the GENERAL DIAGNOSTIC workflow for DMARC-failure RUA rows (the Authentication-Results decode workflow, the per-source_ip attribution workflow, the per-verdict-class SPF-permerror-vs-DKIM-fail-vs-alignment- fail triage, the forward-confirmed-reverse-DNS FCrDNS validation, the deprecated SPF ptr mechanism, and the per-provider coordination patterns for AWS / Google Cloud / Azure / dedicated- IP ESPs), the DMARC-for-SaaS-senders deployment spoke documents the STRUCTURALLY-DISTINCT SaaS-PLATFORM-AS-SENDER class of diagnostic patterns this troubleshooting workflow surfaces. The SaaS-senders spoke documents the per-source_ip attribution cookbook that maps a SaaS-platform outbound IP cohort (149.72.0.0/16 for SendGrid, 69.72.32.0/19 for Mailgun, 54.240.0.0/12 for Amazon SES, 50.31.156.0/24 for Postmark, 208.65.144.0/21 for Mailchimp, 13.111.0.0/16 for Salesforce Marketing Cloud) to the per-platform-vendor remediation cookbook the operator runs to close the alignment gap (the SendGrid Domain-Authentication delegated-DKIM-signing publication, the Mailgun Domain-Verification CNAME publication, the Amazon SES Easy-DKIM three-CNAME publication, the Postmark DKIM two-CNAME publication, the Mailchimp Sending-Domains CNAME publication), the per-platform envelope-MAIL-FROM custom-Return-Path- domain publication that closes the SPF-aligned-pass side (SendGrid's em.<customer>.com bounce-domain CNAME, Mailgun's mg.<customer>.com subdomain, SES's custom MAIL FROM domain configuration, Postmark's Return-Path domain), and the per- platform-vendor DMARC-aligned-pass verification workflow operators use to confirm the remediation closed the alignment gap. The SaaS-senders spoke is the canonical operational reference for the dkim=pass + aligned=false RUA-row pattern (a SaaS-platform sender produces a cryptographically-valid DKIM signature with the platform-shared d= identifier but the customer-domain header-From produces aligned=false under adkim=r / adkim=s because the d= and header-From organisational domains do not match) the diagnostic patterns documented here are intended to surface, plus the per-platform-vendor onboarding regression pattern (a newly-onboarded SaaS-platform-sender appears in the RUA stream as an unattributed source_ip cohort with high-volume + aligned=false + no-platform-signature-customisation, signalling the customer has not yet published the per-platform-vendor delegated-DKIM-signing CNAMEs). Read the SaaS-senders spoke alongside this page when triaging a DMARC-failure RUA row whose source_ip attribution maps to a SaaS-platform IP cohort and you need the per-platform-vendor remediation reference to close the alignment gap and unlock p=quarantine / p=reject enforcement for the customer domain.
• Why SPF alone is insufficient — the SPF-PROTOCOL-LEVEL-STRUCTURAL- INSUFFICIENCY-TAXONOMY-AS-LOAD-BEARING- PATTERN-1-AND-PATTERN-2-ROOT-CAUSE-CLASS- REFERENCE companion to this DMARC- troubleshooting workflow. Where THIS page documents the canonical symptom-driven troubleshooting ladder Pattern 1 (per- publisher per-message SPF-aligned-pass-rate regression at per-receiver per-source-IP granularity) and Pattern 2 (per-forwarder- hop per-publisher per-mailing-list-recipient alignment-pass-loss at the per-forwarder envelope-rewrite boundary) diagnostic ladders, the why-spf-alone-is-insufficient spoke is the PROTOCOL-LEVEL-INSUFFICIENCY- TAXONOMY canonical reference documenting how Pattern 1 and Pattern 2 troubleshooting diagnostic root-cause classes resolve to the per-publisher per-domain SPF-protocol- level structural-insufficiency-class catalogue every per-publisher per-domain DMARC-deployment-architect must understand BEFORE concluding the per-message SPF- aligned-pass regression is a per-publisher deployment-fault rather than an inherent SPF-protocol-level failure-mode at four SPF-insufficiency-root-cause-class coupling dimensions: (i) Pattern 1 SPF- aligned-pass-regression diagnostic ladder bottoms out on per-publisher SPF-record- publication-discipline failure-class — the symptom-driven Pattern 1 ladder THIS page documents (per-message SPF-aligned- pass-rate decline at per-receiver per- source-IP granularity) structurally bottoms out at the per-publisher per-domain SPF- record-publication-discipline failure-class catalogue the why-spf-alone-is-insufficient spoke documents (10-DNS-lookup limit overflow, void-lookup overflow, multi- record SPF publication, record-syntax error, malformed mechanism); without the protocol-level SPF-insufficiency reference, Pattern 1 diagnosis collapses at the per- record-syntax-error symptom without identifying the per-publisher per-domain publication-discipline-failure-class root-cause; (ii) Pattern 2 per- forwarder-hop alignment-pass-loss diagnostic ladder bottoms out on per- forwarder envelope-MAIL-FROM-rewrite as protocol-level SPF-only-insufficiency — the symptom-driven Pattern 2 ladder THIS page documents (per-publisher per- mailing-list-recipient per-message alignment-pass-loss at the per-forwarder- hop boundary) structurally bottoms out at the per-forwarder envelope-MAIL-FROM- rewrite + per-forwarder-IP-source-IP invalidation protocol-level SPF-only- insufficiency the why-spf-alone-is- insufficient spoke documents as the canonical per-forwarder-class SPF-protocol- level failure-mode; without the protocol- level SPF-insufficiency reference, Pattern 2 diagnosis collapses at the per-message spf=fail symptom without identifying the per-forwarder envelope-rewrite root-cause- class; (iii) Pattern 3 DKIM- alignment-pass-failure diagnostic ladder bottoms out on per-publisher SPF-protocol- level-insufficiency forcing per-publisher DKIM-publication-discipline criticality elevation — when Pattern 1 and Pattern 2 SPF-aligned-pass paths are both structurally collapsed, the Pattern 3 DKIM-alignment-pass-failure ladder THIS page documents BECOMES the per-publisher per-message DMARC-aligned-pass-via-DKIM- only-path's load-bearing diagnostic surface — meaning the per-publisher per- selector DKIM publication-discipline (key- size, canonicalization-choice, selector- rotation, signed-headers-list) becomes operationally critical at a per-receiver per-message granularity the per-publisher per-domain SPF-publication discipline CANNOT provide; (iv) Pattern 4 per-source-IP-cohort attribution diagnostic ladder bottoms out on per- publisher SPF-protocol-level-insufficiency forcing per-publisher cross-mechanism message-layer-authentication-publication- discipline-stack completion — the Pattern 4 ladder THIS page documents (per- publisher per-source-IP cohort attribution for per-message DMARC-failure incidents) structurally bottoms out on the per- publisher per-domain SPF-protocol-level- insufficiency the why-spf-alone-is- insufficient spoke documents as the canonical justification for completing the per-publisher per-domain SPF + DKIM + DMARC + ARC complete-message-layer-authentication- publication-discipline-stack the troubleshooting ladder THIS page documents structurally consumes at every per-publisher per-message diagnostic gate. Read the why-spf-alone-is- insufficient spoke ALONGSIDE this DMARC- troubleshooting reference whenever the per- publisher per-domain Pattern 1 / Pattern 2 / Pattern 3 / Pattern 4 diagnostic ladders THIS page documents need a protocol-level SPF-structural-insufficiency root-cause- class catalogue for the per-publisher per-domain cross-mechanism remediation decision.
• DKIM key rotation — the PER-PUBLISHER-PER-SELECTOR-KEY- ROTATION-OPERATIONAL-DISCIPLINE-AS-LOAD- BEARING-PATTERN-3-DKIM-ALIGNMENT-FAILURE- DIAGNOSTIC-ROOT-CAUSE-CLASS-CATALOGUE companion to this DMARC-troubleshooting reference. Where THIS page documents the Pattern 3 DKIM-alignment-failure diagnostic ladder (per-publisher per-domain per-message dkim=fail / dkim=permerror / dkim=temperror / dkim=policy verdict attribution at the per-message receiver- side authentication-results gate), the DKIM-key-rotation spoke is the per- publisher per-selector key-rotation OPERATIONAL DISCIPLINE the Pattern 3 diagnostic ladder structurally bottoms out on at four per-rotation-cutover-class root- cause coupling dimensions: (i) per- rotation stale-public-key-cache-during- cutover root-cause class — when the per-publisher per-rotation cutover retires the OLD selector before the receiver-side DNS-cache TTL elapses, per- message DKIM-Signature verification fails against the new public-key TXT record (the receiver still caches the OLD public key but the message is signed with the NEW private key), producing the Pattern 3 canonical dkim=fail verdict regression — the per-publisher per- rotation overlap-window-must-exceed- receiver-side-DNS-cache-TTL discipline THIS DKIM-key-rotation spoke documents is the load-bearing operational-discipline root- cause-class the Pattern 3 ladder bottoms out on; (ii) per-rotation retired-selector-deletion-too-early root- cause class — when the per- publisher per-rotation cutover deletes the OLD selector's p=-tag public- key TXT record before the receiver-side in-flight messages (signed with the OLD selector, still en route through forwarders / store-and-forward queues) reach the receiver, per-message DKIM-Signature verification fails because the per-message selector lookup returns NXDOMAIN, producing the Pattern 3 canonical dkim=permerror verdict — the per-publisher per-rotation retired-selector-must-survive-in-DNS-until- store-and-forward-queue-drains discipline THIS DKIM-key-rotation spoke documents is the operational-discipline root-cause- class the Pattern 3 ladder bottoms out on at the retired-selector-deletion-cutover boundary; (iii) per-rotation cryptographic-strength-upgrade discipline- gap root-cause class — when the per-publisher per-rotation cutover ships a new selector at the legacy 1024-bit RSA strength (rather than the RFC 8301 2048- bit floor), receivers enforcing the RFC-8301 cryptographic-strength baseline emit dkim=policy verdicts rejecting the per-message signature — the per-publisher per-rotation 1024-to- 2048-bit upgrade discipline THIS DKIM- key-rotation spoke documents is the operational-discipline root-cause-class the Pattern 3 ladder bottoms out on at the cryptographic-strength-floor- enforcement boundary; (iv) per- rotation selector-name-publication- order-violation root-cause class — when the per-publisher per-rotation cutover publishes the NEW selector's p=-tag public-key TXT record AFTER it starts signing with the new private key (rather than BEFORE), per-message DKIM-Signature verification fails because the per-message selector lookup returns NXDOMAIN at message-arrival time, producing the Pattern 3 canonical dkim=temperror verdict during the per-rotation DNS-propagation-window — the per-publisher per-rotation publish- new-selector-FIRST-then-rotate-signing- key discipline THIS DKIM-key-rotation spoke documents is the operational- discipline root-cause-class the Pattern 3 ladder bottoms out on at the per-rotation DNS-propagation-window boundary. Read the DKIM-key-rotation spoke ALONGSIDE this DMARC-troubleshooting reference whenever the per-publisher per-domain Pattern 3 DKIM-alignment-failure diagnostic ladder THIS page documents needs the per- publisher per-selector key-rotation operational-discipline root-cause-class catalogue for the per-publisher per- rotation cutover remediation decision.
• DMARC multi-domain strategy — the MULTI-DOMAIN-ESTATE-SPECIFIC DMARC-TROUBLESHOOTING-COORDINATION companion to this DMARC-troubleshooting diagnostic-ladder reference. Where THIS page documents the provider- agnostic per-symptom diagnostic ladder (Pattern 1 SPF-misalignment, Pattern 2 DKIM-misalignment, Pattern 3 DKIM- temperror, Pattern 4 SPF-permerror, Pattern 5 forwarding-induced failure), the multi-domain-strategy spoke is the MULTI-DOMAIN-ESTATE-SPECIFIC diagnostic-coordination guide at FOUR per-multi-domain-estate-to-DMARC- troubleshooting coupling dimensions: (i) per-organizational-domain diagnostic-ladder scoping discipline — when the org-wide DMARC-aligned- pass-rate degrades, the multi-domain- strategy spoke's per-organizational- domain attribution discipline tells operators which of the brand.com / brand-eu.com / brand-shop.com / brand-newsletter.com domains is the locus of the degradation so the diagnostic ladder THIS page documents is scoped to the right per-domain RUA stream — the multi-domain spoke documents the per-organizational-domain attribution discipline required to scope the diagnostic ladder to the right per-domain rua evidence stream; (ii) per-parked-domain defensive p=reject; sp=reject; publication discipline as a diagnostic-load-reduction primitive — when parked defensive domains like brand-typo.com publish v=DMARC1; p=reject; sp=reject; with empty SPF (v=spf1 -all) and revoked DKIM (v=DKIM1; p=;), the parked-domain rua stream becomes a pure attacker-spoof-attempt diagnostic stream rather than a legitimate-mail-failure diagnostic stream, dramatically simplifying the per-parked-domain Pattern 1-5 ladder application — the multi- domain spoke documents the per- parked-domain defensive publication discipline that converts the parked- domain rua stream into a pure- attack-attribution diagnostic-load- reduction primitive; (iii) per- organizational-domain sp=-tag subdomain- policy-coordination during the per- domain diagnostic ladder — when the per-organizational-domain _dmarc.brand.com publishes sp=quarantine;, every marketing.brand.com, support.brand.com, noreply.brand.com subdomain's per-symptom diagnostic ladder MUST be scoped to the sp=-inherited policy rather than the apex p= policy — the multi-domain spoke documents the per-organizational-domain sp=-tag inheritance discipline that scopes the per- subdomain diagnostic ladder; (iv) per-multi-domain-estate cross-domain RUA-feed aggregation discipline — the multi-domain strategy spoke's per-estate rua- mailbox-aggregation discipline (where rua=mailto:dmarc@brand-rua- collector.com is delegated across every brand-domain's _dmarc record via the cross-domain brand-rua-collector.com._report._dmarc.brand-eu.com verification record) is the load- bearing per-estate evidence-aggregation primitive the diagnostic ladder THIS page documents consumes — the multi-domain spoke documents the per-estate cross-domain rua-feed aggregation discipline operators execute to centralize the per-estate diagnostic-ladder evidence stream. Read the multi-domain-strategy spoke ALONGSIDE this DMARC-troubleshooting diagnostic-ladder reference whenever the per-symptom diagnostic ladder THIS page documents is being applied across the organization's multi- domain estate — the multi-domain spoke is the canonical per-multi- domain-estate diagnostic-coordination reference whose per-organizational- domain + per-parked-domain + per- sp=-tag-inherited-subdomain + per- estate-rua-feed-aggregation disciplines are the LOAD-BEARING multi-domain-estate execution discipline every estate-wide DMARC- troubleshooting cycle depends on.
• Phishing protection — the canonical outcomes-layer anti-phishing defense framework reference documenting how each symptom-driven diagnostic ladder THIS page catalogues directly maps to a phishing-variant detection boundary: (i) the Pattern-1 SPF-aligned-pass-failure ladder ALSO detects the display-name-phishing variant (attacker sends from a non-publisher-controlled domain with a forged Friendly-From header that mimics the publisher's executive — the resulting rua row shows spf=pass for the attacker-controlled envelope but spf-aligned=false against the forged Friendly-From), (ii) the Pattern-2 per-forwarder-hop alignment-loss ladder ALSO detects the ARC-validated- forwarder-phishing variant where the attacker exploits receiver- side ARC chain acceptance from a legitimate forwarder hop (mailing-list, .forward rule, Gmail-to-Gmail forwarding) to deliver phishing whose originating-hop SPF fails but whose forwarder ARC sealed the upstream authentication result, (iii) the Pattern-3 DKIM- alignment-failure ladder ALSO detects the compromised-third-party-ESP phishing variant where the attacker has compromised an ESP account legitimately included in the publisher's SPF / DKIM stack and sends from the ESP infrastructure with dkim=pass on the ESP's d=-tag organisational domain but dkim-aligned=false against the publisher's organisational domain, and (iv) the Pattern-4 per-source- IP-cohort-attribution ladder ALSO detects the lookalike-domain-phishing variant where the attacker registers a typo-squatted lookalike domain (paypa1.com, microsft.com) and sends from attacker-controlled infrastructure on a bulletproof-hosting CIDR or residential-proxy cluster the per-source-IP-cohort attribution ladder surfaces as a new unknown source_ip × From:-domain combination. Read the phishing-protection spoke ALONGSIDE this DMARC- troubleshooting diagnostic playbook whenever the operator asks "is this rua-stream regression a misconfiguration or a phishing campaign in progress" — the answer is FOUR-LAYERED: THIS page documents the symptom-driven diagnostic ladders, the phishing-protection spoke documents the receiver-side phishing-variant mapping for each ladder's terminal- detection boundary, and the cross-protocol defense layers (DKIM-alignment-as-primary- cryptographic-defense + DMARC- enforced-From-header- authentication + BIMI-brand- indicator-as-visual-trust + ARC-chain-validation + MTA- STS-transport-layer-anchored- rejection-of-plaintext- downgrade-interception) that the phishing-protection spoke coordinates as the anti-phishing defense stack.
• SPF mechanisms explained — the RFC-7208-§5-PER-MECHANISM- EVALUATION-SEMANTIC-CATALOGUE-AS- LOAD-BEARING-PATTERN-2-SPF-FAIL- DIAGNOSTIC-LADDER-PER-MECHANISM- ROOT-CAUSE-TAXONOMY companion to this DMARC troubleshooting reference. Where THIS page documents the symptom-driven DMARC- troubleshooting pattern catalogue (Pattern 1 alignment-failure; Pattern 2 SPF-fail; Pattern 3 DKIM-fail; Pattern 4 cross-protocol receiver-side disagreement), the spf_mechanisms_explained spoke documents the canonical RFC 7208 §5 per-mechanism evaluation-semantic catalogue the Pattern-2 SPF-fail diagnostic ladder THIS page documents at the per-row auth_results.spf.result verdict-class level structurally depends on at the per-mechanism token level. FOUR structurally- distinct PER-MECHANISM-VS-PATTERN-2- SPF-FAIL-DIAGNOSTIC-LADDER-ROOT- CAUSE-TAXONOMY dimensions the Pattern-2 SPF-fail diagnostic ladder THIS page documents operationally consumes: (i) per-row auth_results.spf.result=permerror + per-mechanism RFC 7208 §4.6.4 10- DNS-lookup-cap-overflow AS LOAD- BEARING-PATTERN-2-SPF-FAIL-PERMERROR- ROOT-CAUSE-CLASS-VIA-PER-MECHANISM- include:-CASCADE- OVERFLOW — the Pattern-2 diagnostic ladder THIS page documents catalogues the per-row spf=permerror + policy_evaluated.spf=fail verdict-class as a canonical SPF- publisher-side defect class; the spf_mechanisms_explained spoke documents the per-mechanism RFC 7208 §4.6.4 DNS-lookup-count contribution (each include: + a + mx + exists + redirect= token contributes ≥1 lookup) that produces the per-publisher-include-cascade overflow root-cause the Pattern-2 permerror verdict-class diagnoses; (ii) per-row auth_results.spf.result=fail + per-mechanism -all qualifier AS LOAD-BEARING-PATTERN- 2-SPF-FAIL-HARD-FAIL-ROOT-CAUSE- CLASS-VIA-PER-MECHANISM-NEGATIVE- TERMINAL-MODE — the Pattern-2 diagnostic ladder catalogues the per-row spf=fail verdict on a per-source-IP NOT enumerated in the per-publisher SPF mechanism token stack; the spf_mechanisms_ explained spoke catalogues the per-mechanism RFC 7208 §4.7 terminal -all qualifier semantic (per-publisher terminal hard-fail commitment) and the per-mechanism RFC 7208 §4.6.2 per-mechanism prefix-qualifier evaluation order the per-source-IP fail verdict is constructed from; (iii) per-row auth_results.spf.result=neutral + per-mechanism ?all or +all qualifier AS LOAD-BEARING-PATTERN-2-SPF-FAIL- NEUTRAL-ROOT-CAUSE-CLASS-VIA- PER-MECHANISM-OVER-PERMISSIVE- TERMINAL-MODE — the Pattern-2 diagnostic ladder catalogues the per-row spf=neutral verdict as a per-publisher SPF-publication defect where the per-publisher terminal qualifier is too permissive (?all produces neutral OR +all authorizes any source-IP — both pathological); the spf_mechanisms_explained spoke catalogues the per-mechanism RFC 7208 §4.7 neutral / pass / softfail qualifier semantic the per- publisher SPF-publication audit must enforce; (iv) per-row auth_results.spf.result=temperror + per-mechanism RFC 7208 §5.7 per-include-zone SERVFAIL or TIMEOUT AS LOAD-BEARING-PATTERN-2- SPF-FAIL-TEMPERROR-ROOT-CAUSE- CLASS-VIA-PER-MECHANISM-DNS- TRANSIENT-FAILURE — the Pattern-2 diagnostic ladder catalogues the per-row spf=temperror verdict as a per-include-zone DNS transient-failure root-cause; the spf_mechanisms_explained spoke catalogues the per-mechanism RFC 7208 §5.7 per-include-zone recursive-resolution failure-mode (SERVFAIL, NXDOMAIN, timeout, mid- zone-update transient-failure) that produces the per-message per- receiver evaluation-result the Pattern-2 temperror diagnosis operationally consumes. Read the spf_mechanisms_explained spoke ALONGSIDE this DMARC troubleshooting reference when the Pattern-2 SPF- fail diagnostic ladder requires the per-mechanism RFC 7208 §5 evaluation- semantic catalogue — the spoke is the canonical RFC 7208 §5 PER- MECHANISM EVALUATION-SEMANTIC CATALOGUE REFERENCE the Pattern-2 SPF-fail diagnostic ladder THIS page documents structurally depends on at the per-mechanism token-by-token decode level.
• Email spoofing (the seven canonical techniques) — where THIS page documents the symptom-driven DMARC-troubleshooting diagnostic ladder operators execute ONCE per-publisher per-domain DMARC-fail rows are observed in aggregate-XML rua reports, the email-spoofing spoke documents the seven canonical attacker techniques whose per-message exploit signatures appear in the SAME aggregate-XML row-level evidence stream — the critical operator skill THIS troubleshooting playbook supports IS the per-row attribution decision of "is this row a legitimate sender misconfiguration the diagnostic ladder must remediate, OR is this row an active spoofing campaign the diagnostic ladder must surface to the per-publisher security-incident-response queue". FOUR structurally-distinct DMARC- TROUBLESHOOTING-PATTERN-TO- SPOOFING-TECHNIQUE-CLASSIFICATION dimensions the email-spoofing spoke operationally documents: (i) per-source-IP DMARC-fail row from a previously-unknown source-IP as load-bearing diagnostic-ladder branchpoint between "ESP onboarded without SPF-include update" (legitimate misconfiguration) AND "active direct-domain-spoofing campaign from attacker-controlled infrastructure" (security incident) — the per-source-IP DMARC-fail evidence pattern is identical between the two attribution classes; the email-spoofing spoke documents the per-source-IP-PTR- forward-DNS + per-source-IP-AS- ownership + per-source-IP-geolocation attribution discipline that distinguishes them; (ii) per-source-IP DMARC-fail spike burst pattern as load-bearing diagnostic-ladder branchpoint between "new ESP campaign send" (legitimate) AND "active spoofing campaign" (security incident) — both attribution classes produce burst patterns in aggregate-XML evidence; the email-spoofing spoke documents the per-burst per-source-IP per-message-volume + per-receiver- distribution attribution discipline that distinguishes them; (iii) per-source-IP DMARC-fail with NO matching per-source-IP legitimate entry in the per- publisher sender-inventory as load-bearing diagnostic-ladder confirmation primitive for active- spoofing classification — when a DMARC-troubleshooting diagnostic-ladder traversal cannot identify a legitimate owner of the per-source-IP at the per-publisher sender- inventory boundary, the email- spoofing spoke's seven-technique catalogue is the load-bearing attack-classification reference; (iv) per-source-IP DMARC-fail with attacker-controlled IDN-homograph or cousin-domain From: header surfaced in ruf forensic reports as load-bearing diagnostic-ladder evidence for registrar-layer defensive action — the ruf forensic report's per-message From: header capture surfaces IDN-homograph and cousin-domain attacker primitives the email-spoofing spoke catalogues; this attack class CANNOT be remediated through the per-publisher DMARC-publication diagnostic ladder THIS page documents — it requires registrar- layer defensive registration of confusables outside the per- publisher DMARC-publication surface. Read the email-spoofing spoke ALONGSIDE this DMARC- troubleshooting playbook whenever the operator scopes a per-row attribution decision against aggregate-XML evidence — the seven canonical spoofing techniques the email-spoofing spoke catalogues materially define the per-row attacker- signature classification surface this DMARC-troubleshooting diagnostic ladder consumes as the load-bearing per-row attribution-decision input.
• BIMI SVG Tiny PS logo requirements — the BIMI-LOGO-NON-DISPLAY-DIAGNOSTIC- LADDER-AS-LOAD-BEARING-FILE-FORMAT-AXIS- TRIAGE-REFERENCE companion to this DMARC- troubleshooting playbook. Where THIS page documents the operator-side diagnostic ladder for the symptom-driven DMARC-failure classes (record-not-found, alignment-mismatch, SPF-permerror, DKIM-fail, forwarder body modifications, ARC-disabled inbound paths), the BIMI- SVG-requirements spoke is the DEDICATED FILE-FORMAT-COMPLIANCE diagnostic reference for the ORTHOGONAL failure class operators routinely conflate with DMARC failures: "the BIMI logo stopped rendering even though my per-domain DMARC enforcement and aggregate-XML pass-rate evidence are both green." This conflation arises from FOUR distinct Tiny PS file-format regression-axes — (i) the baseProfile="tiny-ps" root attribute silently dropped during an SVG re-export, (ii) the <title>-first-child requirement violated by Adobe Illustrator re-ordering element output, (iii) a forbidden element (<script>, <animate>, <foreignObject>) or forbidden attribute (on* event handlers, external href, javascript: URIs) introduced by a designer toolchain, (iv) the 32KB file-size cap exceeded by uncompressed XML overhead — and the BIMI-SVG-requirements spoke is the ONLY operator-reference that catalogues all four axes with byte-level diagnostic detail. Read the BIMI-SVG- requirements spoke whenever the DMARC-troubleshooting workflow scopes a per-row BIMI-logo-non-display complaint and the per-domain DMARC enforcement and aggregate-XML evidence-stream rule out the four canonical DMARC-side failure classes — the BIMI Tiny PS file-format axis is the load-bearing ORTHOGONAL diagnostic surface this DMARC-troubleshooting playbook routes the operator to.
• Email deliverability — the PER-PUBLISHER-PER-MAILBOX- PROVIDER-DELIVERABILITY-REGRESSION-AS- LOAD-BEARING-OPERATOR-DISCOVERY-PATH- INTO-DMARC-TROUBLESHOOTING-DIAGNOSTIC- LADDER companion reference. Where THIS page documents the cross-cutting symptom-driven DMARC=fail diagnostic ladder (the canonical per-symptom DMARC-failure-class diagnostic decision tree spanning SPF-fail diagnostic ladder, DKIM-fail diagnostic ladder, identifier- alignment-fail diagnostic ladder, forwarder-induced-fail diagnostic ladder, replay-attack diagnostic ladder), the email-deliverability spoke documents the per-publisher per-mailbox- provider deliverability-baseline regression outcome (the per-publisher Gmail-inbox-vs-spam-vs-promotions-vs- blocked / Yahoo / M365 per-day per- publisher delivery-placement-rate aggregate signal degradation each per- publisher's per-mailbox-provider reputation-and-engagement signal stream manifests when DMARC-aligned-pass-rate floors collapse), across four per- publisher-deliverability-regression- symptom-to-DMARC-troubleshooting- diagnostic-ladder-entry-point-coupling dimensions: (i) per-publisher- per-mailbox-provider-spam-placement-rate- regression-as-canonical-DMARC-aligned- pass-rate-floor-collapse-symptom — per-publisher per-day per-mailbox- provider spam-placement-rate regressions (the per-publisher per-mailbox-provider per-day proportion of per-publisher messages routed to spam-vs-inbox at Gmail / Yahoo / M365 receiver-side spam-filter decision-tree) are canonical per-publisher per-mailbox- provider DMARC-aligned-pass-rate floor collapse symptoms that the per-publisher operator must route INTO the DMARC- troubleshooting diagnostic ladder THIS page documents to attribute the per- publisher per-mailbox-provider DMARC- aligned-pass-rate floor collapse to canonical DMARC-failure-class root cause; (ii) per-publisher-per- mailbox-provider-quarantine-vs-block- placement-rate-regression-as-canonical- DMARC-p-tag-enforcement-cascade- symptom — per-publisher per-day per-mailbox-provider quarantine-vs-block- placement-rate regressions at receivers honoring the per-publisher DMARC TXT record p=quarantine / p=reject tag-value enforcement are canonical per-publisher per-mailbox-provider DMARC-aligned-pass- rate floor collapse symptoms with the per-publisher per-mailbox-provider per- message DMARC-fail verdict triggering the per-publisher p-tag terminal enforcement; the per-publisher operator routing into the DMARC-troubleshooting diagnostic ladder THIS page documents attributes the per-publisher per- mailbox-provider DMARC-fail verdict root cause to the canonical SPF-fail / DKIM-fail / identifier-alignment-fail / forwarder-induced-fail / replay- attack diagnostic ladder entries; (iii) per-publisher-per- mailbox-provider-engagement-signal- regression-as-canonical-per-publisher- per-mailbox-provider-reputation-floor- collapse-symptom-correlated-with-DMARC- aligned-pass-rate-collapse — per-publisher per-day per-mailbox- provider engagement-signal regressions (per-publisher per-mailbox-provider per- day open-rate / click-rate / mark-as- not-spam-rate / mark-as-spam-rate signals at Gmail-Postmaster-Tools / M365- SNDS / Yahoo-postmaster) correlated against per-publisher per-mailbox- provider DMARC-aligned-pass-rate regressions are canonical per-publisher per-mailbox-provider reputation-floor collapse symptoms that the per-publisher operator routes INTO the DMARC- troubleshooting diagnostic ladder THIS page documents to disentangle DMARC- aligned-pass-rate-collapse-driven reputation degradation from per- publisher per-mailbox-provider engagement-signal-only reputation degradation; (iv) per-publisher- per-mailbox-provider-deliverability- baseline-shift-attribution-as-DMARC- troubleshooting-diagnostic-ladder-exit- gate-for-remediation-targeting — the per-publisher per-mailbox-provider deliverability-baseline-shift attribution outcome the DMARC-troubleshooting diagnostic ladder THIS page documents produces (canonical DMARC-failure-class attribution: SPF-fail root cause / DKIM- fail root cause / identifier-alignment- fail root cause / forwarder-induced- fail root cause / replay-attack root cause) directly drives the per- publisher operator-side per-publisher per-mailbox-provider deliverability- baseline remediation targeting (per-publisher per-mailbox-provider SPF authorization update vs DKIM key- rotation cadence adjustment vs identifier-alignment authoring update vs forwarder allowlist coordination vs replay-attack signature-narrowing remediation). Read this WITH the DMARC- troubleshooting diagnostic ladder reference when the per-publisher per- mailbox-provider deliverability- baseline degradation root-cause attribution sequence reaches the operator's queue: THIS page documents the cross-cutting symptom-driven DMARC=fail diagnostic ladder, the email-deliverability spoke documents the per-publisher per-mailbox-provider deliverability-baseline regression outcome whose per-mailbox-provider deliverability-degradation symptom class IS the canonical OPERATOR- DISCOVERY-PATH that routes the per- publisher operator INTO the diagnostic ladder THIS page documents.
• DKIM DNS record syntax (RFC 6376 §3.6.2) — the byte-level encoding-layer reference for the public-key TXT record at <selector>._domainkey.<domain>. Covers the v=DKIM1 prefix, the p= base64 public-key payload, the k=rsa / k=ed25519 key-type tag, the h= permitted-hash-algorithm tag, the t=y/s testing / strict- scope flags, the s= service-type tag, TXT-chunking past the 255-octet character-string limit, key revocation via empty p=, and the seven most common syntax mistakes. When Pattern 3 (DKIM selector typo / missing key) surfaces in this troubleshooting playbook, this is the DNS-encoding-layer reference for verifying the published TXT record's syntax matches the RFC 6376 §3.6.2 contract receiver-side verification assumes holds.
• DKIM-Signature header tag anatomy — the per-message DKIM-Signature header per-tag anatomy as load-bearing per-row DKIM-failure attribution decode-reference companion to this DMARC-troubleshooting diagnostic playbook. Where THIS page documents the operator-side per-row dkim- fail diagnostic ladder (Pattern 1 missing DKIM-Signature header, Pattern 2 body-hash mismatch, Pattern 3 DKIM selector typo or missing key, Pattern 4 per-selector public- key publication regression, Pattern 5 per- message algorithm-coverage mismatch), the DKIM-Signature-anatomy spoke documents the per-message header byte-grammar the operator MUST decode tag-by-tag to attribute per-row dkim-fail verdicts to the correct per-message DKIM-signing-discipline regression. Four DKIM-SIGNATURE-HEADER- ANATOMY-VS-DMARC-TROUBLESHOOTING-PER-ROW- DIAGNOSTIC cross-correlation axes the signature-anatomy spoke documents: (i) per-message DKIM-Signature d=<domain> tag VALUE STRUCTURALLY DETERMINES the per-message DKIM-leg DMARC-alignment evaluation that Pattern 1 (missing DKIM-Signature) and Pattern 4 (per-selector publication regression) per-row diagnostics decode — the per-message d= tag value MUST match the per-message From: header organizational domain under adkim=r (relaxed) or exact-match under adkim=s (strict) for the per-message DKIM-leg DMARC-aligned-pass verdict to emit; per-row diagnostic decode at Pattern 1 / Pattern 4 MUST read the d= tag to attribute per-row dkim-misalignment to the correct per-publisher per-domain signing-domain-vs-From-domain divergence; (ii) per-message DKIM-Signature bh=<base64> body-hash tag VALUE STRUCTURALLY DETERMINES the Pattern 2 (body-hash mismatch) per-row diagnostic decode — the per-message bh= tag carries the SHA-256 hash of the canonicalized message body that the receiver-side verifier recomputes from the in-transit body and compares against; per-row diagnostic decode at Pattern 2 MUST read the bh= tag alongside the c= canonicalization tag to attribute per-row body-hash-mismatch failure to per-message intermediary footer-injection or per- message line-ending normalization under c=simple mode; (iii) per- message DKIM-Signature s=<selector> selector tag VALUE STRUCTURALLY DETERMINES the Pattern 3 (DKIM selector typo / missing key) per- row diagnostic decode — the per- message s= tag identifies which per-publisher per-selector public- key TXT-RR at <selector>._domainkey.<d-value> the receiver-side verifier fetches; per- row diagnostic decode at Pattern 3 MUST read the s= tag to attribute per-row dkim-fail to a per-publisher per- selector publication-discipline regression (NXDOMAIN at the per-selector TXT-RR, per- selector retired-without-republication, or per-selector typo at signing time); (iv) per-message DKIM-Signature a=<algorithm> algorithm tag VALUE STRUCTURALLY DETERMINES the Pattern 5 (per-message algorithm-coverage mismatch) per-row diagnostic decode — the per-message a= tag identifies the per-message signature algorithm (rsa-sha256 per RFC 8301 / ed25519-sha256 per RFC 8463); per-row diagnostic decode at Pattern 5 MUST read the a= tag to attribute per-row dkim-neutral or dkim-permerror at receivers that lack Ed25519-aware verifiers, OR per-row dkim- policy verdicts at receivers that flag deprecated rsa-sha1 per- message signatures. Read THIS page when ATTRIBUTING per-row dkim-fail verdicts to the correct per-message DKIM-signing- discipline regression class; read the DKIM-Signature-anatomy spoke when DECODING the per-message DKIM-Signature header byte-grammar tag-by-tag so the per-row attribution chain is anchored to the canonical RFC 6376 §3.5 per-tag semantics every receiver-side verifier evaluates the per-message signature against.
• RFC 7489 — DMARC — the foundational DMARC specification.
• RFC 7208 — SPF — Sender Policy Framework, including the 10-DNS-lookup limit (§4.6.4).
• RFC 6376 — DKIM — DomainKeys Identified Mail signatures.
• RFC 8617 — ARC — Authenticated Received Chain.
• RFC 8601 — Authentication-Results — the header format every receiver uses to stamp its verdict.
• Microsoft SNDS + JMRP monitoring — DMARC reporting shows who fails authentication; Microsoft SNDS + JMRP shows how Outlook.com's filter and its users judge the mail that passes — the per-IP reputation signal aggregate reports cannot see.

14. Diagnose your DMARC issue now

DMARC Analyzer ingests aggregate (rua) reports via the includes/DmarcParser.php pipeline and surfaces per-source-IP failure rates in the dashboard — the inventory you need to root-cause Patterns 1, 2, and 7 from Section 2. The Email Header Analyzer (header_analyzer.php, built on includes/EmailHeaderParser.php) decodes individual failing messages for Patterns 3, 4, and 6. The Domain Security Checker (domain_checker.php, built on includes/DnsChecker.php) runs live DNS queries for Pattern 5 diagnostics including the exact SPF lookup-count.

Check my domain configuration Sign up — Free plan