spf.present Reviewed July 2026

Quick fix

Inventory every legitimate sender, including Microsoft 365, Google Workspace, transactional mail, CRM, support, and security gateways.

What this finding means

SecuTest searches the registrable domain's TXT records for a single value beginning with `v=spf1`. Absence of SPF does not guarantee successful spoofing because DMARC and DKIM may still protect messages, but it removes one major authentication signal and can reduce deliverability.

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

How the attack or failure scenario works

Email spoofing is the use of a forged sender identity so a message appears to originate from a trusted domain. SPF lets a receiver compare the connecting IP with the domain's authorized sending infrastructure. Without SPF, that authorization test cannot produce a pass result for the envelope-from domain.

Conditions and limitations

  • An attacker can send SMTP traffic using the domain in the envelope-from or HELO identity.
  • The receiver accepts unauthenticated or weakly authenticated mail.
  • Successful DMARC abuse also depends on visible From-domain alignment and whether DKIM provides an aligned pass.

Why it matters

Security and business impact Without SPF, receivers have no domain-published list of authorized envelope senders, increasing exposure to email spoofing and phishing.

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 every legitimate sender, including Microsoft 365, Google Workspace, transactional mail, CRM, support, and security gateways.
  2. Construct one SPF record that authorizes only those sources.
  3. Publish the record as TXT at the registrable domain; do not publish the obsolete SPF DNS record type.
  4. Start with `~all` only during a controlled migration, monitor results, then move to `-all` when the inventory is complete.

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.

Basic restrictive example
example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.10 -all"

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

Google Workspace example
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com -all"

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

Verify the fix

  1. Run `dig +short TXT example.com` and confirm exactly one logical `v=spf1` record.
  2. Send test messages from every legitimate platform and inspect `Authentication-Results` for `spf=pass`.
  3. Send an authorized negative test from a non-approved system and confirm SPF does not pass.
  4. Check DMARC aggregate reports before enforcing `-all`.
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

  • Copying multiple provider examples as separate SPF records.
  • Authorizing broad address ranges without confirming ownership.
  • Moving directly to `-all` before discovering scanners, ticketing systems, and legacy senders.

Authoritative references