SPF Record Generator

Set up SPF the right way

SPF tells the world which servers are allowed to send email as your domain. Get it wrong — or miss a sender — and your legitimate cold emails can land in spam or be rejected.

This generator assembles a valid SPF record from the providers you actually use, so you don't have to remember the exact include syntax for Google, Microsoft, SendGrid and the rest.

SPF is one part of deliverability

SPF, DKIM and DMARC together authenticate your domain — but authentication alone won't save you if you email invalid addresses and rack up bounces.

Verify every recipient with Emailchaser's free email verifier to keep your bounce rate low and your sender reputation healthy.

SPF record syntax and mechanisms explained

Every SPF record is a single line that begins with v=spf1 and ends with an all mechanism. In between you list mechanisms that authorise senders: include pulls in another domain's SPF (this is how you add Google, Microsoft or an ESP), a authorises whatever your domain's A record points to, mx authorises the servers in your MX records, and ip4 / ip6 authorise specific addresses or CIDR ranges. The generator above wires these together for you, but knowing the pieces makes troubleshooting far easier.

The all mechanism at the end sets the default for any sender that didn't match, and the symbol in front of it is the qualifier: - means fail (hard), ~ means softfail, ? is neutral and + is pass. The same qualifiers can prefix any mechanism, though you rarely need them anywhere but all. A finished record for a domain that sends through Google Workspace and SendGrid plus one in-house server reads: v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.10 ~all — meaning Google, SendGrid and 192.0.2.10 are allowed, and everything else should be treated as suspicious.

Provider includes hide more than they show. include:spf.protection.outlook.com is a single entry that covers all of Microsoft 365, whereas include:_spf.google.com expands into three nested includes behind the scenes, so one visible line can quietly cost several DNS lookups — which matters for the limit below.

The SPF 10-DNS-lookup limit

SPF caps the number of DNS lookups a record may trigger at 10 (RFC 7208). Every include, a, mx, ptr, exists and redirect counts toward that budget, and nested includes count too — so a record with five providers can pass ten without ever looking long. Crucially, ip4 and ip6 cost nothing to evaluate, and neither does all, because they need no DNS query.

Exceed ten lookups and the record returns a PermError: receivers stop evaluating and treat your SPF as broken, which can push legitimate mail to spam and breaks DMARC alignment on the SPF side. To stay under the limit, remove includes for providers you no longer use, swap an include for a direct ip4 range when a sender publishes fixed IPs, and avoid stacking overlapping marketing tools. SPF flattening — expanding includes into raw IP addresses — technically frees up lookups, but it's fragile: providers change their sending IPs without notice, so a flattened record silently rots and starts failing legitimate mail.

Common SPF record mistakes to avoid

The single most common breakage is publishing two SPF records. A domain may have only one TXT record starting with v=spf1; a second one — often left over from an old provider — turns the whole result into a PermError. Merge every sender into one record instead. The same applies to the all mechanism: it must appear exactly once, at the very end, because anything placed after all is ignored.

Other frequent mistakes: putting the record on the wrong host (SPF belongs on the exact domain that appears after the @ in your From address, and subdomains do not inherit the root's SPF), jumping straight to -all before every sender is listed, which bounces your own mail, and using the deprecated ptr mechanism, which is slow and unreliable. Watch length as well — a single TXT string maxes out at 255 characters, so a long record has to be split into several quoted strings inside the same record, never into multiple records.

How to add and check your SPF record in DNS

Copy the generated record into a new TXT record at your DNS host. For the root domain, set the host or name field to @ (some registrars want it left blank or the bare domain — they all mean the apex), leave the type as TXT, paste the full v=spf1 ... ~all string as the value, and save; a TTL of 3600 seconds is fine. If a subdomain sends mail on its own — say mg.example.com for Mailgun — it needs its own SPF record published on that subdomain.

Changes take effect on the record's TTL, usually within an hour. To confirm it's live, run dig TXT example.com or nslookup -type=txt example.com and look for the v=spf1 line, or drop your domain into Emailchaser's email deliverability test, which checks SPF, DKIM and DMARC together and flags a lookup count creeping toward the limit. Once SPF is done, the DKIM record generator and DMARC record generator cover the other two records receivers look for.