What is Sender Policy Framework (SPF)?

Definition: Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email-authentication standard that lets a domain publish, in DNS, the list of mail servers allowed to send on its behalf. Receiving mail systems check that list during SMTP; if the sending IP isn’t authorized, they can reject, quarantine, or flag the message. If you’re searching for what is Sender Policy Framework, think of SPF as a guest list at the door: only senders you’ve named in DNS get in without trouble.

Why SPF matters (and the trap teams fall into)

Email is the front door of business. Attackers know it, and spoofing a “from” address can look convincing enough to slip past busy people. SPF cuts down spoofing by making recipients verify the path a message took. The trap? Teams “turn on SPF” with a quick copy-paste, then forget to maintain it as vendors change, marketing platforms rotate IPs, or new services send email. Outcomes go sideways: legitimate mail goes to spam, and attackers still find gaps. SPF works best when it’s accurate, minimal, and paired with DKIM and DMARC.

How SPF works (plain-English walkthrough)

At send time, the recipient’s server evaluates SPF roughly like this:

1. Extract the envelope sender (a.k.a. Return-Path, MAIL FROM) or, if empty (bounces), use the connecting IP’s reverse domain (HELO/EHLO).
2. Look up the domain’s SPF policy in DNS (a TXT record that starts with v=spf1).
3. Walk the policy’s mechanisms (e.g., ip4, ip6, a, mx, include) to see if the connecting IP is permitted.
4. Stop at the first match and return a result such as Pass, Fail, Softfail, or Neutral.
5. Apply local policy: accept, tag, throttle, or reject based on that result (and often in combination with DKIM/DMARC).

SPF validates the path (IP/domain relationship), not the header From name users see. That’s why DMARC (which aligns header From with SPF or DKIM) is the strategy glue—more on that in best practices.

Anatomy of an SPF record

SPF lives as a DNS TXT record on your sending domain (and, if you use subdomain routing, on those subdomains). The record begins with v=spf1 followed by mechanisms, qualifiers, and optional modifiers.

Mechanisms (the tests)

• ip4:203.0.113.10 and ip6:2001:db8::/32 — allow specific IPs/CIDR ranges.
• a or a:mail.example.com — allow the A/AAAA of the named host (or the domain’s root if host omitted).
• mx or mx:example.com — allow the MX host IPs.
• include:spf.mailvendor.com — import another domain’s SPF policy (common for ESPs/CRMs).
• exists:… — advanced pattern check using a DNS lookup that returns any record.
• ptr — reverse-DNS match (discouraged: slow and unreliable).
• all — matches everything and is typically placed last to set a default outcome.

Qualifiers (what to do when a mechanism matches)

• + Pass (implicit; usually omitted)
• - Fail (hard fail; receiver may reject)
• ~ Softfail (accept but mark as suspicious)
• ? Neutral (no assertion)

Modifiers (extras)

• redirect=other.example — hand off evaluation to another domain’s policy (mutually exclusive with all).
• exp=explain.example — legacy explanation text (rarely used now).

A simple example

example.com. TXT "v=spf1 ip4:198.51.100.77 include:_spf.mailer.com -all"


This says: mail can come from 198.51.100.77 or from whatever _spf.mailer.com allows; everything else fails.

The 10-lookup rule (and why it bites)

SPF permits at most 10 DNS-mechanism lookups per evaluation (include, a, mx, ptr, exists, redirect). Go over 10 and receivers should return PermError, which many treat like a fail. Large organizations quickly hit this limit by stacking many vendors. Strategies to stay under 10:

• Prefer ip4/ip6 blocks over a/mx where possible (fewer lookups).
• Use vendor-provided consolidated includes (e.g., one include that aggregates many sub-includes).
• Avoid ptr; minimize exists.
• Flatten as a last resort (replace include with vendor IPs), but plan to monitor for vendor IP changes.

Alignment with DMARC (why SPF alone isn’t enough)

SPF evaluates the envelope sender (Return-Path), which is often different from the header From that users see. DMARC adds the rule that either DKIM must validate and align with the From domain, or SPF must validate and the envelope domain must align with the From domain. That “alignment” is what stops an attacker from passing SPF using their own Return-Path while spoofing your visible From. In practice:

• Use DKIM on all sources so DMARC can succeed even with forwarding (which often breaks SPF).
• Ensure the Return-Path domain either matches or is a subdomain of your From domain for SPF alignment (or accept that DKIM will carry the weight).

Forwarding and SRS (the SPF gotcha)

When mail is forwarded, the forwarding server connects to the recipient using its own IP, not the original sender’s IP. Unless the forwarder rewrites the envelope sender using SRS (Sender Rewriting Scheme), SPF will fail at the next hop. You can’t fix third-party forwarders, which is another reason to sign everything with DKIM and rely on DMARC alignment to survive forwarding.

Recommended patterns (sane defaults you can trust)

Start with a minimal allow list

Keep SPF tight. Authorize only what you actually use:

v=spf1 include:_spf.yourmailhost.com ip4:203.0.113.40 -all


• Prefer -all (hard fail) once you’re confident your sources are complete.
• Use ~all (softfail) during discovery while you watch logs and recipient feedback.

Isolate oddball senders on subdomains

If marketing tools, scanners, or apps must send, give them subdomain identities:

• From: campaigns@news.example.com
• SPF on news.example.com: v=spf1 include:_spf.vendor.com -all
• DKIM signing with d=news.example.com
• DMARC on news.example.com with policy and reporting

This keeps your apex domain’s reputation clean and your policies simple.

Prefer vendor “include” over raw IPs—usually

Good ESPs publish stable includes (and maintain them). If your lookup budget is tight, you may flatten to IPs—but set a review cadence because vendors do change ranges.

Step-by-step implementation guide

1) Inventory sending sources.
List everything that sends as your domain: primary mail host, marketing platform(s), ticketing, CRM, scanners, SaaS apps, devices (copiers), and cloud services (e.g., Microsoft 365 or Google Workspace).

2) Decide the identity model.
Keep the apex domain for first-party mail; move third-party tools to subdomains where possible.

3) Draft your SPF records.
Start minimal. Example for an apex domain on a major host + a single app server:

example.com. TXT "v=spf1 include:_spf.hostedmail.com ip4:198.51.100.77 ~all"


4) Publish in DNS.
Create a TXT record at the exact domain that appears in the Return-Path (usually same as From for first-party mail; vendor tools often use a subdomain).

5) Test.
Send to a test account at several providers. Inspect headers for spf=pass and note the domain used. Watch for permerror (too many lookups) or none (no policy found).

6) Turn on DKIM (for every source).
Generate keys, publish selectors, and enable signing so DMARC has a second path to succeed.

7) Add DMARC with reporting.
Start with p=none; rua=mailto:dmarc-reports@example.com to gain visibility. Tighten to quarantine/reject when confident.

8) Move ~all to -all.
Once tests pass across providers and reports show legitimate sources are covered, switch to hard fail.

9) Maintain like a product.
Create a change process: when a marketing or SaaS team adds a sender, they file a request to update SPF/DKIM/DMARC. Review quarterly for stale includes and DNS errors.

Troubleshooting tips (when mail goes missing)

• Check the evaluated domain. Look at the header’s Authentication-Results. If SPF evaluated bounce.news.example.com, ensure that domain has the right SPF.
• Count your lookups. Manually expand includes or use a linting tool; keep total ≤ 10.
• Prefer CIDR. Replace many single ip4 entries with one block where accurate.
• Watch for chained includes. An include that pulls in another include still counts.
• Drop ptr. It wastes lookups and offers little value.
• Avoid multiple SPF records. A domain must have one SPF TXT record; merge entries if duplicates appear.

Example templates you can adapt

Microsoft 365 (single tenant, no extra senders)

v=spf1 include:spf.protection.outlook.com -all


Google Workspace + marketing vendor + on-prem relay

v=spf1 include:_spf.google.com include:_spf.mailer.com ip4:203.0.113.44 -all


Subdomain for scanners (kept separate from user mail)

scans.example.com. TXT "v=spf1 ip4:198.51.100.120 -all"


Security and deliverability best practices

• Pair SPF with DKIM + DMARC. SPF alone is not enough; DKIM handles forwarding, and DMARC enforces alignment with visible From.
• Limit who can send as your apex domain. Reserve it for first-party systems; move everything else to subdomains.
• Monitor DMARC reports. They reveal unknown senders and sources abusing your domain.
• Review vendor guidance. Use their published includes and recommended selectors; don’t invent your own hostnames.
• Keep records short and readable. Humans maintain these; future you will thank present you.

Common pitfalls (and how to avoid them)

Over-including everything. Too many includes blow past the 10-lookup limit. Fix: consolidate, flatten judiciously, or move senders to subdomains.
Leaving ~all forever. Softfail helps during discovery but leaves room for spoofing. Fix: move to -all once coverage is confirmed.
Assuming header From is what SPF checks. It isn’t. Fix: use DMARC to align visible From with SPF (or DKIM).
Breaking outbound after vendor change. Providers rotate IPs. Fix: subscribe to change notices and review quarterly.
Multiple SPF records. Receivers may treat this as an error. Fix: merge into a single v=spf1 TXT.

Related Solutions

SPF delivers best results when it’s part of a coordinated email-security stack. Secure Email Gateway (SEG) adds phishing, malware, and impersonation defenses on top of SPF/DKIM/DMARC. Security Information and Event Management (SIEM) centralizes email authentication logs so your Security Operations Center (SOC) or Managed Detection and Response (MDR) can investigate spoofing attempts quickly. Round out resilience with Security Awareness Training (SAT) so users recognize suspicious mail even when SPF passes, and protect exposed webforms and APIs tied to email flows with Web Application and API Protection (WAAP) where appropriate.