Definition
An SPF Record (Sender Policy Framework record) is a DNS TXT resource record published in a domain’s public DNS zone that enumerates the IP addresses, IPv6 prefixes, and mail server hostnames authorised to send email on behalf of that domain. When a receiving mail server accepts an inbound message, it queries the sender’s DNS for the SPF record and compares the connecting IP address against the policy. If the IP is not listed, the receiving server can mark the message as a softfail, reject it outright, or flag it for further evaluation — depending on the policy qualifier set by the domain owner.
SPF was first formalised as an IETF standard in RFC 4408 (2006) and later updated to the current authoritative specification in RFC 7208, published by the Internet Engineering Task Force (IETF) in April 2014. It is one of three complementary email authentication standards alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance).
How It Works
The SPF evaluation process involves several sequential steps performed by the receiving mail server’s SMTP engine during the MAIL FROM phase of the SMTP handshake.
The domain owner publishes an SPF TXT record in DNS. A typical record follows this syntax: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. The components are: v=spf1 (version identifier), one or more mechanisms (include, ip4, ip6, a, mx, exists), and a final qualifier (+all, -all, ~all, ?all). The -all qualifier means a hard fail — any server not explicitly listed is not authorised. The ~all qualifier (softfail) passes the message but notes the policy discrepancy, commonly used during migration periods.
When a message arrives, the receiving MTA (Mail Transfer Agent) extracts the envelope sender domain (the MAIL FROM address, also called the RFC5321.MailFrom address) and performs a DNS TXT lookup for _spf.<domain> or directly on the domain root. The SPF library evaluates each mechanism in order until one matches or the limit of ten DNS lookups is reached (the “SPF PermError” limit defined in RFC 7208 section 4.6.4). The result — Pass, Fail, SoftFail, Neutral, TempError, or PermError — is inserted into the message’s Received-SPF header and passed to the spam filter and any DMARC policy engine.
It is critical to note that SPF authenticates the envelope sender (MAIL FROM), not the visible From header in the message body. This distinction means SPF alone does not prevent display-name spoofing in email clients, which is why DMARC alignment — requiring both SPF and/or DKIM results to match the RFC5322.From domain — is necessary for complete protection.
Where You Encounter It
SPF records appear in any context where email deliverability and sender reputation matter. Transactional email infrastructure operated by services such as Amazon SES, SendGrid, Mailgun, Postmark, and SparkPost requires domain owners to add SPF include mechanisms pointing to the provider’s sending infrastructure before messages will pass authentication checks.
Contest platforms that send email confirmation votes — including Woobox, ShortStack, and custom-built systems using Mailchimp Transactional (Mandrill) — rely on the sending domain having a valid SPF record. Mailbox providers including Google (Gmail), Microsoft (Outlook / Exchange Online Protection), and Yahoo Mail evaluate SPF as an input into their deliverability algorithms. A missing or misconfigured SPF record substantially increases the probability that confirmation emails are silently delivered to spam folders or rejected entirely, causing votes to go unconfirmed.
DNS hosting panels from providers such as Cloudflare, AWS Route 53, GoDaddy, and Namecheap expose SPF TXT record editing through their management interfaces. Diagnostic tools such as MXToolbox SPF Lookup, Google Admin Toolbox, and DMARCIAN’s SPF Surveyor allow domain owners to inspect and validate published records.
Practical Examples
A contest platform sends vote-confirmation emails from [email protected]. The domain votes.example.com has the SPF record v=spf1 include:sendgrid.net -all. When Gmail receives a confirmation message, its inbound SMTP server queries DNS for the SPF record of votes.example.com, expands the sendgrid.net include mechanism, and checks the connecting IP against SendGrid’s authorised server list. If the IP matches, the SPF result is Pass and the message proceeds to the inbox. If the domain had no SPF record, Gmail’s filter would treat the message as unauthenticated, reducing inbox placement probability.
A regional newspaper contest changes its transactional email provider from Mailchimp to Amazon SES without updating its SPF record. Confirmation emails begin failing SPF checks at Microsoft Outlook and are bulk-foldered, causing voters to miss the confirmation window. The contest administrator diagnoses the issue using MXToolbox, adds include:amazonses.com to the SPF record, and deliverability recovers within the DNS propagation window (typically 0–48 hours depending on TTL settings).
Related Concepts
SPF is one pillar of the three-standard email authentication stack: see DKIM for cryptographic signature verification and DMARC for the policy layer that acts on SPF and DKIM results. The practical impact on contest operations is described in Email Confirmation Vote, where deliverability of the confirmation message is the single most critical operational dependency. BIMI (Brand Indicators for Message Identification), a newer standard building on DMARC, allows verified senders to display a brand logo in supporting mailbox providers — an emerging trust signal not covered here.
