SPF Record (Sender Policy Framework)

SPF (Sender Policy Framework) is a DNS-based email authentication method defined in RFC 7208. The domain owner publishes a TXT record listing every IP address and host allowed to send mail on that domain's behalf. When a receiving mail server gets an inbound message, it takes the domain from the SMTP envelope sender (MAIL FROM), queries DNS for the SPF record, and checks whether the connecting IP is on the authorized list. A match produces a Pass result; a mismatch yields Fail, SoftFail, or Neutral depending on the record's catch-all qualifier.

How SPF evaluation works

Evaluation follows a strict left-to-right order. The record always starts with v=spf1 and ends with a catch-all qualifier, typically ~all or -all. Between them, mechanisms declare authorized sources:

• ip4:203.0.113.0/24 — allow a specific IPv4 address or subnet.
• ip6:2001:db8::/32 — same for IPv6.
• include:_spf.google.com — delegate to another domain's SPF record. Used when mail goes through Google Workspace, Mailchimp, SendGrid, or any third-party ESP.
• a and mx — authorize the IPs resolved from the domain's A or MX records. Convenient, but each costs a DNS lookup.

The receiver walks through each mechanism until one matches the sender IP. If none match, the catch-all applies. -all means hard Fail: reject everything not explicitly listed. ~all means SoftFail: treat as suspicious but leave the final decision to the receiver.

The 10-lookup limit

RFC 7208 caps DNS-querying mechanisms at 10 per evaluation. Each include, a, mx, exists, and redirect counts toward this cap, including nested includes. Exceeding it triggers a PermError, and the message may be rejected outright.

Companies routing mail through several services — a CRM, a transactional ESP, a helpdesk, a marketing platform — frequently hit this ceiling. Two common fixes: replace include directives with static ip4 entries (which cost zero lookups), or use an SPF-flattening service that resolves includes into IP lists and keeps the record within limits.

Common mistakes

• Two SPF records on one domain. There must be exactly one TXT record with v=spf1. Two or more produce a PermError and the check fails immediately.
• Using +all. This allows any IP to send on the domain's behalf. SPF becomes meaningless — there is nothing to protect.
• No catch-all mechanism. Without -all or ~all at the end, the record is technically malformed. Some providers treat this as ?all (Neutral), which weakens the protection considerably.
• Forgetting new sending services. Adding a new ESP without updating SPF means mail through that service will fail authentication. Every infrastructure change requires a fresh review of the record.

SPF alone is not enough

SPF checks the envelope sender, not the visible From header. An attacker can pass SPF using their own domain in MAIL FROM while putting your domain in the From header the recipient sees. This gap is exactly what DMARC closes: it requires alignment between the From header and the domain verified by SPF or DKIM. Without DMARC, SPF blocks only part of the spoofing surface.

In practice, all three records — SPF, DKIM, and DMARC — work as a single authentication stack. SPF declares who may send. DKIM proves the message was not altered in transit. DMARC ties both to the visible sender address and defines a policy for failures.

SPF and email list validation

When a validator inspects a domain's DNS infrastructure, the presence of an SPF record is a reasonable signal that the domain is actively used for sending mail and that someone is managing its authentication. A recently registered domain with no TXT records at all raises more concern.

For senders, the relationship runs the other way. A misconfigured SPF record means messages fail authentication on the receiving side: bounce rates climb, deliverability drops, and domain reputation takes a hit. A clean address list and a correct SPF record are separate problems, but both affect whether your mail reaches the inbox.