spf.all_policy Reviewed July 2026

Quick fix

Inventory and test all legitimate sending systems.

What this finding means

SecuTest follows effective include and redirect behavior and evaluates the final `all` mechanism. `+all` authorizes every sender, `?all` is neutral, `~all` is transitional softfail, and `-all` is the restrictive end state. The scanner also flags missing or multiple `all` mechanisms.

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 Domain spoofing and phishing

How the attack or failure scenario works

An attacker sends mail using the protected domain from infrastructure that the organization does not control. A permissive final SPF policy may return pass or fail to return a strong negative result, making forged envelope identities harder for receivers to distinguish. DMARC protection still depends on identifier alignment.

Conditions and limitations

  • The attacker can deliver SMTP mail from an unauthorized IP.
  • The effective SPF record reaches the weak or permissive `all` mechanism.
  • The receiving system uses SPF and may not have an aligned DKIM pass or enforcing DMARC policy.

Why it matters

Security and business impact A missing, neutral, soft, duplicated, or permissive `all` mechanism can authorize unintended senders or leave spoofing decisions weak.

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. Inventory and test all legitimate sending systems.
  2. Place explicit `ip4`, `ip6`, `include`, `a`, or `mx` authorizations before a single final `all` mechanism.
  3. Remove `+all` and `?all` immediately unless a documented emergency exception exists.
  4. Use `~all` only as a measured transition, then adopt `-all` after DMARC reports show complete coverage.

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.

Restrictive example
example.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all"

Transitional example
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"

Verify the fix

  1. Expand includes and redirects and confirm the final effective policy.
  2. Send authorized mail and confirm `spf=pass`.
  3. Send a controlled unauthorized test and confirm `spf=fail` with `-all`.
  4. Verify that DMARC passes through SPF or aligned DKIM for every production sender.
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

  • Using `+all` to fix delivery complaints instead of identifying the missing sender.
  • Placing mechanisms after `all`, where they are unreachable.
  • Assuming SPF alone protects the visible From header without DMARC alignment.

Authoritative references