DMARC Analyzer

TL;DR

• permerror means the SPF evaluation encountered an unrecoverable failure — typically a syntax error, lookup-count over 10, void-lookup cap violation, deprecated mechanism, multiple SPF records, or a recursive include. Defined in RFC 7208 section 2.6.7.
• temperror means the SPF evaluation encountered a transient DNS-level failure — typically a DNS timeout, SERVFAIL, or transient resolver failure. Defined in RFC 7208 section 2.6.6.
• The diagnostic difference: permerror means "fix your SPF record" (record is broken); temperror means "fix your DNS infrastructure" (record exists but resolver could not reach it).
• DMARC handling per RFC 7489 section 5.6.2: permerror is treated as SPF authentication FAILED; temperror is treated as inconclusive and the receiver MAY defer with 4xx, treat as none, or re-evaluate later.
• The seven canonical permerror causes are: (1) record not found, (2) syntax error, (3) multiple SPF records on the same name, (4) too many DNS lookups (10-lookup cap per RFC 7208 section 4.6.4), (5) void-lookup cap (2 NXDOMAIN/NODATA per the same section paragraph 3), (6) recursive include loop, (7) deprecated mechanism (spf2.0 prefix, ptr).
• The three canonical temperror causes are: (1) DNS timeout (authoritative nameserver unreachable within the resolver timeout window), (2) SERVFAIL (resolver encountered an internal error), (3) transient resolver failure (network partition, rate-limiting, DNSSEC validation intermittent failure).
• The Authentication-Results header (RFC 8601) is the canonical forensic source. Look for spf=permerror or spf=temperror followed by a parenthetical reason; the reason string names the specific cause class. View the raw message source in your mail client and inspect the Authentication-Results line.
• Receiver behavior varies. Gmail typically treats temperror as none under DMARC; Microsoft 365 may defer; Yahoo varies by campaign; ProtonMail often defers. Plan for the worst case (defer + retry-loop) when designing your DNS infrastructure for high-volume sending.

1. Overview

Sender Policy Framework (SPF), defined in RFC 7208, publishes a list of authorised sending sources for an email-sending domain. When a receiver accepts an SMTP transaction, it looks up the SPF record at the senders envelope MAIL FROM domain (per RFC 7208 section 2.3) and evaluates whether the connecting IP is authorised by that record. The evaluation produces one of seven result codes — and two of those seven are error states rather than authoritative pass/fail verdicts: permerror and temperror.

Understanding the difference between permerror and temperror — and between permerror and the unrelated fail result code — is the foundation of SPF triage. The diagnostic implications are different, the DMARC interaction is different, the receiver behavior is different, and the resolution workflow is completely different. Operators who treat the two results as interchangeable misdiagnose incidents routinely.

This page is the focused operator reference for the two error result codes. The sibling SPF pillar (help_spf_explained.php) covers the pass/fail/softfail/neutral/none result codes; the sibling SPF lookup-limit deep dive (help_spf_lookup_limit.php) covers the specific permerror cause that the 10-lookup cap produces. This page covers EVERY permerror and temperror cause, in one place, with the cause-specific resolution playbook beside each.

2. The seven SPF result codes

RFC 7208 section 2.6 defines exactly seven result codes an SPF evaluation can produce. Each has a specific semantic and a specific receiver-side processing rule:

none (RFC 7208 §2.6.1)

The receiver looked up the senders MAIL FROM domain and found no SPF record (no TXT record beginning with v=spf1). The receiver SHOULD treat this as "no SPF policy published" — SPF authentication does not apply. Under DMARC the absence of SPF is acceptable as long as DKIM passes and is aligned.

neutral (RFC 7208 §2.6.2)

The record matched and explicitly produced a neutral verdict — typically via the ?all qualifier or the ?-prefixed include / mechanism. The receiver SHOULD treat this as equivalent to none. Under DMARC, neutral is not a pass.

pass (RFC 7208 §2.6.3)

The connecting IP matches an authorised mechanism in the SPF record. SPF authentication SUCCEEDED. Under DMARC, pass + aligned MAIL-FROM domain = DMARC pass.

fail (RFC 7208 §2.6.4)

The connecting IP did NOT match any authorised mechanism, and the record terminates with -all (strict fail). SPF authentication FAILED — the sending source is not authorised. Under DMARC, fail + DKIM fail triggers the published policy (none / quarantine / reject).

softfail (RFC 7208 §2.6.5)

The connecting IP did NOT match, and the record terminates with ~all (soft fail). The receiver is encouraged to accept the mail but mark it with a low-confidence indicator. Under DMARC, softfail is treated as fail for alignment-evaluation purposes.

temperror (RFC 7208 §2.6.6)

The evaluation encountered a transient DNS-level failure (timeout, SERVFAIL, transient resolver failure). The result is inconclusive. Under DMARC section 5.6.2 the receiver SHOULD defer or treat as none — not fail. See section 5 below.

permerror (RFC 7208 §2.6.7)

The evaluation encountered an unrecoverable failure (syntax error, lookup-count cap, void- lookup cap, multiple records, deprecated mechanism, recursive include). The result is authentication FAILED. Under DMARC section 5.6.2 the receiver treats permerror as fail. See section 4 below.

3. The seven canonical permerror causes

The seven canonical permerror causes account for approximately 95% of permerror incidents in production DMARC deployments per anecdotal field reports. Operators triaging a permerror should walk this list in order — the early items are by far the most common.

3.1 Record not found

Symptom: spf=permerror (no SPF record found) in the Authentication-Results header, or spf=none in receivers that follow RFC 7208 section 2.6.1 strictly.

Root cause: The senders envelope MAIL FROM domain has no TXT record beginning with v=spf1. The receiver looked up example.com TXT and got either NXDOMAIN (the domain does not exist) or NODATA (the domain exists but has no TXT records, or has TXT records that do not begin with v=spf1).

Resolution: Publish an SPF record at the apex of the sending domain. The canonical starting point depends on the sender:

# Google Workspace
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

# Microsoft 365 / Exchange Online
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# Self-hosted mail server, single IP
example.com.  TXT  "v=spf1 ip4:198.51.100.42 -all"

3.2 Syntax error

Symptom: spf=permerror (syntax error) or spf=permerror (invalid SPF record).

Root cause: The SPF record exists but does not conform to the RFC 7208 section 12 ABNF grammar. Common syntax errors include:

• Missing v=spf1 prefix. The first 6 bytes MUST be exactly v=spf1 followed by a space or end of record. Receivers that find a TXT record without the prefix treat it as "not an SPF record" and report none — but some report permerror because a record claiming SPF semantics that lacks the prefix is malformed.
• Trailing whitespace or stray characters. Some DNS provider UIs add invisible characters when admins paste from word processors. The canonical fix is to re-publish the record from a plain-text editor.
• Mechanism with invalid argument. ip4:198.51.100.42/256 (CIDR mask out of range), ip6:not-an-ip, a: with empty argument.
• Modifier with invalid placement. redirect= appearing AFTER an all mechanism (the all terminates evaluation, so redirect= is dead code per RFC 7208 section 5.1).
• Unbalanced quotes in chunked TXT records — see the 255-byte-chunk pitfall in the sibling lookup-limit page.

Resolution: Run the record through a syntax validator (MXToolbox SPF Record Check, dmarcian SPF Surveyor, EasyDMARC SPF Checker, the DMARC Analyzer Domain Security Checker). Fix the syntax error and re-publish.

3.3 Multiple SPF records on the same name

Symptom: spf=permerror (multiple SPF records) or spf=permerror (more than one v=spf1 record).

Root cause: RFC 7208 section 3 paragraph 3 explicitly forbids more than one TXT record at the same name that begins with v=spf1. The receiver MUST treat the presence of multiple SPF records as a syntax error and return permerror. This pattern most often appears when an organisation has migrated between SPF includes (e.g., from on-prem Exchange to Microsoft 365) and the old record was never deleted, OR when two admins each published their own SPF record for the same domain without coordinating.

Resolution: Audit all TXT records at the senders apex domain with dig +short example.com TXT. Delete all SPF records EXCEPT the one with the complete / correct mechanism list, OR merge the mechanisms from multiple records into a single record. The common merge pattern: combine the include: lists, dedupe, and verify the merged record stays under the 10-lookup cap.

3.4 Too many DNS lookups (10-lookup cap)

Symptom: spf=permerror (too many DNS lookups) or spf=permerror (SPF lookup limit exceeded).

Root cause: RFC 7208 section 4.6.4 caps the number of DNS lookups an SPF evaluation may perform at 10. Each include, a, mx, ptr, exists, and the redirect= modifier consumes 1 lookup; ip4, ip6, and all cost zero. The counter is the SUM across the ENTIRE evaluation including nested includes — so a top-level record with 4 includes whose underlying records each contain 3 more includes consumes 4 + 12 = 16 lookups even though the published record only shows 4.

Resolution: See the dedicated deep dive at help_spf_lookup_limit.php. The four canonical remediations in order of preference: audit and remove unused includes; split senders across subdomains; consolidate to fewer ESPs; flatten with a monitored pipeline.

3.5 Void-lookup cap (2 NXDOMAIN / NODATA)

Symptom: spf=permerror (void lookup limit exceeded) or spf=permerror (too many void lookups).

Root cause: RFC 7208 section 4.6.4 paragraph 3 specifies a secondary cap of 2 void lookups: an SPF evaluation that encounters two or more DNS queries returning NXDOMAIN or NODATA MAY return permerror. The void-lookup cap is independent of the 10-lookup cap. The most common cause is an SPF record that references a retired third-party sender via include: — the sender shut down, the includes underlying TXT record was deleted, and now every SPF evaluation against the senders SPF record racks up a void lookup on the retired include.

Resolution: Audit every include:, a:, mx:, and exists: mechanism in the SPF record. For each, run dig +short example.com TXT for includes and dig +short example.com A AAAA MX for the others. Any mechanism whose target returns NXDOMAIN or NODATA is a void-lookup contributor; remove it from the SPF record.

3.6 Recursive include loop

Symptom: spf=permerror (recursive include loop) or spf=permerror (include loop detected).

Root cause: The SPF record contains a chain of include: mechanisms that eventually loop back on itself — example.com includes a.example.com; a.example.com includes b.example.com; b.example.com includes example.com. Most receivers detect the loop after 2-3 cycles and return permerror per RFC 7208 section 5.2 paragraph 6. This is rare in production but appears when an organisation publishes a "core SPF" record that other internal records include — and someone accidentally includes the core record back from a sub-record.

Resolution: Walk the include chain starting from the top-level record. For each include, fetch the included records SPF and recurse until you hit a non-include mechanism. If you encounter the same domain twice in the chain, that is the loop. Remove the offending include and re-publish.

3.7 Deprecated mechanism (spf2.0, ptr)

Symptom: spf=permerror (unsupported mechanism) or spf=permerror (deprecated SPF version).

Root cause: The SPF record contains a mechanism that has been deprecated in the standards process. The two canonical cases:

• spf2.0 prefix. The long-obsolete Sender ID Framework ( RFC 4406, experimental, expired) used the spf2.0 prefix. RFC 7208 section 14.1 directs receivers to ignore spf2.0 records. Some receivers report permerror if a TXT record claiming SPF semantics carries the spf2.0 prefix.
• ptr mechanism. RFC 7208 section 5.5 explicitly deprecates the ptr mechanism: "Use of this mechanism is discouraged because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers". Some receivers still evaluate it, some treat it as permerror.

Resolution: Remove the deprecated prefix or mechanism. Replace ptr with the explicit ip4: / ip6: ranges of the sending infrastructure. Republish.

4. The three canonical temperror causes

Temperror has fewer canonical causes than permerror because temperror is a transient FAILURE TO EVALUATE rather than a failure of the record content. The three causes all share one signature: the SPF record exists and is syntactically valid; the evaluation could not complete because of a DNS- infrastructure-level issue.

4.1 DNS timeout

Symptom: spf=temperror (DNS timeout) or spf=temperror (DNS query timeout).

Root cause: The receivers DNS resolver issued a query to the authoritative nameserver hosting the senders SPF record and did not receive a response within the resolvers timeout window. The window is typically 5 seconds for the initial query plus 1-2 retries; varies by receiver. Common underlying causes: the authoritative nameserver is rate-limiting the receivers resolver; the nameserver is under DDoS attack; the network path between resolver and nameserver has packet loss; the nameserver is overloaded by legitimate traffic; the nameserver is responding only on IPv4 and the resolver is querying via IPv6 (or vice versa).

Resolution: Verify reachability with dig +trace example.com TXT from multiple geographic vantage points (use a tool like DNSChecker.org or RIPE Atlas). If reachability is intermittent, migrate the SPF records DNS hosting to a higher-capacity provider (Cloudflare, AWS Route 53, Google Cloud DNS, NS1 Managed DNS). For dual-stack receivers, ensure the nameservers have both IPv4 (A) and IPv6 (AAAA) glue records.

4.2 SERVFAIL

Symptom: spf=temperror (SERVFAIL) or spf=temperror (DNS server failure).

Root cause: RFC 8499 section 4 defines SERVFAIL as a DNS response code meaning the resolver encountered a server-side error processing the query. The most common underlying causes:

• DNSSEC validation failure. The domain is DNSSEC-signed but the signature does not validate (expired RRSIG, wrong key, broken chain of trust). Validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) return SERVFAIL; non-validating resolvers return the unsigned data and SPF evaluates normally. The split-receiver-behavior makes DNSSEC SERVFAIL particularly hard to debug.
• Broken CNAME chain. The SPF TXT record is reached via a CNAME that points at a non-existent target.
• EDNS0 negotiation failure. The nameserver does not support EDNS0 or has a broken EDNS0 implementation; the resolvers EDNS0-enabled query gets dropped or returns SERVFAIL.

Resolution: If the SERVFAIL is DNSSEC-related, run dig +dnssec example.com TXT @8.8.8.8 and inspect the AD flag; if the chain is broken, fix the DNSSEC signing pipeline at the authoritative nameserver. For CNAME chain issues, inspect the chain with dig +trace example.com TXT and fix the broken hop. For EDNS0 issues, upgrade the nameserver software (BIND, NSD, PowerDNS, Knot DNS) to a version with stable EDNS0 support.

4.3 Transient resolver failure

Symptom: spf=temperror (resolver failure) or spf=temperror (transient DNS error).

Root cause: Any other transient failure category — network partition between the receiver and the nameserver, resolver-side rate- limiting kicking in (some receivers throttle aggressive resolution behavior to protect their DNS infrastructure), brief outage at the senders DNS provider, intermittent UDP packet loss causing truncated responses that the resolver could not re-fetch via TCP.

Resolution: Transient failures by definition do not have a record-side fix. Monitoring is the only reliable remediation: keep the rate of temperror under 0.1% of mail by using a redundant set of authoritative nameservers across multiple providers (anycast helps here), and ensure DNS provider SLAs match the senders mail-volume profile. For very-high-volume senders, consider second-source DNS hosting via secondary- NS configurations so a single-provider outage does not produce a temperror cascade.

5. How DMARC handles permerror vs temperror

RFC 7489 section 5.6.2 specifies how DMARC interprets each SPF result code when computing the DMARC verdict. The handling for permerror and temperror is materially different:

• permerror is treated as SPF fail. RFC 7489 section 5.6.2 paragraph 4 explicitly treats permerror as a permanent failure that contributes to the DMARC fail computation. If the DKIM verdict is also fail or DKIM is not aligned with the From: header domain, DMARC fails and the receiver applies the published policy (none / quarantine / reject).
• temperror SHOULD NOT cause DMARC fail. RFC 7489 section 5.6.2 paragraph 2 specifies that an SPF temperror SHOULD be treated as inconclusive. The receiver MAY (1) defer the message with a 4xx SMTP code asking the sender to retry later, giving the DNS resolver another chance to evaluate the SPF record on the retry; (2) treat the SPF result as none and fall back to DKIM only; or (3) accept the message and re-evaluate SPF on a subsequent delivery.

The practical operator implication: a single misconfigured SPF include can produce a global DMARC fail cascade. Every DMARC-honouring receiver simultaneously sees SPF permerror, combines it with the DKIM verdict, and applies the published policy to every message from the affected From: domain. If the published policy is p=reject, the cascade produces a rejection-at-SMTP-time outage. If the policy is p=quarantine, the cascade routes every message to spam.

By contrast, temperror typically produces only a transient deferral and re-delivery loop — operators may not even notice the temperror incident unless they actively monitor the aggregate (RUA) reports for elevated temperror rates. See help_dmarc_aggregate_reports.php for the RUA monitoring workflow.

6. Receiver behavior at major mailbox providers

The major mailbox providers implement RFC 7489 section 5.6.2 with provider-specific variations. The reference behavior is documented to the extent each provider publishes operator-facing documentation:

Gmail (Google Workspace + consumer Gmail)

permerror is treated as SPF fail per RFC 7489. temperror is typically treated as none under DMARC — Gmail rarely defers on SPF temperror alone. Aggregate reports surface both result codes in the auth_results subtree. Gmail operates extensive resolver infrastructure and is rarely the source of receiver-side temperror.

Microsoft 365 (Exchange Online + Defender)

permerror is treated as SPF fail. temperror may produce a 4xx defer ( 451 4.7.0 Temporary server error) with retry guidance, particularly under Defender for Office 365 conditional policies. Tenant administrators can inspect the Authentication-Results header in the Exchange message trace for the specific result code.

Yahoo (and AOL)

permerror is treated as SPF fail. temperror behavior varies by campaign profile — bulk senders may see temperror cascade to defer + retry; transactional senders may see temperror treated as none. Yahoo also operates the FBL (feedback loop) so spam-classifier signals interact with the SPF result code.

Apple iCloud Mail

permerror is treated as SPF fail. temperror typically defers with a 4xx SMTP code; Apple is one of the receivers most likely to defer rather than treat-as-none.

ProtonMail / Tuta / Fastmail

permerror is treated as SPF fail. temperror often defers with 4xx — these providers tend to favour deferral over none-treatment to protect users from missed mail caused by intermittent DNS infrastructure issues at the sender.

For high-volume senders, the receiver-specific variations matter operationally because deferral cascades can produce delivery-time variance even when the eventual delivery succeeds.

7. Forensic detection workflow

The forensic detection workflow combines Authentication-Results header inspection ( RFC 8601), aggregate (RUA) report analysis, and live SPF record verification.

7.1 Inspect the Authentication-Results header

View the raw message source in your mail client (Outlook File > Properties > Internet headers; Gmail three-dot menu > Show original; Apple Mail View > Message > Raw Source). Find the line beginning with Authentication-Results:. The spf= field will read spf=permerror or spf=temperror followed by a parenthetical reason:

Authentication-Results: mx.google.com;
       spf=permerror (google.com: permanent error
                      in processing during lookup of
                      sender@example.com: too many DNS lookups)
                      smtp.mailfrom=sender@example.com;
       dkim=pass (signature was verified)
                 header.d=example.com;
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT)
                  header.from=example.com

Key fields to extract: the spf= verdict (permerror vs temperror), the parenthetical reason string (names the specific cause class), the smtp.mailfrom= domain (the envelope From: that SPF was evaluated against), and the downstream dmarc= verdict.

7.2 Verify the live SPF record

Once you know the senders MAIL FROM domain, query the SPF record directly:

# Get the raw TXT record
dig +short example.com TXT

# Walk the include chain
dig +trace example.com TXT

# Count DNS lookups via SPF Surveyor / EasyDMARC / DMARC Analyzer
# Domain Security Checker

Compare the live record to what you expect — the cause-class diagnosis from section 7.1 should point at a specific record property to verify.

7.3 Cross-check with aggregate (RUA) reports

Aggregate reports per RFC 7489 section 7 surface per-record SPF result codes in the auth_results XML subtree. If you are monitoring aggregate reports via DMARC Analyzer or a similar tool, filter for spf=permerror or spf=temperror records to see the rate at which the failure mode is occurring across all receivers. A persistent permerror rate over 1% is almost always a record-side fix; a persistent temperror rate over 0.5% is almost always a DNS- infrastructure-side fix.

8. Cause-specific resolution playbook

The resolution playbook is cause-specific. Walk the decision matrix in section 9 to identify which cause class applies, then apply the corresponding remediation:

• permerror — record not found: publish an SPF record at the senders apex (see section 3.1).
• permerror — syntax error: run the record through a syntax validator, fix the malformed mechanism (see section 3.2).
• permerror — multiple SPF records: consolidate to a single TXT record at the apex (see section 3.3).
• permerror — too many lookups: audit / split / consolidate / flatten per help_spf_lookup_limit.php (see section 3.4).
• permerror — void-lookup cap: remove includes whose targets return NXDOMAIN or NODATA (see section 3.5).
• permerror — recursive include: walk the include chain, remove the offending loop link (see section 3.6).
• permerror — deprecated mechanism: remove spf2.0 or ptr; replace with ip4: / ip6: ranges (see section 3.7).
• temperror — DNS timeout: migrate to higher-capacity DNS provider; verify IPv4 + IPv6 nameserver glue (see section 4.1).
• temperror — SERVFAIL: debug DNSSEC chain / CNAME chain / EDNS0 negotiation (see section 4.2).
• temperror — transient: add redundant authoritative nameservers across providers; monitor temperror rate (see section 4.3).

9. Symptom decision matrix

Use the parenthetical reason from the Authentication-Results header to look up the cause class:

"no SPF record found" / "SPF record not present"

Cause: record not found (§3.1). Resolution: publish an SPF record at the apex domain.

"syntax error" / "invalid SPF record" / "malformed SPF"

Cause: syntax error (§3.2). Resolution: validate and fix the record.

"multiple SPF records" / "more than one v=spf1"

Cause: multiple SPF records (§3.3). Resolution: consolidate to one TXT record.

"too many DNS lookups" / "SPF lookup limit exceeded"

Cause: too many lookups (§3.4). Resolution: see lookup-limit deep dive.

"void lookup limit" / "too many void lookups"

Cause: void-lookup cap (§3.5). Resolution: remove retired includes.

"recursive include" / "include loop"

Cause: recursive include (§3.6). Resolution: walk and break the loop.

"unsupported mechanism" / "deprecated"

Cause: deprecated mechanism (§3.7). Resolution: remove spf2.0 or ptr.

"DNS timeout" / "DNS query timeout"

Cause: DNS timeout (§4.1). Resolution: higher-capacity DNS provider.

"SERVFAIL" / "DNS server failure"

Cause: SERVFAIL (§4.2). Resolution: debug DNSSEC / CNAME / EDNS0.

"resolver failure" / "transient DNS error"

Cause: transient (§4.3). Resolution: monitor + redundancy.

10. Real-world examples

Three composite incidents that illustrate the permerror and temperror failure modes in operator practice. Each describes the symptom, the investigation, and the resolution.

10.1 The post-acquisition lookup cascade

Symptom: A mid-size SaaS company completes an acquisition. Two weeks later their primary domains DMARC aggregate reports show SPF=permerror for ~40% of mail. Customer-facing transactional mail (password reset, account confirmation) starts going to spam at Gmail.

Investigation: The Authentication- Results header reads spf=permerror (too many DNS lookups). A DMARC Analyzer Domain Security Checker run against the acquired-company SPF record reports 12 effective DNS lookups (over the cap of 10). Walking the include chain reveals the company added include: for the acquirers SaaS senders (Salesforce, Marketo) to the acquired-company SPF record without removing the legacy includes the acquired company no longer uses.

Resolution: Audit the include chain; remove three legacy includes the acquired company no longer uses. Effective lookup count drops to 8. SPF=permerror clears within 4 hours of DNS propagation. Subsequent monitoring shows DMARC=pass on 99.8% of transactional mail.

10.2 The merged SPF accident

Symptom: A company migrates from Microsoft 365 to Google Workspace. After the cut- over, DMARC aggregate reports show spf=permerror for the migrated domain.

Investigation: dig +short example.com TXT returns two separate SPF records:

"v=spf1 include:spf.protection.outlook.com -all"
"v=spf1 include:_spf.google.com ~all"

The Google Workspace migration runbook added the second record without deleting the first. Per RFC 7208 section 3 paragraph 3, the presence of two SPF records is permerror.

Resolution: Delete the legacy Microsoft 365 SPF record. Merge the include if Microsoft 365 still sends any mail; otherwise publish only the Google Workspace record. Clear within DNS propagation window.

10.3 The DNSSEC SERVFAIL temperror

Symptom: An enterprise deploys DNSSEC on their primary domain. Within 24 hours, aggregate reports show 8% of mail returning spf=temperror (SERVFAIL). The receiver mix that produces the SERVFAIL is notably skewed toward validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9).

Investigation: dig +dnssec example.com TXT @8.8.8.8 returns the record without the AD flag — meaning the validating resolver could not validate the DNSSEC chain. Inspection of the DS record at the parent zone reveals the deployment runbook published a DS record with the wrong key tag — the parent DS points at a key that was not rolled in at the child.

Resolution: Fix the DS record at the registrar to point at the correct active KSK. Within the DNSSEC chain propagation window (typically 24-48 hours depending on parent-zone refresh) the temperror rate drops to baseline.

11. FAQ

What is SPF permerror?

SPF permerror is the "permanent error" result code defined in RFC 7208 section 2.6.7. It means the receiver attempted to evaluate the published SPF record and encountered an unrecoverable failure — typically a syntax error, an SPF lookup count over the RFC 7208 section 4.6.4 cap of 10 DNS queries, a void- lookup cap violation (2 NXDOMAIN/NODATA responses), the use of a deprecated mechanism (the spf2.0 prefix or the ptr mechanism in modern resolvers), multiple TXT records claiming to be SPF for the same domain, or a recursive include loop. The receiver SHOULD treat permerror as authentication FAILED — DMARC at RFC 7489 section 5.6.2 interprets it as SPF fail. The DMARC verdict then combines with DKIM: if DKIM is also fail or not aligned, DMARC fails and the receiver applies the published policy (none / quarantine / reject). The practical effect is that a single misconfigured SPF record can produce a global mail-delivery outage for the From: domain at every DMARC-honouring receiver.

What is SPF temperror?

SPF temperror is the "temporary error" result code defined in RFC 7208 section 2.6.6. It means the receiver attempted to evaluate the published SPF record but the DNS lookup encountered a transient failure — typically a DNS timeout (the authoritative nameserver did not respond within the resolvers timeout window), a SERVFAIL response from the resolver (the resolver itself encountered an error), a network reachability issue between the receiver and the authoritative nameserver, or rate-limiting by the resolver. The receiver SHOULD treat temperror as inconclusive and MAY either (1) defer message delivery with a 4xx SMTP code asking the sender to retry later, (2) treat the result as none and continue processing under DMARC, or (3) accept the message and attempt re-evaluation on a subsequent delivery. The receiver behavior varies by mailbox provider: Gmail typically treats temperror as none under DMARC; Microsoft 365 may defer; Yahoo varies by campaign.

What is the difference between SPF permerror and SPF fail?

SPF fail (the result code RFC 7208 section 2.6.4 calls "fail") is the OUTCOME of a successful SPF EVALUATION that authoritatively rejects the sending IP — the IP is not authorised by the published SPF record. SPF permerror is a result code indicating the EVALUATION ITSELF failed before reaching a conclusion — the record was unreadable, oversized, recursive, or malformed. Both result codes fail SPF authentication and both trigger DMARC fail when DKIM is also fail/not- aligned, but the diagnostic implication is different: fail means "fix your sending source" (the IP is wrong), permerror means "fix your SPF record" (the record is broken). Operators triaging a deliverability incident should always inspect the Authentication- Results header for the specific code so they know whether the problem is sender-side (fail) or record-side (permerror).

Does DMARC fail when SPF returns permerror?

Yes. RFC 7489 section 5.6.2 paragraph 4 specifies that SPF permerror is treated as authentication failure for DMARC purposes. If the DKIM verdict is also fail or DKIM is present but not aligned with the From: header domain, DMARC fails and the receiver applies the published policy (none / quarantine / reject). The most common operator surprise: a single misconfigured SPF include can produce a global DMARC fail cascade — the From: domain mail goes to spam at every DMARC- honouring receiver simultaneously. The fix is record-side (audit the SPF record for syntax / lookup-count / void-lookup / deprecated- mechanism issues), NOT sender-side (changing sending infrastructure does not help).

Does DMARC fail when SPF returns temperror?

Not necessarily. RFC 7489 section 5.6.2 paragraph 2 specifies that an SPF temperror SHOULD NOT cause DMARC fail — the receiver is encouraged to treat the result as inconclusive. The two canonical receiver behaviors are: (1) the receiver defers delivery with a 4xx SMTP code asking the sender to retry later, giving the DNS resolver another chance to evaluate the SPF record on the retry; or (2) the receiver treats the SPF result as none and falls back to DKIM only — if DKIM passes and is aligned, DMARC passes; if DKIM is also unavailable, the receiver MAY apply a none result for DMARC and continue. Receiver behavior varies: Gmail typically treats SPF temperror as none under DMARC; Microsoft 365 may defer; ProtonMail often defers. The practical effect is that intermittent DNS issues do NOT typically cause mass delivery outages, unlike permerror which always does.

How do I find out which permerror or temperror cause is happening?

The Authentication-Results header (RFC 8601) is the canonical forensic source. Inspect the raw message source (Outlook File > Properties > Internet headers; Gmail three- dot menu > Show original; Apple Mail View > Message > Raw Source) and find the line beginning with "Authentication-Results:". The spf= field will read "spf=permerror" or "spf=temperror" followed by a parenthetical reason — for example: "spf=permerror (no SPF record found)" or "spf=temperror (DNS timeout)" or "spf=permerror (too many DNS lookups)". The parenthetical text varies by receiver but typically names the specific cause class. For programmatic forensic detection, the DMARC Analyzer Email Header Analyzer parses the Authentication-Results header and surfaces the specific failure mode. Aggregate (RUA) reports from RFC 7489 section 7 also include per-record SPF result codes in the auth_results subtree, so you can see the receiver-side verdicts at scale.

Can I fix SPF temperror by changing my SPF record?

Usually not. SPF temperror is a TRANSIENT DNS-level failure — the receivers resolver could not get a response from the authoritative nameserver hosting the SPF record. The fix is on the DNS-infrastructure side, NOT the SPF- record-content side. Diagnose: (1) verify the authoritative nameservers are reachable from the public internet (use dig +trace example.com TXT from outside your network); (2) verify the nameservers respond within the receivers timeout window (typically 5 seconds); (3) check for rate-limiting at the nameserver (some providers throttle aggressive resolvers); (4) check for IPv6-only nameservers when the receiver is IPv4-only (or vice versa); (5) check for DNSSEC validation failures that produce SERVFAIL at validating resolvers. If temperror is intermittent and only affects a small fraction of mail, the issue is usually load- related at the nameserver and the resolution is to migrate to a higher-capacity DNS provider (Cloudflare, AWS Route 53, Google Cloud DNS).

What is the spf=permerror "no SPF record found" message?

A "no SPF record found" permerror means the receiver looked up the senders domain (the envelope MAIL FROM domain per RFC 7208 section 2.3, or in some implementations the HELO domain) and found no TXT record beginning with "v=spf1". Some receivers report this case as "spf=none" (meaning "no SPF policy published") rather than "spf=permerror"; the RFC 7208 specification actually requires "none" for the no-record case (see section 2.6.1). When operators see "spf=permerror (no SPF record found)", the implementation is non-strict per the RFC but the diagnostic implication is the same: publish an SPF record at the senders MAIL FROM domain. The fix is to add a TXT record at the apex of the sending domain: example "v=spf1 include:_spf.google.com ~all" for Google Workspace, "v=spf1 include:spf.protection.outlook.com -all" for Microsoft 365.

What is the difference between SERVFAIL and NXDOMAIN in SPF temperror?

SERVFAIL (RFC 8499 section 4) is a DNS response code meaning the resolver encountered a server-side error processing the query — typically a misconfiguration at the authoritative nameserver (broken DNSSEC signatures, bad CNAME chains, EDNS0 negotiation failures), a temporary connectivity issue, or a rate-limit. SERVFAIL produces SPF temperror because the receiver does not know whether the record exists or not. NXDOMAIN (RFC 8020) is a DNS response code meaning the queried name explicitly does not exist — the domain has not been registered, or it has been deleted. NXDOMAIN does NOT produce SPF temperror; per RFC 7208 section 4.4 paragraph 2 NXDOMAIN on the queried name produces SPF none (no record). NXDOMAIN on a referenced include or a/mx target counts against the 2-void-lookup cap per RFC 7208 section 4.6.4 paragraph 3 — and 2 such void responses in a single evaluation produces permerror, not temperror.

12. Related guides

• SPF explained — the canonical SPF pillar. Covers mechanism types, qualifiers, the 10-DNS-lookup limit, and the seven result codes overview.
• SPF DNS record syntax — TXT encoding, character-string boundaries, ABNF — the byte-level syntactic reference for the SPF record this permerror page diagnoses failures on. Many of the canonical permerror causes documented here are syntactic at root (RFC 7208 §3.3): a record exceeding the 255-octet character-string limit that wasn't split into multiple character-strings within a single TXT RR; a record published as two separate TXT RRs at the apex (which RFC 7208 §4.5 mandates as a permerror because the evaluator cannot decide which record to use); an internationalized domain name (IDN) in an include: or a: mechanism that was not encoded as an A-label per RFC 5891; a redirect= modifier that loops back to itself or another redirect chain; unrecognized mechanism tokens (typos like ip: instead of ip4:). Read the DNS-syntax reference to localize a permerror cause to the wire-format layer before re-publishing — a syntactically- invalid record will permerror the same way every time at every receiver until the encoding itself is fixed.
• SPF lookup limit and flattening — the RFC 7208 section 4.6.4 10-DNS-lookup limit deep dive. The most common cause of the "too many DNS lookups" permerror documented in §3.4 of this page.
• SPF mechanisms explained — the per-mechanism deep dive on every directive whose lookup-failure or RRset- absence drives the permerror / temperror result codes this page distinguishes. Permerror vs temperror discrimination is per-mechanism: include:<domain> returning NXDOMAIN is a permerror (the included record does not exist — operator action required), but the same include: returning SERVFAIL is a temperror (transient DNS failure — retry recommended); a / mx / ptr / exists:<domain> follow the same NXDOMAIN-vs-SERVFAIL split per RFC 7208 §5; the redirect=<domain> modifier produces a permerror if the redirected record itself is missing (chained NXDOMAIN bubbles up). The mechanisms reference catalogues every directive's lookup signature and points to which class of DNS-resolution outcome each mechanism's failure mode produces — read it when decoding the auth_results/spf/comment field on an aggregate-report row to map the verbose mechanism-and-lookup string back to the specific directive that caused the result.
• MX records explained — the SPF-MX-MECHANISM-RRSET-ABSENCE-VS- RRSET-FETCH-FAILURE-AS-PERMERROR-VS- TEMPERROR-ROOT-CAUSE companion to this permerror-vs-temperror diagnostic reference. Where THIS page documents the per-mechanism NXDOMAIN-vs-SERVFAIL split (permerror = operator-action-required permanent error; temperror = transient DNS-fetch-failure retry-recommended), the MX-records spoke documents the underlying MX-RR ground truth whose absence / fetch-failure / dangling-target chain produce specific permerror vs temperror sub-classes the mx mechanism evaluation surfaces: (i) MX-RRset NXDOMAIN at the mx:<domain> target — the mx:<domain> directive resolving a target that publishes no MX RRset returns NXDOMAIN per RFC 1035, producing the canonical permerror sub-class (operator must either publish the MX RRset at the target or remove the mx: directive); (ii) MX-RRset SERVFAIL during the per-MX-host A/AAAA expansion — the mx mechanism evaluation per RFC 7208 §5.4 consumes 1 lookup for the MX RRset PLUS one A/AAAA lookup per MX target; a transient SERVFAIL on any per-MX-host A/AAAA lookup produces a temperror per RFC 7208 §11.3 (retry-recommended); (iii) dangling- MX target with NXDOMAIN A/AAAA — an operator-side MX RR pointing to a hostname whose A/AAAA RRset has been deleted produces a permerror per RFC 7208 §5.4 (the operator must either restore the A/AAAA RR or refactor the MX RRset); (iv) MX-RRset publication TTL-cache propagation gap — immediately after MX RRset republication, recursive resolvers cached with the pre-publication state continue returning NXDOMAIN until the RFC 2308 negative-cache SOA-min-TTL window elapses, producing the empirical "permerror that goes away after 24-72 hours" pattern operators misdiagnose as intermittent SERVFAIL. SPF operators decoding aggregate-report spf=permerror / spf=temperror verdict rows with auth_results/spf/comment fields referencing the mx mechanism need the MX-records spoke's apex-MX byte-syntax + per-host preference- ordering semantics to identify the underlying MX-RR fault.
• include vs ip4 vs a vs mx — the four-mechanism decision view — the focused side-by-side comparison of the four IP-providing SPF mechanisms operators actually pick between when authoring an SPF record. Per-mechanism permerror / temperror risk profile differs sharply across the four: ip4:<CIDR> / ip6:<CIDR> literals cost ZERO DNS lookups so they CANNOT produce a permerror or temperror on their own at all (the only zero-error-risk mechanism family); a / a:<domain> cost 1 lookup and produce temperror on SERVFAIL or empty-RRset on a domain whose A record is unstable; mx / mx:<domain> cost 1 + N lookups (one for the MX RRset, then one A/AAAA per MX target) — the second most common 10-lookup-overrun source and the first surface where adding a new MX target silently drives the published SPF record over the limit producing a permerror at the next receiver evaluation; include:<domain> is the dominant permerror source because the included tree is opaque from the publisher's side and a downstream vendor's SPF-tree expansion lands in this domain's lookup budget without warning. Read this decision view when planning the mechanism- choice level of an SPF flattening migration prompted by a recurring permerror documented in this page — moving include:<vendor> to ip4:<cidr> literals for known-stable IP ranges is the canonical flattening pattern and is the only choice that ELIMINATES (not just defers) the permerror risk class entirely.
• SPF for Google Workspace — the PROVIDER-SPECIFIC PERMERROR-PRONE- INCLUDE-CHAIN-DEPLOYMENT companion to this permerror-vs-temperror taxonomy reference. Where THIS page documents the seven canonical permerror causes and the three canonical temperror causes in protocol- general form, the SPF-for-Google-Workspace spoke documents the WORKSPACE-DEPLOYMENT SURFACE the include:_spf.google.com permerror class most commonly fires against: (i) the canonical Workspace SPF deployment publishes a single v=spf1 include:_spf.google.com ~all record at the apex TXT — a minimal record that nonetheless consumes ~6–8 DNS lookups once the recursive Google sub-include chain (_spf.google.com → _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com) fully expands at receiver evaluation time, leaving only 2–4 lookups of headroom for any additional include: / a / mx mechanism the operator adds for third-party senders; (ii) Google periodically adds new sub-include tokens to the expansion chain as their egress IP infrastructure grows — operators who published an SPF record comfortably under the 10-lookup limit at deployment time can silently drift over the limit when Google rolls out a new netblock include without operator notification, and the next receiver evaluation produces a permerror result that cascades into DMARC alignment failure (the spoke documents the operator-side monitoring procedure for detecting Google-driven sub-include changes before they cause production permerror — dig +short _spf.google.com TXT scheduled inventory, with a delta-alert when the include-token set changes); (iii) the Workspace SMTP-Relay service and the Mail-Routing add-on add SECONDARY SPF coordination surfaces — operators using smtp-relay.gmail.com for non-Workspace egress must publish a DIFFERENT include token that is NOT include:_spf.smtp-gmail.com — the smtp-relay-service IPs are inside the main _spf.google.com expansion; the spoke documents the correct deployment pattern to avoid double-counting lookup cost, and (iv) the third-party sender common-add pattern — the Workspace-baseline single-include record leaves so little headroom that adding a second sender like SendGrid (include:sendgrid.net consumes ~3 sub-lookups), Mailchimp (include:servers.mcsv.net), or HubSpot (include:_spf.hubspotemail.net) commonly tips the published record into permerror territory, requiring the operator to either flatten one include to ip4: literals (the help_include_vs_ip4_vs_a_vs_mx sibling spoke documents the canonical decision criterion) or to publish the third-party sender under a delegated subdomain SPF record. Read the SPF-for- Google-Workspace spoke when this permerror page's diagnostic workflow narrows the permerror cause to "the include:_spf.google.com chain expanded under the receiver's lookup budget at evaluation time" — the spoke documents the Workspace-tenant-side monitoring + remediation procedure for the chain-expansion permerror class specifically.
• SPF qualifiers explained — the per-prefix semantic deep dive on the four qualifier tokens (+ = Pass, - = Fail, ~ = SoftFail, ? = Neutral) that determine receiver behaviour AFTER a permerror or temperror has been resolved by the evaluator. Permerror by itself is an SPF result code (not a qualifier verdict), so the per-receiver action on a permerror is a separate policy layer governed by the DMARC p= tag — but once the cause is fixed and the evaluator runs again, the qualifier on the matched mechanism (or the fall-through all) determines whether the message lands at Pass / Fail / SoftFail / Neutral. Read together with this permerror reference when planning a post-incident remediation: fix the permerror cause documented here, then verify the qualifier-layer policy documented there is still appropriate (e.g. a record slimmed via flattening should usually upgrade from ~all to -all once the operator is confident the slimmed record covers all production senders).
• DMARC alignment explained — identifier alignment (RFC 7489 §3.1, §6.6.2): strict vs relaxed, organisational domain, and how SPF result codes interact with DMARC alignment.
• DMARC troubleshooting — the cross-cutting failure-diagnosis reference. SPF permerror and temperror are among the canonical DMARC-fail root causes.
• DMARC record tags explained — every tag in the DMARC DNS record. Reference for the aspf= SPF alignment modifier and the fo= failure- reporting modifier.
• DMARC monitoring — operational reference for ongoing observability of SPF result codes in aggregate (RUA) reports. The recommended SPF result- code SLO is <1% permerror + <0.5% temperror.
• DMARC aggregate (RUA) reports — the daily XML stream receivers send back. Per-record SPF result codes are surfaced in the auth_results subtree.
• DMARC for Google Workspace — provider-specific deployment guide. Includes the canonical Google Workspace SPF record shape that avoids the deprecated- mechanism permerror class.
• DMARC for Microsoft 365 — provider-specific deployment guide. The Microsoft 365 SPF include is one of the most common contributors to the lookup-count permerror.
• SPF for Microsoft 365 — the SPF-LOOKUP-CASCADE-OVERFLOW-DIAGNOSTIC- TARGET-FOR-M365-TENANT-SPF-AUTHORING-WITH- SPF-PROTECTION-OUTLOOK-INCLUDE-LOOKUP-COST- PROFILE companion documenting the Microsoft-365-tenant SPF-authoring discipline this permerror-vs-temperror diagnostic page must intersect with. Where THIS page documents the seven canonical permerror cause classes (the 10-DNS-lookup limit per RFC 7208 §4.6.4, multiple SPF records, invalid macro syntax, unknown mechanisms, redirect-loop / include- loop topologies, deprecated ptr mechanism, MX-record-too-long), the SPF-for-Microsoft-365 spoke is the M365-tenant-SPECIFIC authoring reference documenting WHY the include:spf.protection.outlook.com sub-include cascade is the single most common contributor to the 10-lookup permerror class diagnosed on this page. The four-axis PERMERROR-DIAGNOSTIC-VS-M365-SPF-AUTHORING comparison exposes the structurally-distinct SPF-LOOKUP-CASCADE-OVERFLOW-DIAGNOSTIC-TARGET roles: (i) the spf.protection.outlook.com include expands to a multi-level sub-include tree — the top-level token consumes one of the 10 lookup slots, then recursively resolves include:spf-a.outlook.com / include:spf-b.outlook.com / include:spfd.protection.outlook.com sub-tokens (Microsoft has historically expanded and contracted this tree without notice), each consuming a further lookup slot — a single M365 include token routinely consumes 4-6 of the 10 available slots, leaving thin headroom for secondary ESPs (SendGrid / Mailgun / SES / Mailchimp) co-habiting with M365; (ii) M365 tenants co-habiting with on-prem Exchange hybrid topology consume additional lookup slots — the on-prem Exchange MX endpoint adds an a:mail.<org>.<tld> or explicit ip4: token to the SPF record, increasing total lookup cost; the SPF-for-M365 page documents the hybrid-Exchange SPF-authoring pattern that AVOIDS the cascade-overflow class diagnosed here; (iii) M365-tenant operators authoring SPF on a custom domain MUST decide between ~all softfail and -all hardfail qualifiers — the qualifier-selection decision interacts with the cascade-overflow class because permerror is the THIRD result class (alongside softfail and hardfail) DMARC consumers must align; (iv) permerror in an M365-tenant SPF record produces silent inbox-placement degradation at receive-side mailbox providers — Microsoft EOP, Gmail, Yahoo, and Apple all treat SPF=permerror as a non-aligning result that produces DMARC=fail despite the operator's intent — making permerror-cause-diagnosis on the M365 SPF record a load-bearing operational prerequisite for the M365-tenant DMARC deployment documented in the sibling DMARC- for-Microsoft-365 entry above.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-AS-PERMERROR-VS- TEMPERROR-AUTHENTICATION-RESCUE companion to the SPF-for-Microsoft-365 spoke immediately above. Where the SPF-for-M365 spoke documents the M365-tenant SPF record's canonical include:spf.protection. outlook.com directive and the lookup- cost-profile vulnerabilities that produce spf=permerror when the recursive- include cascade exceeds the RFC 7208 §4.6.4 10-lookup ceiling, and spf=temperror when the Microsoft authoritative-NS layer for spf.protection.outlook.com returns SERVFAIL during peak EOP outbound traffic, the DKIM-for-Microsoft-365 spoke documents the structurally-distinct AUTHENTICATION-RESCUE-PATH that produces a DKIM-aligned-pass result independent of the M365-tenant SPF record's error class at FOUR M365-tenant-specific SPF-error-class- vs-DKIM-rescue dimensions: (i) SPF permerror from spf.protection.outlook.com include-cascade overflow → M365 DKIM Exchange-Online- managed dual-selector aligned-pass rescue — when the M365 tenant's v=spf1 include:spf.protection.outlook.com -all record hits a permerror from the Microsoft outbound-IP-published sub-include cascade exceeding 10 DNS lookups (typically triggered when the tenant adds a third- party-ESP include like SendGrid or Mailchimp on top of the Microsoft outbound), the DKIM-signed message can still produce a DKIM-aligned-pass via the M365 dual-selector DKIM-signer at selector1._domainkey. <tenant> / selector2._ domainkey.<tenant> — independent of the SPF error class, the DKIM signature verifies via a single non-recursive DNS query to the Microsoft-CNAME-delegated selector; (ii) SPF permerror from M365-tenant SPF-record byte-syntax publication bug → DKIM Exchange Online Protection-managed signing-config independence — when an M365 operator publishes a syntactically-invalid SPF record at the Exchange admin center / Microsoft 365 admin portal (a stray character, two SPF records in the same zone, an unparseable mechanism token), the resulting publication-time permerror is structurally independent of the DKIM-signing-config layer — the Microsoft-managed DKIM signer continues producing valid signatures via the Set-DkimSigningConfig -Enabled $true configuration whose byte-syntax lives at the PowerShell-config layer, NOT in the customer- DNS zone; (iii) SPF temperror from transient Microsoft authoritative-NS SERVFAIL during peak EOP traffic → DKIM single-non-recursive-query independence — when Microsoft's authoritative-NS layer for spf.protection.outlook.com returns SERVFAIL during a peak EOP outbound- traffic window, the resulting spf= temperror at the receiver is independent of the DKIM-verifier path (which queries the customer-controlled-CNAME-to-Microsoft delegated selector1._domainkey.< tenant> namespace via a single non-recursive lookup, structurally distinct from the SPF-include-resolver path); (iv) Per-M365-tenant rua-aggregate cross-pillar evidence pair: spf= permerror-rate co-occurring with dkim=pass+aligned=true-rate as M365-tenant DKIM-rescue-rate KPI — the canonical M365-tenant rua-aggregate observability surface for an operator with a flaky SPF-record-vs-stable-DKIM-signer configuration is the per-tenant ratio between the SPF-error-rate (permerror + temperror) and the DKIM-aligned-pass-rate; when the ratio is high, the DKIM-signer is providing structural authentication-rescue bottom-line value for the M365-tenant DMARC-alignment KPI, and the M365 operator should prioritise SPF-record-cleanup (consolidating includes, removing redundant mechanisms, publishing a canonical apex record) WHILE the DKIM-signer continues producing the load-bearing alignment-pass result. Read the DKIM-for-Microsoft-365 spoke alongside this PermError-vs-TempError diagnostic reference when designing the M365-tenant authentication-pillar mix — the M365-tenant DKIM-signer is the structural authentication-rescue surface for the M365-tenant SPF-record error-class events this page diagnoses, and the M365-DKIM spoke documents the Exchange Online-managed dual- selector publication, the operator-driven RSA-1024-to-RSA-2048 upgrade procedure, and the Set-DkimSigningConfig / Rotate-DkimSigningConfig PowerShell cmdlets that constitute the load-bearing operator-side rescue-pillar controls.
• DMARC for SaaS senders — multi-tenant SaaS senders are the highest- incidence cohort for the multiple-SPF-records permerror class documented in §3.3.
• DMARC for transactional email — transactional ESP guides covering the SPF include patterns of Mailgun, Postmark, Amazon SES, SendGrid.
• DMARC for shared hosting — shared-hosting tenants on provider-managed SPF trees are the structurally most exposed cohort to spf=permerror by 10-DNS-lookup overflow per RFC 7208 §4.6.4. The shared-hosting spoke catalogues the per-provider include-cascade arithmetic across the FIVE non-cPanel control panels (Plesk, DirectAdmin, ISPConfig, Webmin/Virtualmin, CentOS-Web-Panel) whose tenant-authored SPF records typically layer a provider-managed include:_spf.<provider>.com token (3–5 nested lookups out of the box) with tenant-added ESP includes (Mailchimp, SendGrid, Mailgun, Constant Contact, etc.) — each ESP include consuming an additional 2–4 nested lookups. The shared-hosting spoke documents the per-panel diagnostic path when the cascade tips over the 10-lookup ceiling: where to view the currently-published SPF record on Plesk's Domains → DNS-Settings page, on DirectAdmin's DNS-management screen, on ISPConfig's Sites → Domain → DNS tab, on Webmin/Virtualmin's BIND-zone editor, on CWP's DNS-zone-editor plugin; the provider-side escalation procedure when the provider-managed include itself already exceeds 8-9 lookups (forcing tenant migration to a flattened custom-include); and the commercial-honesty caveat that the permerror surfaces in the receiver-side DMARC aggregate stream as auth_results/spf/result=permerror regardless of which control panel authored the record. Read the shared-hosting spoke when diagnosing permerror rows tied to provider-managed SPF deployments outside the cPanel cohort, when composing per-tenant permerror-remediation runbooks across heterogeneous control-panel customer-domain footprints, or when attributing temperror rows to provider-side recursive-resolver SERVFAIL on the cached include:_spf.<provider>.com leaf during provider DNS-infrastructure outages.
• DNS propagation explained — how DNS record changes propagate through caching resolvers. After fixing a permerror cause, propagation determines how quickly receivers re-evaluate.
• Email authentication ecosystem (SPF, DKIM, DMARC, ARC, BIMI) — the cluster-intro pillar tying all four- layer authentication standards together.
• Email authentication glossary — defines permerror, temperror, NXDOMAIN, NODATA, SERVFAIL, Authentication-Results, and the rest of the protocol vocabulary.
• DMARC reporting pipeline — the PER-RUA-AGGREGATE-XML-EVIDENCE- STREAM-AS-LOAD-BEARING-EXTERNAL- DIAGNOSTIC-EVIDENCE-SOURCE-FOR-EVERY- SPF-PERMERROR-AND-TEMPERROR-DIAGNOSIS- WORKFLOW-DOCUMENTED-HERE companion to THIS SPF-error-class reference. Where THIS page documents the seven canonical SPF permerror cause classes (10-DNS-lookup-budget overrun, recursive-include cascade, malformed mechanism token, deprecated ptr mechanism, invalid macro expansion, multiple SPF records on same domain, mid-record redirect= circular loop) and the temperror class (transient DNS resolution failure, authoritative-nameserver SERVFAIL, network-partition-induced query timeout), the DMARC-reporting-pipeline spoke is the EXTERNAL TELEMETRY infrastructure documenting how the rua-aggregate-XML stream produced by receivers feeds per-error-class diagnostic evidence at FOUR SPF-error- class-to-rua-evidence dimensions: (i) per-source-IP spf=permerror rua-row counts — the reporting- pipeline spoke documents how the rua- aggregate-XML per-row auth_results.spf.result field surfaces per-source-IP permerror counts that operators correlate against the per-source-IP SPF publication diagnostic THIS page documents; (ii) per-source-IP spf=temperror rua-row counts — the reporting- pipeline spoke documents how the rua-aggregate-XML per-row stream surfaces per-source-IP temperror counts that operators correlate against the per-source-IP transient DNS diagnostic THIS page documents, distinguishing transient infrastructure failure from per-receiver-evaluator divergence; (iii) per-d=-domain SPF- evaluation-result decomposition — the reporting-pipeline spoke documents how the rua-aggregate-XML auth_results.spf.domain field reveals the per-d=-domain SPF- evaluation result the operator correlates against the per-d=-domain publication discipline THIS page's permerror-cause-class catalogue references; (iv) per-rua- reporter permerror / temperror-incidence divergence — the reporting- pipeline spoke documents how the rua-aggregate-XML per-reporter permerror / temperror-incidence divergence (Google reports more permerror due to strict RFC 7208 §4.6.4 10-DNS-lookup- budget enforcement, Microsoft reports more temperror due to per-tenant transient DNS-resolver timeout) is the multi-receiver-side divergence evidence THIS page's per-receiver-divergence diagnostic depends on. Read THIS page when DIAGNOSING a per-message SPF permerror or temperror; read the DMARC-reporting-pipeline spoke when ARCHITECTING the rua-stream infrastructure the SPF-error-class diagnostic playbook THIS page documents draws on.
• MTA-STS policy file syntax — the MTA-STS-POLICY-FETCH-FAILURE- MODE-CLASSES-AS-LOAD-BEARING- TRANSPORT-LAYER-ERROR-CLASS- COUNTERPART-TO-SPF-PERMERROR-AND- TEMPERROR-MESSAGE-LAYER-ERROR-CLASSES companion to THIS SPF permerror / temperror diagnostic reference. Where THIS page documents the RFC 7208 §2.6 SPF result-classes (permerror — permanent publisher-side misconfiguration; temperror — transient receiver-side or resolver-side DNS-lookup failure) and their seven canonical root-cause classes (the 10-DNS-lookup budget overflow, the multi-record cardinality violation, the malformed mechanism-token, the unresolvable include-cascade target, the void-lookup limit exceedance, the per-receiver resolver-side timeout, the per-tenant transient DNS-resolver outage), the MTA-STS-policy-syntax spoke is the TRANSPORT-LAYER ERROR-CLASS-COUNTERPART REFERENCE documenting the receiver-side per- policy-fetch failure-mode taxonomy whose every per-failure-class is the TRANSPORT-LAYER sibling to the SPF MESSAGE-LAYER permerror / temperror error-class taxonomy THIS page catalogues at FOUR cross-layer per-receiver-failure-class-coupling dimensions: (i) per-receiver MTA-STS policy-fetch hard-fail (HTTPS 4xx, malformed policy-file byte-syntax, policy-id mismatch between _mta-sts TXT and policy-host id:) as the permerror-analogue transport-layer failure-class — the MTA-STS-policy-syntax spoke documents the publisher-side per- publication misconfiguration root- causes (HTTPS-fetch 404 / 4xx rejection, malformed mode: / mx: / max_age: key-value grammar, per-policy-id-stale-TXT- record divergence, missing version: first-line) whose receiver-side classification as "permanent publisher-side misconfiguration" parallels the SPF permerror root- cause class THIS page documents; (ii) per-receiver MTA-STS HTTPS-fetch transient-fail (TCP connect failure, TLS handshake failure, HTTPS 5xx response, per-receiver DNS-resolver timeout on _mta-sts TXT lookup) as the temperror- analogue transport-layer failure-class — the MTA-STS-policy-syntax spoke documents the receiver-side transient-failure root-causes (per-receiver HTTPS-fetch transport-timeout, per-receiver DNS-resolver _mta-sts TXT-lookup TempFail, per-policy-host TLS- cert-chain validation transient- failure) whose receiver-side classification as "transient receiver-side failure" parallels the SPF temperror root-cause class THIS page documents; (iii) per- publisher _mta-sts TXT id: vs policy-host id: mismatch as the transport-layer per-publisher misconfiguration root-cause class parallel to SPF's per- publisher mechanism-misconfiguration root-cause classes — the MTA-STS-policy-syntax spoke documents the per-publisher per-policy-id rollover discipline whose policy-id-mismatch is the transport-layer equivalent of the SPF per-publisher multi- record cardinality violation or malformed-mechanism-token per-publication misconfiguration THIS page's permerror root- cause catalogue documents; (iv) per-publisher mode: none / mode: testing / mode: enforce graceful-degradation-on-fetch- failure publication discipline as the transport-layer graceful-degradation analogue to SPF's ?all / ~all / -all tail-mechanism publication discipline — the MTA-STS-policy-syntax spoke documents the per-mode publisher-side downgrade- publication discipline (mode: none = no-enforcement publication, mode: testing = observe-only enforcement- rehearsal publication, mode: enforce = full-enforcement publication) whose receiver- side per-mode evaluation outcome parallels the SPF per-qualifier graceful- degradation outcome receivers evaluate against the published mechanism-list THIS page's qualifier- section references — both publication disciplines document the per-publisher progressive-rollout-and- downgrade-publication discipline whose every per- receiver evaluation outcome is conditioned by the published per-mode or per-qualifier graceful- degradation primitive. Read THIS page when DIAGNOSING a per-message SPF permerror or temperror; read the MTA-STS-policy- syntax spoke when DIAGNOSING the cross-layer transport-layer MTA-STS policy-fetch failure-class counterpart on the same publisher-and- receiver pair.
• SPF forwarding issues — the PER-FORWARDER-ENVELOPE-REWRITE-AS- PERMERROR-AND-TEMPERROR-DIAGNOSTIC- CONTEXT-CLASS companion to this SPF- error-class taxonomy reference. Where THIS page documents the RFC 7208 §8.6 / §8.7 permerror (10-DNS-lookup overflow, multi- TXT-record collision, malformed mechanism byte-grammar, void-lookup overflow) and temperror (DNS resolver timeout, TCP- truncation, transient SERVFAIL) per-class receiver-side outcome taxonomy, the SPF- forwarding-issues spoke is the FORWARDING-CONTEXT diagnostic-class catalogue documenting how the per- forwarder envelope-MAIL-FROM rewrite converts the SPF error-class outcome into per-forwarding-hop root-cause attribution evidence at FOUR per-forwarding-hop-error- class diagnostic-coupling dimensions: (i) per-mailing-list-expander envelope- MAIL-FROM rewrite to the list's bounce- handler domain produces SPF evaluation against the LIST's SPF record (not the originator's) — permerror surfacing here attributes to the LIST's include cascade budget exhaustion, NOT the originator's — the canonical per-mailing-list permerror attribution pivot the SPF-forwarding-issues spoke catalogues that the per-error-class diagnosis taxonomy on THIS page consumes; (ii) per-account-forwarding envelope-MAIL-FROM rewrite to the forwarding-account domain pivots SPF evaluation to the forwarding-account's SPF record — temperror surfacing here attributes to the FORWARDING-ACCOUNT- host's resolver topology, NOT the originator's — the canonical per- account-forwarder temperror attribution pivot whose receiver-side root-cause attribution requires the per-forwarder envelope-rewrite signature the SPF- forwarding-issues spoke catalogues, the per-error-class taxonomy on THIS page consumes; (iii) per-SRS-rewriter envelope-MAIL-FROM rescue restores SPF- pass at the forwarder's IP topology but does NOT rescue permerror originating in the ORIGINAL publisher's include cascade — operator-side permerror diagnosis must distinguish forwarder-side rescue from publisher-side overflow — the canonical SRS-versus-publisher-include- cascade permerror attribution differentiator the SPF-forwarding-issues spoke catalogues, the per-error-class diagnosis on THIS page consumes; (iv) per-forwarder ARC-chain Authentication-Results-header capture preserves the ORIGINATING-hop SPF error- class outcome through subsequent forwarding hops — receiver-side per- forwarded-message error-class attribution depends on ARC-chain inspection rather than direct SPF re-evaluation — the SPF-forwarding-issues spoke catalogues ARC-sealing as the receiver- side cross-hop SPF-error-class-evidence preservation primitive whose per-hop permerror/temperror attribution the per- error-class taxonomy on THIS page consumes through ARC-chain-header inspection rather than direct receiver- side SPF re-evaluation. Read the SPF- forwarding-issues spoke alongside this SPF-permerror-vs-temperror reference when triaging per-forwarded-message SPF-error-class outcomes whose root-cause attribution depends on the per-forwarder envelope-rewrite context class.
• Why SPF alone is insufficient — the SPF-PERMERROR-AND-TEMPERROR-AS-LOAD- BEARING-CANONICAL-EVIDENCE-FOR-SPF-PROTOCOL- LEVEL-STRUCTURAL-INSUFFICIENCY-TAXONOMY companion to this SPF-error-class catalogue. Where THIS page documents the RFC 7208 §4.6.4 permanent-vs-transient SPF-evaluation failure-class publication-and-detection discipline (the seven permerror cause-classes — record-syntax errors, 10-DNS-lookup limit overflow, void-lookup overflow, multi-record SPF publication, malformed mechanism, invalid IP-syntax in ip4: / ip6:, circular include: references — and the four temperror cause-classes — per- receiver DNS-resolution timeout, intermittent DNS failure, SPF-record fetch network error, per-resolver overload), the why-spf-alone- is-insufficient spoke is the STRUCTURALLY-PARALLEL canonical reference documenting how the per-publisher per-domain SPF-error-class emergence catalogued THIS page IS the load-bearing per-publisher per-message evidence of SPF's protocol-level structural insufficiency at four SPF-error- class-as-insufficiency-evidence coupling dimensions: (i) SPF permerror as load-bearing per-publisher per-domain publication-discipline-failure-class producing per-message SPF-aligned-pass-path- elimination — every permerror cause- class THIS page catalogues (RFC 7208 §4.6.4 failure-class taxonomy) produces per-message SPF-aligned-pass-elimination across EVERY per-receiver per-message evaluation; the why-spf-alone-is-insufficient spoke documents this protocol-level failure-class emergence as the canonical per-publisher per-domain SPF-insufficiency-evidence catalogue every per-publisher DMARC-deployment-architect must understand BEFORE assuming SPF alone protects per-publisher per-domain author- domain identity; (ii) SPF temperror as load-bearing per-receiver-fault transient per-message SPF-aligned-pass-rate volatility- source — every temperror cause- class THIS page catalogues (per-receiver DNS- resolution-infrastructure-failure boundary) produces per-publisher per-receiver per-day per-message SPF-aligned-pass-rate-volatility the receiver-side SPF-evaluator CANNOT deterministically resolve; the why-spf-alone- is-insufficient spoke documents this per-receiver-volatility-source as load- bearing evidence of SPF's per-receiver per- DNS-resolution-infrastructure deterministic- evaluation impossibility — the cross- receiver per-publisher per-day SPF-aligned- pass-rate-distribution-instability is canonical per-publisher SPF-insufficiency- evidence; (iii) SPF-permerror-and- temperror-class observability surface as per-publisher per-domain canonical aggregate- XML evidence stream — the per- publisher per-message SPF-error-class verdict THIS page catalogues materialises at per-receiver per-day per-source-IP per- SPF-result-class row-granularity in the rua aggregate-XML evidence stream the receiver-side SPF-evaluator emits per RFC 7489 §7.2 (the <auth_results> <spf> element's <result> child captures permerror / temperror / fail / softfail / neutral / pass / none verdict-class verbatim); the why-spf-alone-is-insufficient spoke documents this aggregate-XML observable- emergence as load-bearing per-publisher per- domain SPF-insufficiency-evidence-stream every per-publisher DMARC-monitoring-architect must watch; (iv) SPF-error-class-emergence as load-bearing per-publisher per-message upstream-trigger for DKIM-aligned-pass-path- reliance and per-publisher complete-message- layer-authentication-publication-discipline- stack completion — every per-message spf=permerror / spf=temperror verdict THIS page catalogues structurally collapses the per-publisher per-message SPF-aligned-pass evaluation path; the per-publisher per- message DMARC-aligned-pass-via-DKIM-only- path then BECOMES load-bearing — meaning the per-publisher per-selector DKIM- cryptographic-foundation-publication- discipline + per-forwarder-class ARC-chain- preservation-publication-discipline + per- publisher per-domain DMARC-disjunction- evaluation-publication composes into the complete-message-layer-authentication- publication-discipline-stack the why-spf- alone-is-insufficient spoke documents as per-publisher per-domain SPF-only- insufficiency-remedy. Read the why-spf- alone-is-insufficient spoke ALONGSIDE this SPF-permerror-vs-temperror reference whenever the per-publisher per-domain SPF-error-class catalogue THIS page documents needs a protocol-level SPF-structural-insufficiency framing for the cross-mechanism remediation decision.
• DKIM failures explained — the RFC 6376 §3.9 DKIM-VERDICT-CLASS- TAXONOMY-AS-CROSS-MECHANISM-MESSAGE-LAYER- AUTHENTICATION-EVALUATION-FAILURE-CLASS- CATALOGUE-PARALLEL companion to this SPF-permerror-vs-temperror reference. Where THIS page documents the SPF-error-class taxonomy (per-publisher-fault permerror via SPF-record-syntax-error + 10-DNS-lookup- limit-overflow + void-lookup-overflow + multi-record-SPF-publication, vs per- receiver-fault temperror via per-receiver DNS-resolution-timeout + intermittent-DNS- failure + SPF-record-fetch-network-error), the DKIM-failures-explained spoke is the cross-mechanism PARALLEL message-layer- authentication-evaluation-failure-class catalogue documenting the four receiver- side DKIM verdict-class keywords whose per- message verdict surface structurally parallels THIS page's SPF-error-class taxonomy at four cross-mechanism message- layer-authentication-evaluation-failure- class parallel coupling dimensions: (i) DKIM-permerror parallels SPF-permerror as load-bearing per-publisher per-domain publisher-fault permanent message-layer-authentication-evaluation- failure-class — DKIM-permerror is the per-publisher per-selector publication- discipline-failure-class catalogue (DKIM- Signature header syntactically invalid + public-key TXT record cannot be retrieved + v=-tag missing-or-unsupported + multi- signature precedence ambiguity) parallel to the per-publisher per-domain SPF- permerror catalogue THIS page documents at the per-message per-publisher message- layer-authentication-evaluation-failure- class boundary; (ii) DKIM-temperror parallels SPF-temperror as per-receiver- fault transient message-layer- authentication-evaluation-failure-class — DKIM-temperror is the per-receiver-fault transient public-key-TXT-record retrieval- failure-class catalogue (per-receiver DNS- resolver public-key TXT-record retrieval- timeout + intermittent DNS-failure during per-message DKIM-Signature verification) parallel to the per-receiver-fault SPF- temperror catalogue THIS page documents at the per-message per-receiver message-layer- authentication-evaluation-failure-class boundary; (iii) cross-mechanism message-layer-authentication-evaluation- failure-class composition as load-bearing per-publisher per-domain DMARC-aligned- pass-evaluation-failure upstream attribution- pipeline primitive — the per- message DMARC-aligned-pass-evaluation algorithm requires per-message SPF- aligned-pass OR per-message DKIM-aligned- pass; per-message SPF-error-class emergence eliminates the SPF-aligned-pass path forcing the load-bearing reliance on per-message DKIM-aligned-pass — but if the per-message DKIM-verdict-class is ALSO in the failure-class catalogue THIS DKIM-failures spoke documents (bodyhash- mismatch / signature-mismatch / permerror / temperror), the per-message DMARC- aligned-pass-evaluation algorithm has NO path to a per-message DMARC-aligned-pass verdict and the per-publisher per-domain per-message DMARC-aligned-pass-rate decays; (iv) cross-mechanism per- message-class failure-class observability surface as per-publisher per-domain operations-team cross-mechanism per- message-class evidence-capture composition primitive — the per-publisher per-domain aggregate-XML auth_results body publishes both the SPF-error-class per-message verdict (THIS page's catalogue) AND the DKIM-error-class per- message verdict (the DKIM-failures spoke catalogue) for every per-message-class evidence row; per-publisher per-domain cross-mechanism per-message-class evidence-capture composition is then the load-bearing per-publisher per-domain cross-mechanism per-message-class evidence-row attribution primitive every per-publisher per-domain per-message DMARC-aligned-pass-rate root-cause- attribution decision consumes. Read the DKIM-failures-explained spoke ALONGSIDE this SPF-permerror-vs-temperror reference whenever an operator triaging a per- publisher per-domain DMARC-aligned-pass- rate regression needs the cross-mechanism per-message-class failure-class catalogue whose four DKIM verdict-class keywords structurally parallel THIS page's SPF- error-class taxonomy at the cross-mechanism message-layer-authentication-evaluation- failure-class boundary.
• Reverse DNS / PTR records for mail servers — the SPF-PERMERROR-AND-TEMPERROR- RESULT-CLASS-TAXONOMY-AS-LOAD-BEARING- DOWNSTREAM-CONSUMER-OF-IN-ADDR.ARPA- REVERSE-ZONE-PTR-RR-RESOLUTION-FAILURE companion to this SPF-permerror-vs- temperror result-class taxonomy. Where THIS page documents the RFC 7208 §2.6 result-class taxonomy (the seven RFC 8601 §2.7.2 result-class verdicts spf=none / spf=neutral / spf=pass / spf=fail / spf=softfail / spf=temperror / spf=permerror, the permerror-cause taxonomy, the temperror-cause taxonomy), the reverse-DNS-PTR spoke documents the per-source-IP IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-RR resolution- failure modes whose RFC 1035 §3.5 + RFC 7766 PTR-RR lookup outcomes directly produce permerror and temperror verdicts THIS taxonomy catalogues at FOUR per-PTR-RR- resolution-failure-mode-to-SPF- result-class coupling dimensions: (i) per-source-IP-IN- ADDR.ARPA-NXDOMAIN-PTR-RR-resolution- as-direct-RFC-7208-§5.5-ptr-mechanism- spf=permerror-producer — the SPF ptr mechanism evaluates the per-source-IP reverse- zone PTR-RR; any per-source-IP reverse-zone NXDOMAIN response (no PTR-RR published at the IN-ADDR.ARPA / IP6.ARPA owner-name) produces the spf=permerror verdict THIS page's permerror-cause taxonomy catalogues — operator-side per- source-IP PTR-RR publication discipline THIS reverse-DNS spoke documents is the load-bearing prerequisite for avoiding this permerror-class outcome; (ii) per-source-IP-reverse-zone- SERVFAIL-or-timeout-as-direct-RFC- 7208-§5.5-ptr-mechanism-spf=temperror- producer — per-source-IP IN-ADDR.ARPA / IP6.ARPA reverse-zone nameserver SERVFAIL responses, recursive-resolver timeout, or RFC 7766 TCP-fallback failure during PTR- RR resolution all produce the spf=temperror verdict THIS page's temperror-cause taxonomy catalogues — operator-side per- source-IP reverse-zone nameserver availability + RFC 7766 TCP-fallback discipline THIS reverse-DNS spoke documents is the load-bearing prerequisite for avoiding this temperror-class outcome; (iii) per-source-IP-FCrDNS- forward-confirmation-failure-as- direct-RFC-7208-§5.5-ptr-mechanism- spf=fail-or-spf=neutral-producer — even when per-source-IP reverse- zone PTR-RR resolution succeeds, the FCrDNS forward-confirmation step (resolving the PTR-target hostname's forward A/AAAA RRs and verifying they include the original per-source- IP) may fail when the forward-zone hostname-suffix doesn't match the publisher-claimed domain or the forward A/AAAA RRs are absent — this failure mode produces spf=fail / spf=neutral from the ptr mechanism THIS page's result-class taxonomy documents, even though the underlying mechanism evaluation completed without permerror or temperror; (iv) per-source-IP-reverse-zone- PTR-RR-resolution-as-load-bearing- UPSTREAM-evidence-input-into-RFC-7208- §6.2-void-lookup-spf=permerror- accounting — even when the SPF policy doesn't include the ptr mechanism explicitly, per-source-IP reverse-zone PTR-RR resolution failures during HELO- identity evaluation (RFC 7208 §2.3) or during macro-expansion evaluation (RFC 7208 §7) count against the RFC 7208 §6.2 void-lookup ceiling whose breach produces spf=permerror — per- source-IP PTR-RR publication discipline THIS reverse-DNS spoke documents is therefore a load-bearing upstream-prerequisite for SPF- permerror-avoidance ACROSS the catalogue, NOT only the explicit ptr-mechanism evaluation pathway. Read the reverse-DNS-PTR spoke alongside THIS page when the operator asks "which per-source-IP reverse-zone PTR-RR resolution- failure modes directly produce SPF- permerror or SPF-temperror verdicts at the receiver" — the answer is FOUR-LAYERED: THIS page documents the SPF-result-class taxonomy, the reverse-DNS-PTR spoke documents the per-source-IP reverse-zone PTR-RR resolution-failure modes whose outcomes directly produce the permerror and temperror verdicts THIS taxonomy catalogues.
• Email Header Analyzer — paste a raw email header and the tool surfaces the Authentication-Results verdict, including the specific SPF result code and parenthetical reason. The forensic detection workflow from §7 in tool form.
• Domain Security Checker — verifies your own domains SPF record live from DNS, counts lookups, validates syntax, and reports any of the seven permerror cause classes before they affect production deliverability.
• DNS Record Generator — generates publish-ready SPF records for your domain. Built with the permerror-avoidance patterns documented on this page.
• DMARC myths and misconceptions debunked — the canonical educational myth-busting reference whose 18 named DMARC misconceptions are empirically debunked against the per-message SPF result-class taxonomy and RFC 7208 §2.6 SPF- evaluation-outcomes THIS page documents at four SPF-result- class-to-DMARC-myth resolution dimensions: (i) the RFC 7208 §2.6.7 spf=permerror + RFC 7489 §6.6.2-implicit-DMARC- fail downstream coupling is the canonical empirical counterexample to the "permerror is just a warning, not a real failure" misconception — the myth catalogue debunks the false-perception of permerror as a soft signal; per RFC 7489 §6.6.2 every spf=permerror row contributes to the per-message DMARC-fail verdict whenever DKIM is not aligned-pass, and the downstream policy_evaluated.disposition emits the per-publisher p=-tag terminal- state action; (ii) the RFC 7208 §2.6.2 spf=none vs §2.6.3 spf=neutral per-result-class semantic distinction is the canonical empirical counterexample to the "spf=neutral and spf=none are the same thing" misconception — the myth catalogue debunks the receiver-side reputation- treatment conflation; spf=none means no SPF record published at the envelope MAIL-FROM domain (DMARC §4.1 will skip SPF-aligned-pass evaluation entirely), spf=neutral means a record is published with the ?-qualifier applying to the per-source-IP path (the publisher explicitly declines to assert pass-or-fail and receivers MUST treat it as spf-not-pass for DMARC-aligned- pass evaluation, NOT as equivalent to spf=none); (iii) the RFC 7208 §5 / §11.4 spf=temperror per-receiver retry-discretion discipline is the canonical empirical counterexample to the "receivers always retry temperror until SPF resolves" misconception — the myth catalogue debunks the false-expectation of deterministic temperror retry behaviour; per-receiver retry policy (Gmail batches per-message-queue retry over 4-24h, M365 emits an immediate-soft-fail without retry, Yahoo retries once at the message-queue front, Fastmail retries over a 1-2h window) means temperror outcomes resolve into receiver-side spf=temperror-promoted-to-fail verdicts at different per- receiver per-source-IP cadences; and (iv) the RFC 7208 §1.1.3 envelope MAIL FROM vs RFC 5322 From- header identifier-domain distinction is the canonical empirical counterexample to the "spf=pass means the message is authenticated as from the From-header domain" alignment-fallacy misconception — the myth catalogue explicitly debunks the SPF-pass-as-DMARC-pass fallacy; SPF evaluates only the envelope MAIL FROM identifier (the HELO-and- MAIL FROM identifier domain) per RFC 7208 §1.1.3, and the per-message DMARC-aligned- SPF-pass verdict requires the envelope MAIL FROM organisational domain to organisationally-align with the RFC 5322 From-header per RFC 7489 §3.1.2 — the canonical spf=pass-with- aligned=false defect-class the myth catalogue explicitly names. Read the myths-and-misconceptions spoke ALONGSIDE this SPF permerror-vs-temperror result-class reference whenever the publisher scopes a per-publisher operator-education curriculum on SPF result- class semantics — the per-result-class taxonomy THIS page documents IS the empirical evidence-chain that grounds every SPF- result-class-semantics- subset entry in the myth catalogue against receiver-side Authentication-Results reality.
• DMARC forensic reports (RUF / AFRF) — the PER-AFRF-ROW-SPF-RESULT-CODE-AS- FORENSIC-EVIDENCE-DECODE companion to this SPF permerror-vs-temperror result-code catalogue reference. Where THIS page documents the RFC 7208 §4.6 result-code catalogue (the permerror publisher-side-defect / over-the-ten-DNS- lookup-cap class vs the temperror receiver-side-resolver-transient-failure class, the per-result-code root-cause taxonomy at the per-publisher SPF-publication AND per-receiver-resolver evaluation boundary), the DMARC-forensic-reports spoke is the per-message AFRF / IODEF evidence- stream reference documenting the RFC 6591 forensic-report channel whose per-message message/rfc822 embedded-part plus Authentication-Results: + Received-SPF: AFRF-header byte-preservation is the FORENSIC-GRAIN evidence the operator's incident-response team uses to attribute a per-message spf=permerror or spf=temperror verdict to the specific per-publisher OR per-receiver root cause. The PER-AFRF-ROW-SPF-RESULT-CODE- VS-PER-MESSAGE-FAILURE-ATTRIBUTION cross- reference establishes FOUR structurally- distinct SPF-result-code-vs-AFRF-evidence- row dimensions: (i) per-message spf=permerror publisher-side- SPF-publication-defect AFRF evidence — the per-AFRF Received-SPF: AFRF-header field per-RFC 7208 §4.6 result- code byte-fidelity plus the per-AFRF Identity: AFRF-header field identifies the failing per-publisher envelope-from domain whose SPF record contains the publisher-side syntactic- defect — a per-AFRF stream attributing a per-message spf= permerror to a specific publisher- side defect (a missing colon-after- v=spf1 token, a non-RFC-7208- permitted mechanism qualifier, a malformed include: macro expansion) lets the SIRT or per-publisher per-portfolio- member SPF-publication owner cite the per-AFRF-byte-preserved evidence when coordinating an emergency SPF-record-fix deployment across the per-publisher DNS- publication pipeline; (ii) per- message spf=permerror RFC 7208 §4.6.4 ten-DNS-lookup-cap overflow AFRF evidence — the per-AFRF Received- SPF: byte-preservation plus the per- AFRF embedded message/rfc822 envelope identifies the per-publisher envelope-from domain whose include: cascade overflows the per-RFC 7208 §4.6.4 ten-DNS-lookup budget — a per- AFRF stream attributing per-message spf=permerror to per-publisher ten-DNS-lookup-cap overflow lets the SIRT identify the specific per-publisher-stacked include: cascade exceeding the budget and coordinate the per-publisher per-stacked-ESP include:-cascade flattening or ip4:-literal-CIDR substitution remediation campaign; (iii) per-message spf=temperror receiver-side-resolver-transient-DNS-failure AFRF evidence — the per-AFRF Received- SPF: byte-preservation plus the per- AFRF Source-IP: AFRF-header field identifies the receiver-resolver- organization whose per-receiver-resolver DNS-cache experienced a per-include-zone authoritative-nameserver SERVFAIL or per- zone-transfer-window-bounded transient failure — a per-AFRF stream attributing per-message spf=temperror to a specific per-receiver-resolver- organization cohort lets the SIRT differentiate per-publisher per-include- zone authoritative-nameserver instability from per-receiver-resolver-organization DNS-cache transient pathology and coordinate the per-include-zone DNS-publication- availability remediation; (iv) per- message spf=permerror-OR- spf=temperror per-DMARC-rua- aggregate-row vs per-DMARC-ruf-AFRF-row granularity divergence AFRF evidence — the per-AFRF embedded message/rfc822 part byte-preservation supplements the per- rua aggregate Stage 2 per-source-IP per- disposition row-aggregation with per- message envelope-from / DKIM-Signature / Authentication-Results: byte- fidelity — the per-AFRF per- message-granularity attribution is the ONLY forensic evidence channel that differentiates a per-publisher per-day spf=permerror burst attributable to a single mis-published per-portfolio- member SPF record (per-AFRF evidence-stream clusters on the offending per-portfolio- member envelope-from) vs a per-publisher per-day spf=permerror burst attributable to a per-include-zone cascade- overflow root cause (per-AFRF evidence- stream clusters on the per-stacked-ESP cascade depth boundary). Read the DMARC- forensic-reports spoke alongside THIS SPF-result-code catalogue reference whenever the operator authors the per-publisher- side-defect-vs-per-receiver-side-transient- failure SPF result-code triage playbook — the per-message AFRF / IODEF evidence stream is the SOLE per-message-byte-fidelity per-result-code-root-cause attribution channel the receiver-side aggregate spf=permerror / spf= temperror verdict granularity does NOT preserve.
• DMARC for cPanel / WHM shared-hosting deployments — the per-cPanel-account per-customer- domain DMARC publication workflow at the WHM Email Deliverability auto-generation flow, the cPanel DNS Zone Editor publication boundary, and the per-cPanel- server shared-outbound-MTA IP block baseline. When a cPanel-hosted publisher layers include:_spf.mail.hostgator.com / include:_spf.bluehost.com / hosting-provider-SPF-include AT the per-customer-domain SPF record AND ALSO layers include:_spf.google.com for the per-customer-domain Workspace deployment AND ALSO layers include: sendgrid.net for the per-customer- domain transactional-sender deployment, the per-publisher-per-domain RFC 7208 §4.6.4 10-DNS-lookup budget overruns at per-receiver-side check_host() evaluation, and the canonical spf=permerror verdict THIS page documents fires at the receiver-side per-message verifier — read THIS permerror diagnostic reference alongside the cPanel deployment guide so the per-cPanel-account per-customer-domain SPF-publication discipline accounts for the cPanel-shared-MTA hosting-provider- SPF-include lookup-budget consumption profile at the per-customer-domain SPF- record publication boundary.
• DKIM troubleshooting — the DKIM-SIDE PER-SYMPTOM RESULT-CLASS DECISION-TREE companion to THIS page's SPF- side permerror-vs-temperror result-class triage. Where THIS page documents the SPF- side per-receiver-side verifier's RFC 7208 §2.6 result-class enumeration (none / neutral / pass / fail / softfail / permerror / temperror) and the per-result-class diagnostic for SPF-record syntactic / DNS-resolution / lookup-budget failures, the DKIM-troubleshooting spoke is the DKIM-side parallel — documenting the per-symptom decision-tree (dkim=none / dkim=neutral / dkim=pass-but-DMARC-fail / dkim=fail body- hash / dkim=fail signature / dkim=temperror / dkim=permerror / dkim=policy) operators descend when the per-message authentication failure is on the DKIM side rather than the SPF side. The two spokes together form the PER-AUTHENTICATION-RECORD-CLASS operator diagnostic catalogue: a per-receiver per- message spf=permerror verdict sends the operator to THIS page's lookup- budget / syntactic / void-lookup branches; a per-receiver per-message dkim=permerror verdict sends the operator to the DKIM-troubleshooting spoke's missing-selector / malformed-key / unparseable-DKIM-Signature-header branches. Read THIS page when DIAGNOSING the SPF- side result class; read the DKIM- troubleshooting spoke when DIAGNOSING the DKIM-side result class — and consult BOTH when the per-message DMARC verdict fails with neither SPF-aligned nor DKIM-aligned passing, because the DMARC-fail root cause may lie on EITHER authentication-record- class side of the alignment evaluation.
• DKIM best practices — the per-publisher per-selector DKIM publication-and-rotation canonical deployment discipline (RSA-2048-minimum key-strength baseline per Feb 2024 bulk- sender requirements, dual-selector rotation-overlap-window discipline, per-publisher per-selector private-key custody-vs-ESP-delegation policy, per- publisher per-selector k=-and-p=-byte- syntax DNS-publication discipline at <selector>._domainkey.<domain>) whose per-publisher per-domain DKIM publication-correctness IS the LOAD- BEARING DKIM-side counterpart to the per- receiver per-message SPF result class taxonomy THIS page documents. The composition operates through FOUR per- DKIM-publication-discipline-as-per-DKIM- verdict-class-precondition coupling dimensions every per-publisher operator must reason about jointly with the SPF- side error-class diagnostic ladder: (i) per-publisher per-selector DKIM publication-byte-syntax correctness determines per-receiver dkim=none vs dkim=permerror verdict — a per-selector TXT-RR with malformed v=DKIM1; k=rsa; p=<base64> byte-syntax (line-folding errors, missing/wrong k= tag, truncated p= base64 key, 252-character TXT chunking errors) produces per-message dkim=permerror at the receiver, paralleling the SPF spf=permerror publisher- fault class THIS page diagnoses; (ii) per-publisher per-selector key-rotation cadence-and-overlap-window discipline determines per-receiver per-message DKIM-aligned-pass-rate continuity across rotation boundaries — the canonical 24-72-hour dual-selector publication overlap window during which BOTH the OLD selector AND the NEW selector are simultaneously published is the LOAD-BEARING per-publisher per- domain DKIM-aligned-pass-rate- continuity primitive whose absence produces the per-rotation per-receiver DKIM-aligned-pass-rate collapse that operators routinely mis-diagnose as per-receiver dkim=permerror; (iii) per-publisher per-selector RSA-2048- minimum key-strength baseline coordination with per-receiver per- message DKIM-verdict acceptance — the Feb 2024 Gmail / Yahoo Bulk Sender Requirements RSA-2048-minimum floor gates per-receiver per-message dkim=pass verdict acceptance; per-selector publications below the RSA-2048 floor produce per- receiver per-message dkim=neutral / dkim=policy / dkim=fail verdicts whose per-publisher per-receiver acceptance threshold the DKIM-best-practices spoke documents the per-publisher per-domain operator-side per-receiver per-selector key-strength upgrade playbook for; (iv) per-publisher per-domain joint SPF- permerror-and-DKIM-permerror per-day per-receiver-source RUA aggregate- report observability discipline — the per-publisher per-domain operator-side per-day RUA aggregate-report ingestion pipeline MUST surface per-receiver per- message JOINT spf=permerror + dkim=permerror verdict rows as the canonical per-publisher per-domain joint-authentication-record- publication-correctness regression signal, because per-publisher per- receiver per-day DMARC composite-fail spikes whose ROW-LEVEL attribution is joint-permerror MUST be diagnosed at the joint publication-correctness boundary BOTH the SPF-permerror-and- temperror taxonomy THIS page documents AND the DKIM-best-practices spoke documents prescribe the operator-side remediation playbook for. Read THIS page when DIAGNOSING the per-receiver per-message SPF-side result-class verdict; read the DKIM-best-practices spoke when AUDITING the per-publisher per-domain per-selector DKIM publication-and-rotation-discipline correctness that the per-publisher per-domain DMARC composite-pass-rate at the receiver materially depends on as the load-bearing DKIM-side counterpart to the SPF-side error- class taxonomy THIS page catalogues.
• DANE explained — the PER-MX-DANE-TLSA-VALIDATION-FAILURE- MODE-CATALOGUE-AS-TRANSPORT-LAYER-PARALLEL companion to this SPF permerror-vs-temperror error-class taxonomy reference. Where THIS page catalogues the per-publisher per-domain receiver-side SPF result-code taxonomy (the RFC 7208 §2.6 permerror vs temperror distinction whose per-error-class operator- side resolution discipline differs by whether the error reflects a per-publisher per-domain configuration-defect requiring publisher-side fix vs a per-receiver-side transient-DNS-lookup-failure requiring retry), the DANE-explained spoke documents the structurally-parallel per-MX transport- layer cryptographic-chain validation failure- mode catalogue whose per-receiver-side TLSA validation result-classes ( NO_TLSA_RECORDS reflects publisher-side configuration absence — parallel to SPF none; TLSA_HASH_MISMATCH reflects publisher-side certificate- rotation lag without TLSA-RR-update — parallel to SPF permerror; per-receiver DNSSEC-validation transient failure reflects receiver-side resolver- chain instability — parallel to SPF temperror) form the per- publisher per-domain transport-layer error-class taxonomy operators apply the parallel publisher-side fix vs receiver-side retry resolution discipline THIS page prescribes for SPF errors. Read THIS page when DIAGNOSING per- message receiver-side SPF error-class outcomes; read the DANE-explained spoke when DIAGNOSING per-message receiver- side TLSA-validation error-class outcomes at the per-MX transport-layer cryptographic-chain validation boundary where the per-publisher per-MX TLSA RR publication discipline determines the operator-side resolution path.
• DMARC deployment checklist — the PRE-FLIGHT-CHECKLIST-ITEM-SPF- PERMERROR-AND-TEMPERROR-RATE-FLOOR companion to this SPF-error-mode result-code reference. Where THIS page documents the per-publisher per-domain SPF receiver-side result-code taxonomy (RFC 7208 §2.6.7 `spf=permerror`: operator-side permanent over-budget / record-grammar / macro-expansion failures; §2.6.8 `spf=temperror`: transient receiver- side DNS-resolver outages, typically self- resolving) + per-publisher per-domain diagnostic-and-remediation discipline for each error-mode class, the DMARC-deployment- checklist spoke is the per-publisher per- domain DMARC deployment process-reference whose pre-flight checklist-items the per- publisher per-domain SPF-error-mode diagnostic reference THIS page documents structurally enables. FOUR per-publisher per-domain deployment-checklist-vs-SPF- error-mode coupling dimensions: (i) per-publisher per-domain Pre- flight checklist-item: per-publisher per- domain `spf=permerror`-rate-floor verified via per-receiver aggregate-report RUA-row evidence enumeration as load-bearing per- publisher per-domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per- domain pre-flight `spf=permerror`-rate- floor verification step (per-publisher per- domain per-receiver per-day aggregate- report RUA-row evidence enumeration confirming the per-publisher per-domain `spf=permerror`-rate is BELOW the per- receiver-side empirical floor, typically <1%) the per-publisher per-domain DMARC deployment operator MUST execute BEFORE advancing past `p=none` to `p=quarantine`; the per-publisher per-domain SPF-error-mode result-code reference THIS page documents is the LITERAL pre-flight diagnostic reference the deployment-checklist operator consults at the per-publisher per-domain `spf=permerror`-rate-floor verification step; (ii) per-publisher per-domain Pre- flight checklist-item: per-publisher per- domain `spf=temperror`-rate transient-vs- chronic discrimination via per-publisher per-domain per-receiver per-day RUA-row evidence rate-of-change as load-bearing per- publisher per-domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per- domain pre-flight `spf=temperror`-rate transient-vs-chronic discrimination verification step (per-publisher per-domain per-receiver per-day RUA-row evidence rate- of-change profiling to discriminate transient receiver-side DNS-outage spikes from chronic per-publisher per-domain authoritative-DNS-outage patterns) the per- publisher per-domain DMARC deployment operator MUST execute BEFORE advancing ramp; the per-publisher per-domain SPF- error-mode result-code reference THIS page documents is the LITERAL pre-flight transient-vs-chronic diagnostic reference the deployment-checklist operator consults at the per-publisher per-domain `spf=temperror`-rate diagnostic step; (iii) per-publisher per-domain Ramp-phase checklist-item: per-publisher per-domain RFC 7208 §4.6.4 ten-DNS-lookup budget headroom cross-checked during the per-publisher per-domain DMARC ramp as load-bearing per-publisher per-domain `spf=permerror`-regression-prevention gate — the deployment-checklist spoke documents the per-publisher per- domain RFC 7208 §4.6.4 ten-DNS-lookup budget headroom cross-check the per- publisher per-domain DMARC deployment operator MUST audit DURING per-phase ramp advancement (per-publisher per-domain budget-headroom <2 lookups indicates per-publisher per-domain SPF include-cascade is approaching the budget ceiling and any per-publisher per-domain additional `include:` token will produce per-receiver `spf=permerror` ramp- regression); the per-publisher per-domain SPF-error-mode result-code reference THIS page documents is the LITERAL per-publisher per-domain budget-regression-diagnosis reference the deployment-checklist operator consults at the per-phase budget-headroom audit step; (iv) per-publisher per-domain Post-flight checklist-item: per-publisher per-domain per-receiver `spf=permerror` / `spf=temperror` row-attribution accuracy floor in aggregate-report RUA evidence stream as load-bearing per-publisher per- domain DMARC-aligned-pass-rate-floor empirical-observability primitive — the deployment-checklist spoke documents the per-publisher per-domain per-receiver post-flight `spf=permerror` / `spf=temperror` row-attribution accuracy floor (per-row attribution of operator- side-investigation-required vs receiver- side-self-resolving evidence rows) the per-publisher per-domain DMARC deployment operator MUST verify in the per-receiver RUA evidence stream BEFORE advancing to terminal `p=reject pct=100`; the per- publisher per-domain SPF-error-mode result- code reference THIS page documents is the LITERAL per-row attribution diagnostic reference the deployment-checklist operator consults at the post-flight per-receiver row-attribution audit step. Read the DMARC-deployment-checklist spoke alongside this SPF-error-mode result-code reference when AUTHORING the per-publisher per-domain DMARC deployment pre-flight checklist whose `spf=permerror`-rate-floor and `spf=temperror`-rate transient-vs- chronic discrimination is the load-bearing pre-flight gate, when PLANNING the per- publisher per-domain DMARC ramp-progression calendar with explicit RFC 7208 §4.6.4 ten- DNS-lookup budget headroom audit checklist items, or when VALIDATING the per-publisher per-domain DMARC terminal-state `p=reject pct=100` ramp-readiness against the post- flight per-receiver `spf=permerror` / `spf=temperror` row-attribution accuracy- floor checklist gate.
• ARC (Authenticated Received Chain, RFC 8617) explained — the FORWARDER-RELAY-SECOND-HOP-SPF- VERDICT-PRESERVATION-VIA-ARC companion to this SPF permerror-vs-temperror reference. Where THIS page documents the per-publisher per-domain SPF DNS-budget accounting (the RFC 7208 §4.6.4 ten-lookup cap), the void-lookup ceiling, the per- receiver permerror-vs-temperror error-class attribution semantics, the per-domain DMARC ramp-readiness audit, the ARC- explained spoke is the FORWARDER-SECOND-HOP- AUTH-PRESERVATION REFERENCE every SPF operator consults when investigating per- domain SPF-fail / SPF-permerror clusters correlating with mailing-list-expansion or auto-forwarder traffic patterns. Three structurally-distinct SPF-vs-ARC coordination dimensions: (i) the canonical SPF-break-at-second-hop scenario (forwarder relays publisher's mail from publisher's authorised sender to a downstream MX whose connecting IP is the forwarder's egress IP, NOT in the publisher's SPF record, so SPF returns fail) is structurally DESIGNED-OUT by ARC chain — the receiver- side ARC-Seal carries the original publisher's SPF-pass verdict from the first-hop ARC sealer, preserving DMARC- pass across the second-hop SPF-fail; (ii) per-publisher SPF-record `permerror` cluster diagnosis benefits from ARC-chain evidence — receivers logging both per- message SPF-permerror AND broken-ARC-chain outcomes surface per-forwarder-relay Trusted-ARC-Sealers configuration gaps the publisher coordinates with downstream forwarder operators; (iii) SPF-temperror retry semantics during forwarder-relay traversal can produce per-message intermittent DMARC-fail outcomes that the ARC-chain's per-hop preserved-result row distinguishes from genuine attacker- spoofing — receivers consulting the ARC- chain row see the upstream SPF-temperror was a transient retry, NOT a permanent publisher-side authorisation gap.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-SPF- PERMERROR-RATE-FLOOR-AND-SPF-TEMPERROR- RATE-FLOOR-AS-LOAD-BEARING-PRE-FLIGHT- CHECKLIST-GATE-FOR-DMARC-POLICY-MODE- RAMP-COMMITMENT companion to this SPF permerror-vs-temperror diagnostic-ladder reference. Where THIS page documents the per-publisher per-domain SPF result- class diagnostic-ladder at the RFC 7208 receiver-side authentication-failure-mode layer (the per-publisher per-domain spf=pass / spf=neutral / spf=softfail / spf=fail / spf=temperror / spf=permerror / spf=none result-class taxonomy per RFC 7208 §2.6.1-§2.6.7, the per-publisher per-domain spf=permerror root-cause catalogue (10-DNS-lookup-ceiling breach per RFC 7208 §4.6.4, ABNF byte-grammar violation per RFC 7208 §4.5, multiple- v=spf1-TXT-RR per RFC 7208 §4.5, void- lookup-ceiling breach per RFC 7208 §4.6.4), the per-publisher per-domain spf=temperror root-cause catalogue (DNS-resolver-side per-RR timeout, SERVFAIL upstream-authoritative- nameserver, DNSSEC-validation-failure transient state), the per-publisher per- domain per-receiver-side diagnostic decision-tree distinguishing publisher- side authorisation gap from transient DNS-resolver retry), the DMARC-policy- rollout spoke is the PER-PUBLISHER-PER- DOMAIN-SPF-ERROR-RATE-FLOOR-AS-PRE- FLIGHT-CHECKLIST-GATE companion documenting the per-publisher per-domain canonical DMARC policy-mode-ramp progression (p=none 30+ days monitoring → p=quarantine pct=10 7-14 days → pct=25 7-14 days → pct=50 7-14 days → pct=100 7-14 days → p=reject pct=100) whose per-phase per-publisher per-domain commitment-readiness gate consumes per- publisher per-domain spf=permerror-rate-floor evidence + spf=temperror- rate-floor evidence as load-bearing pre- flight checklist-items. Four SPF-error- mode-vs-DMARC-rollout coupling dimensions matter at the per-publisher per-domain ramp-readiness boundary: (i) per-publisher per-domain spf=permerror- rate-floor pre-flight gate — the per- publisher per-domain DMARC p=none- to-p=quarantine transition gate consumes per-publisher per-domain RUA aggregate-XML-report per-receiver per-day spf=permerror count normalised against the total per-publisher per-domain per-receiver per-day message volume; per-publisher per-domain spf=permerror rate above per-publisher per-domain ramp-gate threshold blocks per-phase progression until the per-publisher per-domain SPF- permerror root-cause THIS page diagnoses is remediated; (ii) per-publisher per- domain spf=temperror-rate- floor pre-flight gate — the per-publisher per-domain DMARC p=quarantine pct=N-progression gates consume per-publisher per-domain RUA aggregate- XML-report per-receiver per-day spf=temperror count normalised against per-publisher per-domain per- receiver per-day message volume; per- publisher per-domain spf=temperror rate above the per-publisher per-domain ramp-gate threshold indicates per-publisher per- domain DNS-resolver-side or authoritative- nameserver-side reliability degradation the per-publisher per-domain operator must remediate before per-phase progression; (iii) per-publisher per- domain SPF-flattening remediation cadence during ramp — when per-publisher per- domain SPF-permerror is caused by RFC 7208 §4.6.4 10-DNS-lookup-ceiling breach from an over-broad per-publisher per- domain include: cascade, the per-publisher per-domain SPF-flattening remediation (per-ESP include: consolidation, per-zone v=spf1 TXT-RR splitting across _spf.<domain> sub-zones, per-publisher per-domain ip4: / ip6: literal expansion) THIS page recommends IS the load-bearing per-publisher per- domain pre-flight checklist-item the DMARC policy-rollout discipline gates per-phase progression against; (iv) per- publisher per-domain DMARC rollback observability for SPF-error-mode regression — when per-publisher per- domain p=quarantine pct=N mid-ramp observability surfaces per-publisher per- domain SPF-permerror or SPF-temperror rate-regression in per-publisher per- domain RUA aggregate-XML-report rows, the per-publisher per-domain DMARC policy-rollout rollback options (downward-pct-adjustment, per-publisher per-domain DMARC p=none downgrade) protect per-publisher per- domain deliverability while the SPF- error-mode root-cause THIS page diagnoses is remediated. Read THIS page when DIAGNOSING the per-publisher per-domain per-message SPF-permerror / SPF-temperror result-class root-cause; read the DMARC- policy-rollout spoke when SEQUENCING the per-publisher per-domain DMARC policy- mode-ramp progression whose per-phase per-publisher per-domain commitment- readiness gate consumes per-publisher per-domain SPF-permerror-rate-floor + SPF-temperror-rate-floor evidence the per-publisher per-domain SPF-error-mode result-code taxonomy THIS page diagnoses produces.
• TLS-RPT (SMTP TLS Reporting RFC 8460) explained — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-OBSERVABILITY-STREAM-AS- STRUCTURALLY-PARALLEL-OBSERVABILITY- COUNTERPART-TO-SPF-PERMERROR-AND-TEMPERROR- OBSERVABILITY-STREAM companion to THIS SPF-permerror-vs-temperror result-class diagnostic reference. Where THIS page documents the per-publisher per-domain RFC 7208 §2.6.6 SPF temperror (transient recoverable result-class from per-message per-include SERVFAIL / per-message per- nameserver-outage / per-message per- upstream-resolver rate-limit) and RFC 7208 §2.6.7 SPF permerror (persistent non- recoverable result-class from per-publisher per-domain 10-DNS-lookup cap breach / per- publisher per-domain malformed-record-syntax / per-publisher per-domain 2-void-lookup secondary-cap breach) at the per-publisher per-domain envelope-MAIL-FROM-layer result- class diagnostic boundary, the TLS-RPT spoke is the PER-PUBLISHER-PER-DOMAIN-TRANSPORT- LAYER-OBSERVABILITY-STREAM companion at FOUR per-SPF-result-class-vs-transport- layer-observability coordination dimensions: (i) per-publisher per-domain SPF- permerror persistent-non-recoverable result-class observability stream AS structurally-parallel envelope-MAIL-FROM- layer counterpart to per-publisher per- domain TLS-RPT per-MX-host per-day transport-layer persistent-failure-bucket observability stream — the per-publisher per-domain SPF-permerror catastrophic-persistent-disposition observability stream THIS page documents IS the structurally-parallel per-publisher per-domain envelope-MAIL-FROM-layer counterpart to the per-publisher per- domain TLS-RPT per-MX-host per-day transport-layer persistent-failure-bucket observability stream the TLS-RPT spoke documents the per-MX-host per-failure-type- bucket attribution discipline of (per- publisher per-domain policy-mode-fail / mx-mismatch / mx-host-mismatch / certificate-name-mismatch / certificate-expired / certificate-not-trusted per-MX-host persistent-failure-buckets); BOTH observability streams surface per- publisher per-domain persistent-publisher- side publication-discipline defects at the per-publisher per-domain catastrophic- disposition-class observability boundary; (ii) per-publisher per-domain SPF- temperror transient-recoverable result- class observability stream AS structurally- parallel envelope-MAIL-FROM-layer counterpart to per-publisher per-domain TLS-RPT per-MX-host per-day transport- layer transient-failure-bucket observability stream — the per-publisher per-domain SPF-temperror transient-recoverable-disposition observability stream THIS page documents IS the structurally-parallel per-publisher per-domain envelope-MAIL-FROM-layer counterpart to the per-publisher per- domain TLS-RPT per-MX-host per-day transport-layer transient-failure-bucket observability stream the TLS-RPT spoke documents (per-publisher per-domain per- MX-host transient-TLS-cipher-negotiation- failure, per-publisher per-domain per-MX- host transient-STARTTLS-availability- failure); BOTH per-publisher per-domain transient-recoverable-disposition observability streams surface per-MX-host / per-include-target transient- infrastructure-failure root causes operators discriminate from persistent- publication-defect root causes at the per- publisher per-domain transient-vs- persistent diagnostic boundary; (iii) per-publisher per-domain composite SPF-permerror-rate-floor + SPF-temperror- rate-floor + TLS-RPT-transport-layer- failure-rate-floor observability AS load- bearing per-publisher per-domain DMARC- policy-mode-ramp-progression-readiness evidence-stream — the per- publisher per-domain composite-result- class observability stream consumes per- publisher per-domain envelope-MAIL-FROM- layer SPF-permerror-rate-floor + SPF- temperror-rate-floor evidence THIS page's per-result-class taxonomy diagnoses PLUS per-publisher per-domain transport-layer TLS-RPT-failure-rate-floor evidence the TLS-RPT spoke documents the per-MX-host per-day JSON-aggregate-report observability ingestion discipline of, at the per- publisher per-domain composite-observability- floor DMARC-policy-mode-ramp progression commitment-readiness evidence-stream boundary; per-publisher per-domain operators consume ALL THREE result-class- observability-and-transport-layer- observability rate-floor evidence streams before per-publisher per-domain DMARC p=quarantine / p=reject commitment- progression; (iv) per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination AS load-bearing per-publisher per-domain operator-side unified-trust- signal-publication-discipline-floor — the per-publisher per-domain TLS- RPT transport-layer-observability publication discipline the TLS-RPT spoke documents IS the load-bearing transport- layer-observability leg of the per- publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication- floor coordination posture the per- publisher per-domain SPF-permerror-vs- SPF-temperror result-class diagnostic discipline THIS page documents the envelope-MAIL-FROM-layer-result-class- observability leg of; per-publisher per- domain operators publish ALL FIVE per- publisher per-domain protocol-layer publications coordinated at the per- publisher per-domain unified-trust-signal- floor publication-readiness boundary. Read THIS page when DIAGNOSING per- publisher per-domain per-message SPF- permerror / SPF-temperror result-class root-cause; read the TLS-RPT spoke when AUDITING the per-publisher per-domain per-MX-host per-day transport-layer- observability stream whose per-publisher per-domain RFC 8460 JSON-aggregate-report ingestion discipline IS the load-bearing sibling per-publisher per-domain transport-layer-observability stream coordinated with the per-publisher per- domain envelope-MAIL-FROM-layer SPF- permerror-and-temperror result-class observability stream THIS page diagnoses.
• Email spoofing techniques and defenses — the seven-technique email-spoofing attack catalogue companion at four SPF- result-class vs spoofing-attack-class coupling dimensions.
• Phishing protection defence-in-depth stack — the PER-PUBLISHER-PER-DOMAIN-SPF- PERMERROR-AND-TEMPERROR-RESULT-CLASS-AS- LOAD-BEARING-RECEIVER-SIDE-FAIL-OPEN- VULNERABILITY-WINDOW-FOR-PHISHING-PRETEXT- EMAILS companion to this SPF result-class diagnostic pillar. Where THIS page documents the per-publisher per-domain SPF-evaluator failure-mode result distinction (permerror per RFC 7208 §2.6.7 from 10-DNS-lookup-cap exhaustion + temperror per RFC 7208 §2.6.6 from DNS-resolver-timeout), the phishing-protection spoke is the DEFENCE- IN-DEPTH STACK REFERENCE documenting the receiver-side composite defence posture the SPF-permerror-and-temperror result-class diagnostic ON THIS PAGE shapes at FOUR per-phishing-attack-class vs SPF-result-class coupling dimensions: (i) SPF- permerror opens the receiver-side fail-open phishing-pretext- delivery window — receivers that treat permerror as soft-disposition (rather than the RFC 7208 §8.6 SHOULD-disposition) admit per-publisher per-domain envelope-MAIL-FROM-spoofed phishing-pretext emails that the phishing- defence stack must catch downstream via DKIM-alignment + content-heuristic filters; the phishing-protection spoke documents the per-publisher operator-hygiene + per-receiver receiver-hygiene disciplines that close the permerror-derived phishing-delivery window; (ii) SPF-temperror per-receiver retry-window is a phishing- timing-attack vector — attackers timing per-mailbox-provider SPF-temperror retry windows push phishing-pretext emails through receivers deferring per-message disposition while the retry-window remains open; the phishing-defence stack catalogued in the spoke addresses this per-day per- MX-host transient-bypass attack-window via DKIM-signature-on-every-outbound + DMARC composite verdict; (iii) SPF qualifier-tightening from ~all SoftFail to -all Fail is the upstream input to phishing-defence-stack composite per-message disposition — the phishing-protection spoke documents the per-publisher per-domain qualifier- tightening discipline AS THE LOAD-BEARING UPSTREAM INPUT to the receiver-side defence-in-depth composite verdict; (iv) SPF-permerror cascade-elimination via SPF-flattening shrinks the per-domain phishing-pretext-delivery attack-surface — the phishing-defence stack catalogued in the spoke documents the flattening-as-defensive-hardening discipline whose per-publisher per-domain adoption is upstream-coordinated by the SPF-permerror result-class diagnostic on THIS page.
• Business Email Compromise (BEC) defence stack — the per-publisher per-domain SPF- permerror-vs-temperror-result-class-as-load- bearing-anti-BEC-envelope-MAIL-FROM-layer- defence companion to this SPF result-class diagnostic pillar. Where THIS page documents the per-publisher per-domain SPF evaluator failure-mode-result distinction (permerror per RFC 7208 §2.6.7 from 10-DNS-lookup-cap exhaustion or malformed-syntax / temperror per RFC 7208 §2.6.6 from DNS-resolver-timeout / the operator-side SPF-flattening + include-cascade-consolidation + qualifier-tightening drift-closure discipline), the BEC defence-stack spoke documents the per-publisher per-domain anti- BEC envelope-MAIL-FROM-layer defence boundary the SPF result-class diagnostic underpins. Four coupling axes connect them: (i) per- publisher per-domain SPF permerror result-class IS a direct anti-BEC defence-collapse vector — per-receiver per-mailbox-provider partial-SPF-implementations admit per-message envelope-MAIL-FROM-spoofed BEC pretext-emails when SPF-permerror is treated as soft-disposition (rather than the RFC 7208 §8.6 SHOULD-disposition); per-publisher per- domain SPF-flattening drift-closure operationally hardens the envelope-MAIL-FROM- spoofing-via-SPF-permerror-bypass attack- surface; (ii) per-publisher per-domain SPF temperror result-class IS the per-day per-MX-host transient-bypass attack- window authenticated-replay spoofing harvests — attackers timing per-mailbox-provider SPF-temperror retry-evaluation windows can push BEC pretext-emails through receivers deferring per-message disposition while the retry-window remains open; per-publisher per- domain DNS-resolver-degradation drift-closure operationally hardens this transient-bypass attack-window; (iii) per-publisher per- domain SPF qualifier-tightening from ~all SoftFail to -all Fail IS the load-bearing anti-direct-domain-spoofing defence-strength primitive — per-publisher per-domain BEC defence requires -all hard-fail qualifier-policy emission rather than the ~all SoftFail qualifier-policy the receiver-side Sender-allowlists routinely admit; (iv) per-publisher per-domain SPF result-class diagnostic baseline IS the per- publisher per-domain operator-side anti-BEC ramp-readiness diagnostic-baseline — per-publisher per-domain operators MUST baseline SPF result-class distribution (per-receiver per-day per-result-class attribution in DMARC RUA aggregate-report stream) BEFORE per-publisher per-domain DMARC enforcement-mode ramp progression past p=none monitoring-tier to per- publisher per-domain p=quarantine / p=reject enforcement-tier closing the anti-BEC envelope-MAIL-FROM- layer defence boundary. Read the BEC defence-stack spoke alongside this SPF result-class diagnostic pillar when AUDITING per-publisher per-domain SPF-permerror / SPF-temperror distribution against BEC attack-surface exposure-budget, when AUTHORING per-publisher per-domain SPF publication-discipline drift-closure ahead of anti-BEC ramp progression, or when PLANNING per-publisher per-domain qualifier- tightening + DMARC enforcement-mode ramp sequencing against the composite SPF-result- class-and-DMARC-enforcement-mode anti-BEC defence-floor progression discipline.
• DMARC policy modes
• DKIM-Signature header explained
• DMARC multi-domain strategy
• Email deliverability — the inbox-placement companion to this SPF permerror-vs-temperror diagnostic page. A per-publisher per-domain spf=permerror verdict (10-DNS-lookup-cap exhaustion or byte-grammar drift per RFC 7208 §4.6.4) collapses the SPF authentication leg, dropping the DMARC composite-aligned-pass rate and pushing otherwise-legitimate mail into quarantine or the spam folder — while transient spf=temperror produces intermittent deliverability dips that read as sender-reputation noise. The deliverability spoke frames why the permerror/temperror distinction this page diagnoses is a first-order inbox-placement signal, not just an authentication footnote. Read it when an SPF result-class regression is showing up as a deliverability complaint.
• MTA-STS for Microsoft 365
• DKIM alignment with DMARC — the other DMARC authentication leg, the one that survives when SPF breaks. An spf=permerror or spf=temperror collapses the SPF leg, but a DKIM signature whose d= domain aligns (relaxed or strict) with the From-header domain still carries the DMARC pass per the "any aligns wins" rule. Read the alignment spoke to see why a healthy aligned DKIM leg is the resilience hedge against the SPF result-code failures this page triages.
• TLS-RPT record syntax — the TRANSPORT-LAYER-FAILURE-DIAGNOSTIC-VISIBILITY companion to this SPF result-code reference: just as a malformed or syntactically-invalid SPF record produces the permanent spf=permerror this page triages, a malformed _smtp._tls.<domain> TXT-RR (wrong version tag, missing rua=, bad URI) silently disables the transport-layer reporting stream a domain would otherwise use to see STARTTLS-handshake failures — both are DNS-record-byte-grammar faults that degrade an operator's diagnostic visibility, one at the envelope-MAIL-FROM authentication layer and one at the transport-encryption-reporting layer. Read the TLS-RPT-record-syntax spoke when triaging whether a domain's loss of failure visibility traces to an SPF result-code fault or to a mis-published TLS-reporting record.
• Microsoft SNDS + JMRP monitoring — SPF PASS does not clear Microsoft's IP-reputation gate: SNDS shows the per-IP GREEN/YELLOW/RED filter verdict Outlook.com assigned to each authorized address and JMRP reports the Junk clicks behind a degraded one.

13. Verify your SPF record now

The DMARC Analyzer platform surfaces SPF result codes in three places: the Domain Security Checker runs a live SPF lookup against the public DNS and reports any of the seven permerror cause classes plus the live lookup count; the Email Header Analyzer parses pasted Authentication-Results headers and surfaces the specific spf= verdict and parenthetical reason; the dashboard ingests DMARC aggregate (RUA) reports and surfaces per-record SPF result codes at scale so you can monitor the permerror / temperror rate over time.

Check my SPF record Analyze an SPF permerror or temperror header Sign up — Free plan