What is SPF (Sender Policy Framework)?

Definition

Sender Policy Framework is one of the three core email authentication standards, alongside DKIM and DMARC. It addresses a basic weakness in email: by default, anyone can send a message that claims to come from any domain, because the original mail protocols never built in a way to prove who the real sender is. SPF closes part of that gap by giving a domain owner a way to declare, publicly and in a machine-readable form, exactly which servers are permitted to send mail on the domain's behalf.

That declaration lives in the Domain Name System, the same global directory that translates domain names into network addresses. The domain owner publishes a special DNS record that names the authorized senders. When a message arrives, the receiving mail server looks up that record and compares it against the server that actually delivered the message. If the sending server is on the list, the message passes SPF. If it is not, the message fails SPF, which is a strong hint that the mail may be forged. SPF does not encrypt anything and does not check the message content. It answers one focused question: was this message sent from a server the domain owner approved?

How It Works

An SPF policy is published as a single DNS TXT record on the domain. The record always begins with the version tag v=spf1, followed by a series of mechanisms that describe authorized senders, and it normally ends with an all mechanism that defines the default outcome. A simple record might read v=spf1 include:_spf.google.com -all, which authorizes Google Workspace mail servers and rejects everything else.

The mechanisms are the building blocks. The ip4 and ip6 mechanisms authorize specific addresses or address ranges directly. The a mechanism authorizes the servers found in the domain's address records, and mx authorizes the servers listed as the domain's mail exchangers. The include mechanism is the most common in practice, since it pulls in the SPF policy of another provider, which is how a domain delegates sending to services such as Google, Microsoft, or an email platform. Each mechanism can carry a qualifier that sets the result when it matches. A plus sign, which is the default, means pass. A minus sign means fail, a tilde means softfail, which is a soft warning, and a question mark means neutral. The all mechanism at the end catches every server that did not match, so -all is a hard rejection of anything unlisted while ~all is a softer signal.

When a receiving server evaluates SPF, it checks the envelope-from address, which is the return-path declared during the SMTP exchange, and for bounce messages with an empty return-path it checks the HELO identity instead. The standard imposes an important constraint: evaluating a record may use no more than ten DNS lookups, and mechanisms such as include, a, mx, and exists each consume one. If a record needs more than ten, it produces a PermError, which receivers can treat as a failure, so SPF records must be kept compact. SPF also has structural limits. It breaks when mail is forwarded, because the forwarding server is not on the original domain's list, and crucially it only validates the envelope-from address, not the visible From address that a recipient actually sees.

Why It Matters for Email Deliverability

SPF is now a baseline requirement rather than an optional extra. Mailbox providers treat a passing SPF check as a positive trust signal and treat a missing or failing record as a reason for suspicion, which directly affects whether mail reaches the inbox or the spam folder. Since the 2024 sender requirements introduced by Google and Yahoo, bulk senders are expected to authenticate with SPF, and a domain without a valid SPF record can see its mail throttled or rejected outright.

SPF also matters because it is a prerequisite for DMARC, the policy layer that ties authentication to the visible From address. DMARC works by checking whether SPF or DKIM passed and whether the result aligns with the From domain. Without a correctly configured SPF record, a domain cannot achieve DMARC alignment through SPF, which weakens its overall protection. At the same time, it is important to be realistic about what SPF cannot do. Because it ignores the visible From header and breaks on forwarding, SPF alone cannot stop a determined spoofer. It is one necessary layer of a three-layer defense, and it delivers its full value only when DKIM and DMARC are in place beside it.

How VeriMails Handles It

SPF and email verification solve two different halves of the same deliverability problem. SPF authenticates the mail you send so receiving servers trust that it genuinely came from you. Email verification cleans the list you send to, so that you are only ever mailing real, reachable addresses. Strong inbox placement needs both working together, and neither one substitutes for the other.

VeriMails focuses on the recipient side. Every address you submit is checked through syntax validation, an MX and DNS lookup, a live SMTP handshake, catch-all detection, disposable address detection, and role-based detection, so invalid addresses are removed before they can bounce and drag down a reputation that good SPF, DKIM, and DMARC records exist to protect. To help on the authentication side as well, VeriMails offers a free SPF generator that builds a syntactically correct record for your domain and sending services, keeping it within the ten lookup limit. You can verify a list through the REST API or a bulk CSV upload, with clear deliverability categories for campaign decisions. Verification starts at $0.0019 per email, with 10,000 credits for $19 and subscriptions from $15 per month, and every account begins with 100 free credits, no credit card required, that never expire.

Frequently Asked Questions