SPF (Sender Policy Framework)

Sender Policy Framework (SPF) is a DNS-based email authentication standard that lets a domain owner publish, in a single DNS TXT record, the list of mail servers authorized to send email on the domain's behalf. When a receiving server gets a message, it looks up the SPF record for the sender's domain and checks whether the connecting IP address is permitted. If it is, the message passes SPF; if not, the receiver can treat it as suspicious. SPF is defined in DNS records and works alongside DKIM and DMARC as one layer of a complete email authentication setup.

Why it matters

Without SPF, anyone can send email claiming to be from your domain, because the SMTP envelope sender is trivially forgeable. That makes a domain attractive for phishing, business email compromise, and brand impersonation. A correctly scoped SPF record limits which servers can legitimately send mail, helping receiving providers reject or quarantine spoofed messages and improving the deliverability of your real email.

How it works

SPF lives as a TXT record at the root of your domain, beginning with v=spf1. The record contains mechanisms that authorize sources, and ends with a qualifier that tells receivers how to treat anything not listed:

• ip4: / ip6: — authorize specific IP addresses or ranges.
• include: — delegate to another domain's SPF (common for providers like Google Workspace or SendGrid).
• a / mx — authorize the domain's own A or MX hosts.
• -all (hard fail), ~all (soft fail), or ?all (neutral) — the closing policy.

SPF also has a hard limit of 10 DNS lookups per evaluation. Exceeding it produces a permerror, which can silently break authentication, so keep include: chains lean.

Example

A domain that sends mail through Google Workspace and one marketing platform might publish:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Here, only Google's and SendGrid's servers are authorized, and -all instructs receivers to reject anything else.

On your external attack surface

SPF is a public DNS record, so its presence and contents are part of your visible attack surface. Common issues an attacker or auditor will spot include a missing record (a domain trivially spoofable), a weak ?all/+all ending, more than 10 lookups, or multiple SPF records on one domain (which is invalid and causes failures). SPF only covers the return-path domain, so it should never be relied on alone — DMARC ties it back to the visible From address.

How FortWatch helps

FortWatch's DNS monitoring scanner inspects each asset's SPF record continuously, flagging a missing record, an overly permissive policy, duplicate records, or lookup-count overruns, then assigns a severity based on whether the domain actually sends mail and pairs it with AI-generated remediation. You can also check any domain instantly with the free DMARC/SPF checker.