spf.recursion Reviewed July 2026

Quick fix

Map the complete include and redirect graph from the root record.

What this finding means

SecuTest recursively resolves `include` and `redirect` dependencies, detects loops, missing targets, ambiguous records, unsupported macros, and excessive depth. The check distinguishes deterministic configuration defects from transient DNS failures.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type SPF dependency failure and authentication denial

How the attack or failure scenario works

SPF policies can delegate authorization to other domains. A circular or invalid dependency prevents the receiver from completing evaluation, often producing `permerror`. This can reject legitimate mail and remove a dependable anti-spoofing signal. An attacker may benefit indirectly if a third-party dependency becomes compromised, but the finding itself does not prove compromise.

Conditions and limitations

  • The root SPF policy references an invalid or circular dependency.
  • A receiver evaluates the affected path for a message.
  • Abuse through dependency control additionally requires an attacker to control a referenced DNS zone or provider account.

Why it matters

Security and business impact Broken, circular, missing, or excessively deep SPF dependencies can produce permanent errors and invalidate sender authorization.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Map the complete include and redirect graph from the root record.
  2. Remove circular references and duplicate or missing dependency records.
  3. Replace unsupported dynamic macros with explicit, auditable mechanisms where possible.
  4. Minimize third-party dependencies and document the owner, purpose, and removal process for each include.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Inspect root policy
dig +short TXT example.com | grep -i 'v=spf1'

Inspect dependency
dig +short TXT spf.example-provider.net | grep -i 'v=spf1'

Verify the fix

  1. Query every referenced domain and confirm exactly one valid SPF record exists.
  2. Run a recursive SPF evaluator and verify there are no loops or unresolved targets.
  3. Send messages through each dependent platform and confirm `spf=pass`.
  4. Repeat SecuTest and ensure recursion and lookup-limit checks both pass.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Flattening a provider record once and never updating the resulting IP list.
  • Removing a loop at one point while leaving another redirect path circular.
  • Treating a transient DNS timeout as proof that the dependency is permanently invalid.

Authoritative references