An SPF record is a TXT DNS record that lists which mail servers are allowed to send email for your domain. When a receiving server gets a message, it checks the sender's SPF record to confirm the source is authorized. This helps stop spoofing and protects your domain's sending reputation.
What is an SPF record?
SPF stands for Sender Policy Framework. It is a published list, stored in DNS, of the IP addresses and services allowed to send mail using your domain. Receiving servers read it during delivery to decide whether the sending source is legitimate. Without SPF, anyone can forge your domain in the From line more easily.
SPF was built to solve one narrow problem: unauthorized servers sending mail that claims to come from you. It does not encrypt anything and it does not check the message body. It answers a single question. Is this sending IP on the approved list for this domain? That answer feeds into spam filtering and, later, into DMARC.
How do receiving servers evaluate SPF?
The receiving server looks at the envelope sender domain (the Return-Path), queries that domain's SPF TXT record, and compares the connecting IP against the record's rules. It reads left to right and stops at the first match. The final mechanism decides the result: pass, fail, softfail, or neutral.
The check runs against the Return-Path domain, not the visible From address. This is an important distinction. A message can pass SPF while still showing a spoofed From header to the reader, which is exactly why DMARC exists to tie the two together. SPF alone validates the envelope path.
Each SPF evaluation is capped at 10 DNS lookups. Mechanisms like include, a, mx, ptr, and exists each count against that limit. Go over 10 and the record returns a permerror, which many servers treat as a failure. Nested includes from multiple vendors are the most common way domains blow past the cap.
How do you read an SPF record?
Read an SPF record left to right, one mechanism at a time, stopping at the first match. A record starts with the version tag, lists authorized sources, and ends with an all mechanism that sets the default for everything else. The qualifier in front of each mechanism decides pass or fail.
Here is a typical record: v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.7 ~all. That authorizes Google Workspace, SendGrid, and one specific IP, then soft-fails everything else. The pieces break down like this.
| Element | Example | Meaning |
|---|---|---|
| Version tag | v=spf1 | Marks the record as SPF version 1. Required first. |
| include | include:_spf.google.com | Authorizes another domain's sending servers, usually a vendor. |
| ip4 / ip6 | ip4:198.51.100.7 | Authorizes a specific IP address or range. |
| a / mx | mx | Authorizes the hosts named in the domain's A or MX records. |
| Pass qualifier | + | Explicit pass. The default if no qualifier is written. |
| Softfail | ~all | Accept but mark as suspicious. The common safe default. |
| Fail | -all | Reject anything not listed. Strict, use once you are confident. |
The all mechanism at the end is the catch-all. ~all (softfail) tells receivers to accept unlisted sources but flag them. -all (hardfail) tells them to reject. Start with ~all while you confirm every legitimate sender is covered, then tighten to -all once you trust the list.
Check your list right now, free
10 checks a day with no signup. 100 a day with just your email.
What are the most common SPF misconfigurations?
The frequent SPF mistakes are exceeding the 10 DNS lookup limit, publishing more than one SPF record, forgetting a sending vendor, and ending with the wrong all qualifier. Each one either breaks authentication or leaves a gap that lets spoofed mail slip through. Most are quick to spot and fix.
- Too many DNS lookups. Every include and mechanism counts toward the cap of 10. Stacking Google, a CRM, a support tool, and a marketing platform can push you over, triggering a permerror. Flatten unused includes or consolidate vendors.
- Two SPF records on one domain. Only one v=spf1 TXT record is allowed per domain. A second record produces a permerror. Merge all mechanisms into a single record instead.
- Missing senders. Email service providers, help desks, invoicing tools, and cold outreach platforms all send on your behalf. Leave one out and its mail soft-fails or hard-fails. Audit every source before tightening to -all.
- Defaulting to +all. Ending with +all authorizes the entire internet to send as your domain. It defeats the point of SPF entirely. Never publish it.
- Relying on ptr. The ptr mechanism is deprecated, slow, and unreliable. Receiving servers may ignore it. Replace it with explicit ip4 or ip6 entries.
How does SPF fit with deliverability?
SPF is one leg of email authentication. DKIM signs the message, and DMARC ties SPF and DKIM back to the visible From domain with a policy. A domain that passes all three earns more trust from inbox providers and sees fewer messages land in spam. Skip SPF and you hand filters a reason to doubt you.
Authentication sets the stage, but list quality decides the outcome. Sending to dead addresses spikes your bounce rate, and a bounce rate above 2% signals trouble to Gmail and Microsoft no matter how clean your DNS is. Verify addresses before you send. You can paste a list or drop a CSV into our Free Email Verifier and get Deliverable, Risky, and Invalid verdicts in seconds, with the file parsed in your browser so nothing gets uploaded.
Fix the records once, then keep the list healthy on an ongoing basis. Teams that want the pipeline built and kept warm for them can lean on Synthisia for done-for-you outreach, but the authentication basics here are worth owning yourself. Publish a clean SPF record, add DKIM and DMARC, verify before every send, and your legitimate mail reaches the inbox.