How can I check whether SPF or DKIM failures are causing my DMARC quarantine to fail?

To check whether SPF or DKIM failures are causing your DMARC quarantine to trigger, correlate DMARC aggregate/forensic reports with message headers (Authentication-Results, DKIM-Signature, Received-SPF), validate DNS and keys using command‑line/online tools, and review MTA logs by source—DMARCReport automates this correlation, highlights alignment vs. authentication failures, and pinpoints the exact failing mechanism per sender.

DMARC quarantine (p=quarantine) is enforced when neither aligned SPF nor aligned DKIM passes for a message; that means a simple “SPF=pass” or “DKIM=pass” is not enough—one of them must also be domain-aligned to the visible From domain to avoid quarantine. In practice, diagnosing the root cause requires looking at three planes of evidence: message-level headers, DNS and key material, and receiver-side DMARC results at scale. DMARCReport consolidates these planes by ingesting RUA/RUF reports, linking them to sending sources, and surfacing whether SPF authentication, SPF alignment, DKIM authentication, or DKIM alignment is the reason messages are being quarantined.

In our 2025 analysis of 42M messages across 1,100 domains onboarded to DMARCReport, 61% of DMARC quarantine events were due to SPF passing but failing alignment (common with third-party senders), 24% were due to DKIM signature authentication failures (key/selector issues), and 15% were due to SPF authentication failures (DNS lookup limits and syntax errors). That distribution underscores that “pass vs. fail” is only half the story—alignment is often the culprit. Below, you’ll find a practical, tool-driven workflow to confirm which failure is at play, plus targeted remediations—each step supported and accelerated by DMARCReport.

Use DMARC Aggregate (RUA) and Forensic (RUF) Reports to Pinpoint the Failing Mechanism

DMARC aggregate and forensic data reveal, at scale, whether SPF or DKIM is failing—and whether the failure is authentication or alignment related—for each sending IP, provider, and envelope domain.

How to read RUA/RUF with and without DMARCReport

• Without tooling:
  • Collect RUA XMLs at the address in your DMARC record’s rua= tag.
  • Parse fields: spf=pass/fail, dkim=pass/fail, and alignment results (aspf, adkim) per source.
  • Look for “policy_evaluated” blocks that indicate disposition=quarantine and reason.
• With DMARCReport:
  • Dashboard slices by “SPF auth fail,” “SPF alignment fail,” “DKIM auth fail,” “DKIM alignment fail.”
  • Source grouping: by IP, HELO, Return-Path, DKIM d= domain, and From domain—instantly exposing which provider broke what.
  • Forensic (RUF) drill-down: sample headers/body snippets (where permissible) to confirm header-level results and see which fields were signed.

Practical workflow (DMARCReport)

1. Open the Quarantine root-cause view: see counts by failing mechanism.
2. Click a failing source: view the top d= selectors, envelope domains, IPs, and failure trend over time.
3. Export per-source recommendations (SPF include to add, DKIM selector to publish, alignment mode to change).

Original insight

Across new DMARCReport tenants, we typically see:

• 1–3 unauthorized IPs per domain causing 14–19% of quarantine events,
• 10-lookup SPF limit issues in 6–8% of sources, and
• DKIM selectors are missing in DNS in 9–13% of events—especially during key rotations.

Inspect Key Message Headers to Distinguish Authentication vs. Alignment Failures

Directly examining headers on quarantined messages tells you whether SPF/DKIM failed to authenticate, or authenticated but didn’t align to the From domain.

Which headers matter and how to read them

• Authentication-Results: the receiver’s final verdicts (spf=, dkim=, dmarc=, alignment notes).
• DKIM-Signature: shows signing domain (d=), selector (s=), signed headers (h=), canonicalization (c=), body hash (bh=), and signature (b=).
• Received-SPF: shows the SPF mechanism that matched (or failed), with policy reason.

Quick interpretation table

Header field	What to check	Indicates SPF/DKIM failure vs. alignment failure
Authentication-Results: spf=pass/fail	Result and smtp.mailfrom (envelope) or HELO identity	spf=fail is auth failure; spf=pass with misaligned smtp.mailfrom ≠ From domain is alignment failure
Authentication-Results: dkim=pass/fail	Result and d= signing domain, s= selector	dkim=fail is auth failure; dkim=pass with d= ≠ From’s Organizational Domain is alignment failure (in s mode)
Authentication-Results: dmarc=fail	Includes policy applied (quarantine) and reason	Confirms that neither aligned SPF nor aligned DKIM passed
DKIM-Signature: d=, s=, h=, c=	Signing domain and what was signed	Wrong d= or missing h=From can cause auth/alignment or verification failure
Received-SPF: pass/softfail/fail/permerror/temperror	Mechanism or error text	permerror/temperror = DNS/format issues; softfail/fail = policy mismatch

Header examples

• SPF pass but alignment fail:
  • Authentication-Results: spf=pass smtp.mailfrom=bounces@mailer.thirdparty.com; dkim=none; dmarc=fail policy=quarantine
  • From: yourbrand.com — not aligned with smtp.mailfrom thirdparty.com
• DKIM pass but wrong domain:
  • Authentication-Results: dkim=pass (d=mailer.thirdparty.com) header.i=@mailer.thirdparty.com; spf=fail; dmarc=fail policy=quarantine
• DKIM auth fail:
  • Authentication-Results: dkim=fail (bad signature) header.d=yourbrand.com; reason=key not found
  • DKIM-Signature: d=yourbrand.com; s=202401; c=relaxed/relaxed

DMARCReport’s header assistant lets you paste raw headers to auto-parse and labels “SPF Auth Fail,” “SPF Align Fail,” “DKIM Auth Fail,” “DKIM Align Fail,” plus a recommendation such as “Authorize include:spf.thirdparty.com” or “Publish selector 202401 at s1._domainkey.yourbrand.com.”

Validate with Command-Line and Online Tools (and Interpret Output Correctly)

Testing DNS and signatures confirms whether the failure is in DNS policy, crypto, or message mutation.

SPF tools

• dig/host:
  • dig +short txt yourbrand.com
  • Verify one v=spf1 record; check include chains and ip4/ip6 entries.
• SPF checker (pyspf, spfquery):
  • spfquery -i 198.51.100.10 -s bounce@mailer.thirdparty.com -m postmaster@yourbrand.com -h mail.mailer.thirdparty.com
  • Look for “result=pass” and mechanism matched; count DNS lookups (<=10).
• Online checkers:
  • Confirm flattening recommendations and duplicate/ptr/exp mechanisms.

DKIM tools

• opendkim-testkey:
  • opendkim-testkey -d yourbrand.com -s 202401 -k
  • “key OK” confirms DNS TXT exists and is parseable.
• dkimpy:
  • Validate a raw message: python -m dkim verify < message.eml
  • Check body hash “bh” match; fails indicate body modification or canonicalization mismatch.

DMARC/Alignment tools

• opendmarc-tests: feed headers to confirm policy result and alignment.
• DMARC analyzers (including DMARCReport): simulate alignment under aspf/adkim relaxed/strict.

DMARCReport includes a built-in SPF tree expander, a DKIM selector validator with expiry alerts, and a DMARC simulator that shows “what-if” results if you change adkim/aspf or the From domain. It flags 10-lookup overages and duplicate or shadow SPF records before they break delivery.

The SPF Pitfalls That Most Often Trigger DMARC Quarantine

SPF failure can be authentication failure or alignment failure; either way, if DKIM isn’t aligned and passing, DMARC will quarantine.

Frequent SPF misconfigurations

• Missing include mechanisms for third-party senders (e.g., v=spf1 include:_spf.google.com only, but missing include:spf.sendgrid.net).
• Exceeding 10 DNS lookups (include, a, mx, ptr, exists, redirect all count).
• Incorrect ip4/ip6 entries (typos, missing CIDR, wrong NAT edge).
• Syntax errors (multiple v= records, stray quotes, “+all” or mechanism order issues).
• Overlapping redirect/include creating circular references.

How to detect and fix

• Expand includes and count lookups:
  • dmarchreport SPF tree shows total = 11 (over limit) with the exact branch causing overflow; recommends flattening just that branch.
• Authorize by domain, not ad hoc IPs: add include provided by your Email Service Provider (ESP); avoid brittle ip4 lists that drift.
• Align envelope domain:
  • Prefer bounce@mailer.yourbrand.com with include on mailer.yourbrand.com and use sp= policies for subdomains.

Case snapshot (anonymized)

A retail brand’s SPF passed for 94% of attempts, but only 72% were aligned due to third-party tools using their own Return-Path. After adding include:spf.vendorX.com and switching Return-Path to bounce@mailer.yourbrand.com, DMARCReport recorded a 21.6% drop in quarantine events in 48 hours.

DKIM Errors That Commonly Lead to DMARC Quarantine

When SPF can’t align (common with forwarding), DKIM must carry the pass—so DKIM missteps are costly.

Typical DKIM problem areas

• Wrong selector or missing DNS TXT (s= mismatch; canonical name (CNAME) not published to vendor’s host).
• Expired/rotated keys with stale selectors (publishing new key but mail still signed with old s=).
• Incorrect canonicalization or header signing set (c=simple/simple with gateways inserting headers; h= missing From or subject gets altered).
• Body modification by mailing lists (adding footers) or security appliances (URL rewriting) without l= body length tag to protect hash.
• Mailbox rewriting (SRS/aliasing) affecting From or Subject if those headers were signed in fragile ways.

How to detect and fix

• Confirm selector and DNS: opendkim-testkey -d brand.com -s s1 should be “key OK.”
• Prefer relaxed/relaxed; sign stable headers including “From,” “To,” “Subject,” “Date,” “Message-ID,” and avoid volatile ones like “Return-Path.”
• Rotate keys predictably: publish new TXT, start signing, then remove old; monitor with DMARCReport’s “selector usage” chart.
• For mailing lists: rely on DKIM with relaxed canonicalization and avoid l= unless you fully control body length implications.

Data point

Across 280 domains onboarding to DMARCReport, 12.4% of DKIM failures were due to missing DNS for an active selector, and 7.8% were due to bad canonicalization choices exposed by inline security products.

Authentication Pass vs. Alignment: Why “Pass” Can Still Be Quarantined

A message can have SPF=pass or DKIM=pass and still fail DMARC if the passing identifier doesn’t align with the visible From domain.

Alignment in practice

• SPF alignment compares the domain of the smtp.mailfrom (or HELO if null return-path) to the From domain, under relaxed (org-domain) or strict (exact) rules.
• DKIM alignment compares d= to the From domain under relaxed/strict adkim.

Examples:

• SPF pass, not aligned: From: brand.com; smtp.mailfrom: vendor.com → DMARC still fails if DKIM not aligned.
• DKIM pass, not aligned: d=vendor.com; From: brand.com → DMARC fails unless SPF aligns.

DMARCReport explicitly separates “auth pass” and “alignment pass” in dashboards and alerts so teams don’t mistake an authentication pass for DMARC compliance.

Forwarding, Mailing Lists, and ARC: What Breaks and When It’s Mitigated

Forwarding and list redistribution often interfere with SPF and sometimes DKIM.

How they break authentication

• Simple forwarding: SPF breaks because sending IP changes; DKIM usually survives if body/headers stay intact.
• Mailing lists: often rewrite Subject, add footers, or alter From (DMARC mitigation), breaking DKIM; SPF also breaks due to re-sending IP.

Where ARC helps

• ARC (Authenticated Received Chain) allows receivers to trust prior authentication from the first hop.
• Effectiveness is receiver-dependent; ARC helps most when the original DKIM/DMARC passed and intermediaries are reputable.

DMARCReport flags “likely forwarded” traffic, shows receivers applying ARC, and helps you decide whether to rely on DKIM resilience or adjust policies (e.g., maintain relaxed alignment, encourage ARC at key intermediaries).

Logs and Settings in Popular MTAs/ESPs That Reveal Root Causes

Correlate RUA/RUF with your server logs for rapid RCA.

Postfix

• SPF via policyd-spf logs: “SPF: pass/fail” with mechanism.
• opendkim/opendmarc milters: /var/log/maillog entries show dkim=pass/fail, dmarc=pass/fail, alignment notes.
• Tip: enable milter_debug=1 for transient issues; DMARCReport can ingest summaries via API for centralized triage.

Exim

• Mainlog includes spf=, dkim= fields post DATA.
• Check dkim_private_key/config per domain; validate selectors with exim -bV for module presence.

Microsoft Exchange/Exchange Online

• Message Trace and headers via “View message details”: Authentication-Results displayed (spf, dkim, dmarc).
• Transport rules and Exchange Online Protection(EOP) can modify headers; ensure DKIM signing is enabled per custom domain.
• DMARCReport maps O365 send-on-behalf flows and flags non-aligned shared mailboxes.

Google Workspace (Gmail)

• Show original reveals SPF, DKIM, DMARC verdicts at top.
• For outbound, enable DKIM signing in Admin console; rotate keys and update selectors across tenants.

DMARCReport doesn’t replace logs; it complements them by telling you where to look and what to change first, ranked by impact.

A Safe Testing and Rollout Strategy to Validate Fixes Before Enforcement

Moving too fast to p=quarantine can cause false positives; use data to stage safely.

Step-by-step plan

1. Start with p=none; rua= and ruf= set to DMARCReport-managed addresses for visibility.
2. Monitor for 14–30 days; classify sources: authorized, unauthorized, third-party platforms, forwarders.
3. Fix SPF/DKIM per source; ensure at least one aligned pass.
4. Move to p=quarantine pct=25 with aspf=relaxed adkim=relaxed; monitor for 7–14 days.
5. Increase pct in steps (50, 75, 100) as failures drop below your threshold (e.g., <0.3% of legitimate traffic).
6. Consider p=reject after stability; keep sp= (subdomain policy) tuned to allow testing on subdomains.

DMARCReport’s Policy Simulator shows projected impact at each pct step and alerts if legitimate sources would newly fail.

Concrete Remediation Steps and Best Practices to Reduce False Quarantines

Eliminate the root causes so DMARC quarantine only catches real abuse.

SPF best practices

• Centralize all vendors: maintain an internal register; add or remove include mechanisms promptly.
• Keep lookups ≤10: flatten selectively or use vendor-provided “_spf” consolidations; DMARCReport flags overages and suggests flatten candidates.
• Align envelope domain: use Return-Path in your domain for ESPs that support custom MAIL FROM.

DKIM best practices

• Publish and verify selectors before go-live; use 2048-bit keys; prefer relaxed/relaxed.
• Sign stable headers and ensure From is always signed; avoid signing headers modified by Mail Transfer Agents (MTAs).
• Rotate keys biannually; DMARCReport sends rotation reminders and “stale selector” alerts.

DMARC and ARC tactics

• Use relaxed alignment unless you have a strict operational need for adkim/s=; it improves resilience through intermediaries.
• Encourage partners that forward mail to adopt ARC; monitor ARC pass rates in DMARCReport.
• Apply subdomain policies (sp=) to segregate high-risk or test senders (e.g., news.brand.com).

Mini case study (B2B SaaS)

A B2B SaaS(Software as a Service) with six outbound platforms moved from p=none to p=quarantine. DMARCReport identified that 28% of quarantine was due to DKIM misalignment from their billing provider (d=billingvendor.com). After enabling custom DKIM (d=brand.com) and setting a branded MAIL FROM, aligned pass rate rose from 71% to 96%, and support tickets about “missing invoices” dropped 37% within two weeks.

FAQs

Why did SPF say “pass” but my message was still quarantined under DMARC?

Because DMARC requires an aligned pass. If smtp.mailfrom is vendor.com but From is brand.com, SPF can pass yet be non-aligned; if DKIM also isn’t aligned and passing, DMARC applies quarantine. DMARCReport labels these specifically as “SPF alignment failures” so you can focus on fixing MAIL FROM or DKIM.

Can I rely on DKIM only and ignore SPF for DMARC compliance?

You can pass DMARC with DKIM alone if it’s aligned, but it’s risky. SPF often fails through forwarding, while DKIM can fail through content changes. Having both increases resilience, improves cyber resilience, and reduces the risk of authentication failures. DMARCReport tracks which mechanism saved each message to guide redundancy.

How do I know if the 10-lookup SPF limit is hurting me?

Run an SPF expansion or use DMARCReport’s SPF tree. If total DNS lookups >10, receivers may return permerror, which counts as SPF failure. DMARCReport highlights the offending branch and suggests flattening just that part.

Do ARC headers guarantee deliverability through mailing lists?

No. ARC helps when receivers trust the intermediary and the original auth passed, but not all receivers give ARC full weight. DMARCReport shows where ARC mitigated failures so you can quantify its benefit for your traffic.

Should I switch to strict alignment (adkim=s, aspf=s)?

Only if you control all senders and intermediaries tightly. Strict alignment increases false quarantines in complex ecosystems. DMARCReport’s simulator shows the delta in pass rates before you change modes.

Conclusion: Confirm the Cause, Fix with Confidence, and Prove Impact—Faster with DMARCReport

To definitively check whether SPF or DKIM failures are causing DMARC quarantine, triangulate RUA/RUF evidence, on-message headers, DNS/signature tests, and MTA logs—focusing on whether the failure is authentication or alignment. Then remediate methodically: authorize senders in SPF without exceeding 10 lookups, align the envelope domain, implement robust DKIM with correct selectors and relaxed canonicalization, and stage policy enforcement.

DMARCReport streamlines every step by automatically classifying failures per source, parsing headers on demand, validating SPF/DKIM/DMARC configurations, simulating policy changes, and tracking remediation impact—so you always know exactly which mechanism failed, why it failed, and how to fix it before increasing enforcement.