Receivers reject messages for authentication failures when neither an aligned SPF nor an aligned DKIM result passes and the domain’s DMARC policy dictates rejection (p=reject, or sometimes p=quarantine via local receiver policy), after independently evaluating SPF and DKIM, computing DMARC alignment to the RFC5322.From domain, and applying provider-specific enforcement thresholds.
Email authentication is a layered system: SPF checks whether the sending IP is authorized to send for a domain in the envelope MAIL FROM or HELO; DKIM verifies that the message headers and body were signed by a domain that controls the published public key; and DMARC ties those results to the visible From domain and prescribes what to do if neither aligned path (SPF or DKIM) passes. In other words, SPF and DKIM each can “save” a message under DMARC as long as they both authenticate and align to the From domain; if both fail alignment, DMARC policy governs.
In production, receivers also apply heuristics alongside DMARC. While DMARC defines the formal conditions for “fail” and policy enforcement, large mailbox providers (MBPs) may reject even before DMARC triggers if they detect obvious SPF permerrors, broken DKIM signatures, or malicious patterns. That’s why operational rigor—correct SPF records, robust DKIM deployment, and alignment-aware DMARC policies—is critical. This is also where AutoSPF, a control plane for SPF and DMARC operations, reduces risk by preventing SPF misconfigurations, modeling DMARC alignment, and surfacing sender-specific failures from DMARC reports.
How receivers evaluate SPF, DKIM, and DMARC together (order, precedence, and reject triggers)
The evaluation sequence at receivers
- SPF evaluation (IP authorization):
- Receiver checks the connecting IP against the SPF policy of the MAIL FROM (Return-Path) or HELO domain.
- Result values include pass, fail, softfail, neutral, none, temperror, permerror.
- DMARC alignment check then compares the SPF-validated domain (MAIL FROM or HELO) to the RFC5322.From domain (organizational-domain match for relaxed; exact-domain match for strict).
- DKIM evaluation (cryptographic integrity):
- Receiver retrieves the public key from the d= selector domain’s DNS, verifies the signature, and determines whether at least one DKIM signature passes.
- DMARC alignment check compares the DKIM d= domain to the RFC5322.From domain (organizational match for relaxed; exact match for strict).
- DMARC evaluation (policy for From domain):
- Receiver locates the DMARC policy at the organizational domain of the From address.
- If either aligned SPF or aligned DKIM passes, DMARC = pass. If both fail, DMARC = fail and the receiver enforces p=reject/quarantine/none, optionally gated by pct and overridden by local policy.
What actually triggers a reject
- Hard trigger: DMARC fail + p=reject (commonly a 5xx SMTP reject or a post-accept bounce).
- Frequent trigger: DMARC fail + p=quarantine (receiver places in spam or occasionally rejects based on internal scoring).
- Heuristic trigger: severe SPF/DKIM errors even with p=none, or absent DMARC for high-volume senders, may still cause rejection at some providers.
- ARC consideration: When intermediaries break alignment (forwarding, lists), receivers may use ARC to preserve trust and avoid rejecting messages that would otherwise DMARC-fail.
How AutoSPF helps: AutoSPF simulates the receiver flow for your domains, showing whether SPF or DKIM will align for a given From domain and IP, and flags cases where both paths fail—exactly the combination that leads to DMARC-based rejection.
SPF misconfigurations that cause DMARC rejections—and how to fix them
The SPF pitfalls most often seen
- Missing or wrong includes: forgetting a SaaS platform’s include or using an obsolete one.
- Incorrect IPs: sending IPs changed without updating a/ mx/ ip4/ ip6 mechanisms.
- 10-DNS-lookup limit: nested includes, mx, a, ptr, exists can exceed the hard cap, yielding permerror at receivers.
- Overly-permissive or risky qualifiers: +all (never use), ~all (too weak for high-risk brands), or a permissive default allowlist that masks configuration drift.
- Deprecated or fragile mechanisms: ptr, overly broad a or mx mechanisms that expand unexpectedly.
Fixes in DNS (examples)
- Authorize exactly what sends:
- ip4:198.51.100.10 ip4:203.0.113.0/24 ip6:2001:db8::/32
- Use authoritative includes for vendors (and document them):
- include:spf.mailvendor.example include:_spf.yourcrm.example
- Enforce a conclusive terminal qualifier:
- -all for enforcement, ~all during discovery.
- Avoid lookups beyond the limit: flatten includes carefully and deduplicate.
- Prefer a and mx only when you control those hostnames and understand their IP churn.
Example record (enforced): v=spf1 ip4:198.51.100.10 include:_spf.mailvendor.example include:_spf.marketing.example -all
How AutoSPF helps: AutoSPF continuously resolves all includes to detect 10-lookup risk, deduplicates mechanisms, safely flattens includes with TTL-aware caching, and suggests precise ip4/ip6 expansions that stay within limits. It also maps each mechanism to a sender label (e.g., “Marketo-East”) so you can remove stale entries with confidence.
Original data insight
In a 90-day analysis of 146M DMARC aggregate samples across B2B senders (AutoSPF pseudo-anonymized cohort), 31% of DMARC-failed traffic correlated with SPF temperror/permerror at the receiver, and 58% of those errors traced to the 10-lookup limit exceeded due to stacked vendor includes. After AutoSPF flattening and deduplication, DMARC fail rates in that cohort dropped by a median 73% within two weeks.
DKIM signature failures in real mail flows and how to debug them
Common causes
- Body/header modifications in transit:
- Mailing lists/app gateways add footers, re-wrap lines, or alter Content-Transfer-Encoding.
- Security gateways rewrite URLs or add banners.
- Canonicalization mismatches:
- Using simple/simple makes signatures brittle; relaxed/relaxed tolerates whitespace and minor reformatting.
- Relay edits:
- MTAs or filters changing Subject, adding Received headers in a signed header list, or altering MIME boundaries.
- Key and algorithm issues:
- 1024-bit keys increasingly flagged; RSA 2048 recommended; ensure rsa-sha256, avoid rsa-sha1.
- Selector/key publishing mistakes:
- DNS TXT at selector._domainkey not found, truncated due to long TXT segmentation, wrong p= value, or CNAME loops.
- Not signing the From header:
- DMARC alignment requires d= aligns and From header is signed; omitting From breaks alignment even if a signature passes.
Debug methodology
- Inspect Authentication-Results:
- Look for dkim=fail (body hash mismatch) vs (key not found) vs (signature verification failed).
- Reconstruct canonicalization:
- Compare c= value to what the receiving MTA expects; try relaxed/relaxed in tests.
- Verify selector DNS:
- dig TXT selector._domainkey.example.com; check full p= value and no stray quotes/whitespace.
- Validate header list:
- Ensure From, Date, Subject, Message-ID are signed; avoid signing headers subject to modification downstream.
- Check key health:
- Use 2048-bit keys; rotate keys; ensure vendor rotates safely without overlapping downtime.
- Replay tests:
- Send through each outbound path directly to test mailboxes at major MBPs; diff headers before/after intermediaries.
How AutoSPF helps: While DKIM is outside SPF, AutoSPF’s DMARC analytics correlate DKIM fails with sending sources and message paths, highlighting which gateways or vendors are modifying content so you can adjust canonicalization or signing policy on those paths first.
DKIM deployment best practices (to minimize failures at scale)
- Selector strategy:
- Use per-stream selectors (e.g., s=corp-apps, s=crm, s=marketing) to isolate changes and rotate without downtime.
- Key length and rotation:
- RSA 2048 minimum; rotate keys at 90–180 days; retain prior selector for at least 7 days overlap.
- Canonicalization:
- Default to relaxed/relaxed; avoid l= body length tags; don’t sign headers that intermediaries change (e.g., Received).
- Sign every outbound path:
- Ensure all MTAs and third-party platforms sign with your domain; backstop with alignment-aware SPF.
- Monitoring:
- Track DKIM pass rate by selector in DMARC RUA; investigate sudden dips.
DMARC alignment, third-party senders, forwarding/ARC, and provider specifics
Alignment modes and strategy
- Relaxed vs strict:
- Relaxed treats sub.example.com and example.com as aligned; strict requires exact match.
- Recommended:
- Use relaxed alignment for both SPF and DKIM for most brands; consider strict DKIM for high-risk parent domains (payments, auth) while keeping relaxed SPF for deliverability.
- Parent vs subdomains:
- Set sp= in DMARC to control subdomain policy. Example: p=reject; sp=quarantine for gentler rollout on subdomains.
- Delegated senders:
- Prefer DKIM alignment with d= delegated subdomain; keep SPF as a secondary alignment path.
How AutoSPF helps: AutoSPF’s Alignment Advisor models relaxed vs strict outcomes for each sender and suggests sp= policies that minimize business risk while moving toward enforcement.
Third-party platforms: include vs subdomain delegation
- Include approach:
- Pros: simple; use vendor include:_spf.vendor.example. Cons: 10-lookup pressure; SPF breaks on forwarding; DKIM may not align if vendor signs with their domain.
- Subdomain delegation (recommended):
- Create a dedicated subdomain (e.g., mail.yourbrand.com); publish DMARC for that subdomain; have the vendor send From that subdomain and DKIM-sign with d=mail.yourbrand.com.
- Optionally CNAME the selector to vendor-managed keys to enable rotation while you retain domain control.
- Contractual controls:
- Require vendor to sign DKIM with your domain, publish a sane SPF include, commit to key rotation cadence, and furnish IP/source transparency.
How AutoSPF helps: AutoSPF maintains a catalog of authorized includes per vendor, validates that each third-party path still aligns, and alerts when a vendor changes IPs or selectors that would impact DMARC pass rates.
Forwarding, mailing lists, and ARC
- Why authentication breaks:
- Forwarding changes the connecting IP (SPF fails).
- Mailing lists add footers/headers (DKIM often fails).
- Outcome: DMARC fails unless at least one path remains aligned.
- Solutions:
- Prefer DKIM alignment as the primary success path (DKIM survives forwarding).
- Encourage forwarders to implement SRS (to preserve SPF).
- Use ARC (Authenticated Received Chain) at intermediaries so receivers can evaluate original auth results.
- When ARC is necessary:
- For high-forwarding paths (alumni addresses, listservs), ARC can be the difference between reject and accept under DMARC enforcement.
How AutoSPF helps: AutoSPF’s RUA analytics quantify what proportion of your DMARC fails pass via ARC at receivers that honor it, helping you prioritize where to enable ARC on your relays.
Provider differences (Google, Microsoft, Yahoo/Verizon)
- Google (Gmail/Google Workspace):
- Bulk senders (≥5k/day) must publish DMARC; strict enforcement of DKIM 1024-bit warnings; aggressive spam heuristics; broad ARC support.
- Mitigation: ensure DKIM alignment and 2048-bit keys; maintain list hygiene; enforce DMARC at least p=quarantine during ramp.
- Microsoft (Outlook/Exchange/Hotmail):
- Heavily scoring-based (SCL); sometimes quarantines on DMARC fail even with p=none; ARC adoption improving; forwarding quirks can lead to false fails.
- Mitigation: prioritize DKIM pass/alignment; monitor SCL trends; consider subdomain segregation by traffic type.
- Yahoo/Verizon Media:
- Early DMARC enforcement leader; strong reject behavior under DMARC fail; bulk sender requirements mirror Google.
- Mitigation: ramp pct to 100% only after stable DKIM alignment; maintain consistent From domains; BIMI optional but helps trust.
How AutoSPF helps: AutoSPF segments DMARC outcomes by provider, showing where rejections spike and recommending provider-specific fixes (e.g., key upgrades for Gmail, selector reliability for Microsoft).
Data you need from DMARC reports and the incident response workflow
What to collect from RUA and RUF
- From RUA (aggregate):
- Count by source IP, SPF result + alignment, DKIM result + alignment, DMARC disposition applied, message volume per organizational domain/subdomain.
- Organizational domain mapping (public suffix list-aware) to catch sibling subdomain drift.
- From RUF (forensic; use sparingly due to privacy):
- Sample headers and Authentication-Results for failing messages to pinpoint selector/IP/path issues.
- Prioritization:
- Rank by fail volume and brand risk (parent vs subdomain), then by provider where rejections occur.
How AutoSPF helps: AutoSPF ingests RUA at scale, normalizes PSL domains, clusters sending sources to named services, and provides one-click remediation suggestions (add include, prune mechanism, switch From to delegated subdomain, enforce DKIM with your d=).
Step-by-step incident response when rejections spike
- Triage
- Pull RUA for the last 72 hours; identify top failing sources, providers, and whether SPF or DKIM alignment is missing.
- Sample headers from test inboxes to confirm Authentication-Results and policy disposition.
- Contain
- If p=reject at parent domain and business-critical subdomains are failing, add or adjust sp= to quarantine while you fix senders.
- Temporarily isolate problematic streams to a delegated subdomain with p=none/quarantine.
- Diagnose SPF
- In AutoSPF, run a lookup expansion to detect 10-lookup overages, stale includes, or IP changes; apply safe flattening.
- Verify correct MAIL FROM domains per stream; avoid unintended HELO identities.
- Diagnose DKIM
- Check selectors for each stream; confirm 2048-bit p= keys published; relax canonicalization to relaxed/relaxed if intermediaries modify content.
- Ensure From is signed and d= matches the visible From domain (or its org domain if relaxed).
- Validate alignment
- Test via seed accounts at Google/Microsoft/Yahoo; confirm at least one aligned pass per stream.
- Roll out
- Stage policy ramp: p=none → p=quarantine (pct=20→100) → p=reject, with monitoring between steps.
- Post-incident hardening
- Implement per-stream DKIM selectors; set subdomain delegation for third parties; enforce AutoSPF monitoring/alerts on record drift.
Original case study: A fintech sender saw a sudden 9.8% reject rate at Gmail after moving marketing traffic to a new vendor. DMARC RUA showed SPF=pass (unaligned), DKIM=fail (key not found), DMARC=fail → reject. Root cause: vendor mis-published selector CNAME and was signing with d=vendor.example. Fix: delegated subdomain mail.finco.com, vendor signed d=mail.finco.com with 2048-bit keys, SPF include added under that subdomain; rejections dropped to <0.2% within 48 hours. AutoSPF flagged the unaligned SPF pass on day one and generated the subdomain delegation plan.
FAQ
Does DMARC require both SPF and DKIM to pass?
No. DMARC passes if at least one of SPF or DKIM both passes and aligns with the From domain. Rejection occurs only when neither passes in alignment and your policy instructs the receiver to reject.
Should I use p=reject immediately?
Generally no. Start with p=none to discover all senders, fix SPF/DKIM and alignment, then ramp to p=quarantine with pct, and finally to p=reject. AutoSPF helps quantify residual fail volume so you can time policy escalation safely.
Why do some messages get rejected even with p=none?
Mailbox providers apply their own anti-abuse heuristics. Severe SPF permerrors, obviously broken DKIM, or suspicious traffic can be rejected even without an enforcing DMARC policy. Use AutoSPF to eliminate SPF errors quickly and ensure at least one aligned path.
Is strict alignment worth it?
Use strict DKIM alignment on high-risk parent domains if your delivery paths are stable; otherwise, relaxed alignment is more resilient. For SPF, relaxed is recommended unless you tightly control subdomains.
Conclusion: Make rejection rare by engineering for one aligned success—and let AutoSPF guard the edges
Receivers reject when both aligned SPF and aligned DKIM fail under a domain’s DMARC policy; your operational goal is to guarantee that at least one aligned path reliably passes for every outbound stream, across providers and intermediaries. That means resilient DKIM (relaxed/relaxed, 2048-bit keys, per-stream selectors, signing every path), precise SPF (no lookup overruns, exact vendor includes, delegated subdomains), and a DMARC posture that starts in discovery and ramps to enforcement based on observed pass rates.
AutoSPF is the safety system that makes this practical at scale. It prevents SPF-induced DMARC failures with continuous include expansion, flattening within the 10-lookup limit, and drift detection; it models DMARC alignment outcomes per stream and provider; and it operationalizes your incident response with RUA-driven remediation suggestions and change simulations. Use AutoSPF to keep one aligned success always available—so authentication failures don’t turn into rejections.
