SPF Record Setup Guide

Sender Policy Framework (SPF) is an email authentication standard (RFC 7208) that lets a domain owner publish, in DNS, the list of mail servers authorized to send email for that domain. When a receiving mail server accepts a message, it looks up the SPF record of the domain in the SMTP envelope sender — the MAIL FROM address, also called the Return-Path — and checks whether the connecting IP is on the authorized list.

Without SPF, any server on the internet can open an SMTP connection and claim to be sending for your domain. SPF is the first of the three core email-authentication mechanisms (SPF, DKIM, DMARC) and is a prerequisite for DMARC to be useful: DMARC can only pass via SPF when SPF both passes and aligns with the visible From: domain.

A critical point that trips up many administrators: SPF validates the envelope sender (MAIL FROM / Return-Path), not the From: header that recipients actually see. A message can pass SPF for one domain while displaying a completely different domain in the From: header — which is exactly why DMARC alignment exists.

1. A sending server connects to the recipient's MX and issues MAIL FROM:<bounce@​yourdomain.com>. 2. The receiving server extracts the domain (yourdomain.com) and queries DNS for its SPF record — a single TXT record at the root of that domain that starts with v=spf1. 3. The receiver evaluates each mechanism left to right against the connecting IP address. Recursive mechanisms (include:, a, mx, redirect=, exists:) trigger additional DNS lookups. 4. The first mechanism that matches the connecting IP determines the result, combined with its qualifier (+pass, ~softfail, -fail, ?neutral). If nothing matches before the all mechanism, the all qualifier applies. 5. The result — pass, fail, softfail, neutral, none, permerror, or temperror — is recorded in the Authentication-Results header and fed into DMARC evaluation.

SPF says nothing about message content and provides no cryptographic guarantee — it is purely an IP-to-domain authorization check at connection time.

An SPF record is a single DNS TXT record published at the root of your domain. It always begins with the version tag and ends with an all mechanism:

Each mechanism can carry a qualifier prefix. The default qualifier is + (pass) when none is written. These are the mechanisms and qualifiers you will actually use:

Copy-paste examples for common providers. Replace IPs and includes with your own senders:

The trailing all mechanism is the catch-all for any IP that did not match an earlier mechanism. It is the single most consequential choice in your record:

• ~all (softfail) — receivers accept the message but treat it as suspicious. This is the correct starting point: it lets DMARC observe failures without bouncing legitimate mail you may have forgotten to list. • -all (hardfail) — receivers reject unauthorized mail outright. Move here only after DMARC aggregate reports confirm every legitimate sender is covered. • ?all (neutral) — makes no assertion; offers no spoofing protection. Avoid except during early diagnostics. • +all (pass) — authorizes the entire internet to send as your domain. This is never correct and actively harmful.

1. Inventory every system that sends mail using your domain: your mailbox provider (Google Workspace, Microsoft 365), transactional/marketing platforms (SendGrid, Mailgun, Mailchimp), helpdesk and CRM tools, and any on-premise mail server. 2. Build a single record that authorizes all of them, preferring ip4:/ip6: for servers you control and include: for managed providers. 3. In your DNS provider, add a TXT record: - Name/Host: @ (or the bare domain / blank, per your provider's convention) - Type: TXT - Value: your full v=spf1 ... ~all string - TTL: 3600 4. Save and allow time for propagation, then confirm with a checker.

SPF allows a maximum of 10 DNS lookups during evaluation (RFC 7208 §4.6.4). The mechanisms include:, a, mx, exists:, and redirect= each consume lookups, and include:/redirect= also count every lookup performed inside the referenced policy recursively. Exceed 10 and the result is permerror — which DMARC treats as an SPF failure, silently breaking authentication.

Counting rules: • include: = 1 lookup + all lookups inside that policy (a single provider include can hide 3–5 nested lookups) • a = 1 lookup • mx = 1 lookup, plus 1 per returned MX host that must be resolved • ip4: and ip6: = 0 lookups

The practical fix is to replace include: chains with the underlying ip4:/ip6: ranges (SPF "flattening") for senders whose IP space is stable, and to remove includes for services you no longer use.

After publishing, confirm the record resolves, parses, and stays within the lookup limit before tightening the policy. Verify it with our free SPF Checker, which counts your DNS lookups and flattens the include graph, and build or edit your record with the SPF Record Generator.

Once SPF passes and aligns, the next layer is DKIM — a cryptographic signature that survives forwarding and gives DMARC a second, independent way to pass.