SPF Record

What is an SPF record?

An SPF (Sender Policy Framework) record is a DNS entry that lists which mail servers are authorized to send email on behalf of your domain. Email’s original design let anyone put any address in the “From” field — there was no built-in check that a message claiming to be from [email protected] actually came from your company’s servers, which is exactly what spammers and phishers exploit. An SPF record closes part of that gap: you publish, in DNS, the list of IP addresses/servers allowed to send mail for your domain, and receiving mail servers check incoming messages against it. If mail claiming to be from your domain arrives from a server not on the list, that’s a red flag for forgery. It’s one of the three interlocking email-authentication standards — SPF, DKIM, and DMARC — that together fight email spoofing.

How it works, and why SPF alone isn’t enough

An SPF record is a specially-formatted TXT record in your domain’s DNS (e.g., v=spf1 include:_spf.google.com include:sendgrid.net -all), where the mechanisms list authorized senders (your own mail servers, plus third-party services you send through like Google Workspace, a marketing platform, or a transactional-email provider) and the ending qualifier tells receivers how strict to be (-all = hard fail anything not listed, ~all = soft fail/mark suspicious). When a receiving server gets a message, it looks up the sending domain’s SPF record and checks whether the connecting server’s IP is authorized. But SPF has real limitations that mean it can’t stand alone. Critically, SPF validates the “envelope” sender (the return-path), not the “From:” header the user actually sees — so an attacker can pass SPF for a domain they control while still displaying a forged, look-alike From address to the recipient, defeating the intuitive purpose. SPF also breaks on forwarding: when a message is forwarded, the forwarding server becomes the sender, which usually isn’t in the original domain’s SPF record, causing legitimate forwarded mail to fail SPF. These gaps are precisely why the three standards work together: DKIM adds a cryptographic signature that survives forwarding and ties the message to the domain, and DMARC ties it all together — it tells receivers to check that the visible From domain aligns with the SPF/DKIM-authenticated domain, closes the “validates the wrong address” gap, and lets the domain owner publish a policy (monitor, quarantine, or reject) plus receive reports on who’s sending as their domain.

Why it matters and how it’s done right

Getting email authentication right is important for two reasons: security (preventing criminals from convincingly impersonating your domain in phishing, which protects your customers and your brand) and deliverability (mailbox providers increasingly require proper SPF/DKIM/DMARC and will send unauthenticated mail to spam or reject it — Google and Yahoo now mandate it for bulk senders, so misconfigured authentication directly hurts your legitimate mail reaching inboxes). The correct approach is to publish all three: an accurate SPF record listing every legitimate sending source, DKIM signing on your mail, and a DMARC policy — typically starting at p=none (monitor mode, gathering reports to discover all your legitimate senders) before tightening to quarantine or reject once you’re confident nothing legitimate is being caught. The recurring mistakes are specific and common: treating SPF as sufficient on its own (it isn’t — without DMARC alignment, attackers still spoof the visible From); forgetting to include a third-party sender (a new marketing tool or SaaS that sends “as” your domain but isn’t in your SPF record, causing its legitimate mail to fail); exceeding SPF’s 10-DNS-lookup limit (too many include: mechanisms causes SPF to break entirely); and jumping straight to a strict -all/DMARC reject policy without first monitoring, which can silently block real mail.

What people get wrong

• Relying on SPF alone — it checks the envelope sender, not the visible From address, and breaks on forwarding; only SPF + DKIM + DMARC together actually stop spoofing.
• Missing a legitimate sender: forgetting to add a third-party service (marketing, CRM, support tool) to your SPF record makes its real mail fail authentication and land in spam.
• Going strict without monitoring — enforcing hard-fail SPF or DMARC reject before confirming all your legitimate senders pass can silently block real email; start in monitor mode.

Primary source: RFC 7208: Sender Policy Framework (SPF)