SPF Record

SPF Record: What It Is & How It Works

An SPF record is a DNS text entry that tells receiving mail servers which IP addresses and servers are authorised to send email on behalf of a domain. It’s the first layer of email authentication — a published list that lets any incoming mail server check whether an email truly came from a trusted source before deciding what to do with it.

Sender Policy Framework (SPF) is used to authenticate the sender of an email. With an SPF record in place, internet service providers can verify that a mail server is authorised to send email for a specific domain. An SPF record is a DNS TXT record containing a list of the IP addresses that are allowed to send email on behalf of a domain.

The analogy that tends to make it click: think of SPF records like a guest list managed by a door attendant. If someone is not on the list, the door attendant won’t let them in. Similarly, if an SPF record doesn’t have a sender’s IP address on its list, the receiving server will either not deliver those emails or mark them as spam.

How SPF Works

The process happens automatically, in milliseconds, every time an email is received.

When a receiving server gets an email, it takes the return-path domain and looks up its SPF record. If it finds one, it searches the record for the sending server’s IP address. If the IP address is listed, the SPF check passes, and the email goes through. If it isn’t listed, the SPF check fails — and the email is rejected or marked as spam, depending on the record’s policy.

One important technical detail: SPF checks the return-path (also called the envelope sender or MAIL FROM address) — not the visible “From” address that appears in someone’s inbox. That distinction matters for understanding SPF’s limitations, which we’ll get to shortly.

What an SPF Record Looks Like

SPF records are stored as DNS TXT records and written in a specific syntax. A typical example:

v=spf1 include:_spf.google.com ip4:192.0.2.0 -all

Breaking it down:

• v=spf1 — identifies this as an SPF record. Every SPF record must start with this.
• include: — references another domain’s SPF record (useful for third-party senders like Google Workspace, Mailchimp, or SendGrid)
• ip4: — directly lists an authorised IPv4 address
• The final -all, ~all, or ?all — the policy tag, which tells receiving servers what to do with any email that doesn’t match the list:
  • -all (hard fail) — reject unauthorised mail
  • ~all (soft fail) — accept but flag as suspicious, likely routing to spam
  • ?all (neutral) — take no action, effectively treating SPF as absent

One critical rule: a domain can only have one SPF record. Multiple SPF records on the same domain cause authentication failures — all authorised senders must be consolidated into a single record.

SPF’s Known Limitation: Forwarding

SPF is effective, but it has one well-known weak point. Forwarding of email happens constantly on the internet, and the SPF mechanism doesn’t survive the forwarding process. When someone forwards an email to a different address, your email appears to come from infrastructure that has nothing to do with you — causing SPF to fail even for completely legitimate messages.

This is precisely why SPF is designed to work alongside DKIM, which uses a cryptographic signature that survives forwarding, and DMARC, which coordinates both and enforces a consistent policy. SPF alone provides useful protection, but it’s the combination of all three that creates a complete authentication layer.

The 10-Lookup Limit

One of the most common SPF problems organisations run into is exceeding the DNS lookup limit. When a receiving email system queries an SPF record, it can only perform up to 10 DNS lookups — each include: statement counts toward this limit. If the number of lookups exceeds 10, the message fails SPF with a permanent error, and the receiving server may reject or bounce it.

Businesses using multiple third-party sending services — a marketing ESP, a CRM, a transactional email provider, a customer support tool — can hit this limit surprisingly quickly. Consolidating and flattening SPF records is a common maintenance task as an organisation’s email infrastructure grows.

Why SPF Matters

SPF prevents email spoofing, which protects a domain from being misused by malicious actors sending phishing or spam emails. It enhances email deliverability by validating emails and reducing the chance of them being marked as spam. And it improves domain reputation with ISPs and email clients, increasing the likelihood that emails will be successfully delivered.

Since 2024, Google and Yahoo both require SPF for senders sending bulk email. Without it, campaigns face filtering, bouncing, or outright rejection. And without SPF, DMARC — which depends on SPF and DKIM passing — can’t be properly enforced.

Key Takeaways

• An SPF record is a DNS TXT entry that lists all IP addresses and servers authorised to send email on behalf of a domain — acting as a published allowlist that receiving servers check before delivering mail.
• It works by comparing the sending server’s IP address against the list in the record — a match means the email passes; no match means it fails and the policy tag determines what happens next.
• SPF alone has limitations — it doesn’t protect the visible “From” address from spoofing, and it breaks when email is forwarded, which is why it works best as part of a broader authentication stack with DKIM and DMARC.
• A domain can only have one SPF record — multiple records cause authentication failures — and the record is limited to 10 DNS lookups.
• Google and Yahoo now require SPF for bulk senders, making it a baseline requirement for email deliverability rather than an optional security measure.