A real-format record, read left to right
Take this record for a business that uses Google Workspace for staff mail, Amazon SES for app notifications, and one office server: v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.25 ~all. The two includes come from Google's own example of combining senders; the IP address is a reserved documentation address standing in for yours. [2]
A receiving server evaluates the terms from left to right and stops at the first one that matches the connecting IP. [1]
| Term | Type | What it does | RFC 7208 reference |
|---|---|---|---|
| v=spf1 | Version | Marks the TXT record as SPF. It must be exactly v=spf1; v=spf10 does not match. [1] | Section 4.5 |
| include:_spf.google.com | Mechanism | Runs SPF against Google's record. Matches only if that check returns pass. [1] | Section 5.2 |
| include:amazonses.com | Mechanism | Same, against Amazon SES's record. [1] | Section 5.2 |
| ip4:203.0.113.25 | Mechanism | Matches if the connecting IP is in that address or CIDR range; no extra DNS lookup. [1] | Section 5.6 |
| ~all | Qualifier plus mechanism | Always matches, so every other IP gets softfail. Terms after all are ignored. [1] | Sections 4.6.2 and 5.1 |
Qualifiers: what ~all, -all, ?all and +all return
Every mechanism can carry a qualifier. With no qualifier, the default is +, which means pass. [1] That default is why a bare all, or +all, is dangerous: it authorizes every server on the internet to send as you.
The choice that matters in practice is ~all versus -all. Softfail is a weak statement by the domain owner that the host is probably not authorized. [1] Fail is an explicit statement that it is not, and RFC 7208 notes that fail results can be used to reject messages during the SMTP transaction. [1] Google recommends ~all in the SPF record for Google Workspace. [2]
If you publish DMARC, the gap between the two narrows. DMARC only counts an SPF pass on an aligned domain; softfail and fail are both non-passes, and a message can still pass DMARC on an aligned DKIM signature. [5] Our recommendation for a small sender: use ~all, put the effort into DKIM on your own domain for every platform, and let DMARC carry enforcement.
| Ending | Result for unlisted servers | When it fits |
|---|---|---|
| ~all | softfail | Most small senders; Google's recommendation [2] |
| -all | fail | Domains whose senders are all listed and DKIM-signed, or domains that never send mail |
| ?all | neutral | Rarely useful; it says nothing about unlisted servers [1] |
| +all or all | pass | Never: it authorizes everyone [1] |
The one-record rule
RFC 7208 is explicit: multiple SPF records are not permitted for the same owner name, and if a receiver finds more than one, check_host() returns permerror. [1] A permanent error is not a pass, so every sender on the domain loses SPF at once, not just the newest one.
This is the most common SPF mistake on small domains, because each platform's setup screen shows a complete record. MailerLite's Namecheap instructions say there should be only one SPF record at a time and tell you to remove other records that start with v=spf1. [4] The safe reading of that advice is merge, then remove: copy the other record's mechanisms into one combined record before deleting anything.
Two related limits: the separate SPF DNS record type is discontinued, so publish SPF only as TXT; and redirect= or exp= may each appear only once. [1]
Worked example: merging three senders into one record
Starting point: over time, three people each followed a different setup screen, and the domain now has three TXT records at @. The first says v=spf1 include:_spf.google.com ~all. The second says v=spf1 include:amazonses.com ~all. The third says v=spf1 ip4:203.0.113.25 -all. Receivers return permerror for all three. [1]
Merge in four steps. First, keep one v=spf1 at the start. Second, list every include and ip4 or ip6 term once, in any order. Third, choose one all at the end; mixing ~all and -all is impossible in a single record, so pick ~all unless you have a reason not to. Fourth, publish the result as one TXT record and delete the other two.
Result: v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.25 ~all. Each include and any a or mx term counts toward SPF's 10-lookup limit, and nested includes count too; ip4 and ip6 do not. [1] If your merged record grows past that, see our guide to fixing too many SPF lookups.
Publishing it at Namecheap
- Open Domain List, Manage, Advanced DNS. If the tab is missing, your DNS is hosted elsewhere and the record goes there. [3]
- Add a TXT record with Host @ for the root domain. For a sending subdomain such as news.example.com, the Host is just news. [3]
- Google says each sending subdomain needs its own SPF record; the root record does not cover it. [2]
- Default TTL is 30 minutes, so changes can take that long to be seen. [3]
- Very long records must be split into several quoted strings of up to 255 characters each, which receivers join without spaces. [1]
Pre-publish checklist
- Exactly one TXT record at the name starts with v=spf1.
- No ptr mechanism; RFC 7208 says it should not be published. [1]
- Exactly one all, at the very end.
- No +all or bare all.
- Includes copied exactly from each provider's documentation or setup screen.
- Lookup count at 10 or fewer.
- DKIM set up on your own domain for each platform, so DMARC does not depend on SPF alone.
Questions before you decide
Should I use ~all or -all?
Google recommends ~all for Google Workspace domains. RFC 7208 defines ~all as softfail, a weak statement that a server is probably not authorized, and -all as fail, which receivers can use to reject during the SMTP transaction. Under DMARC, neither softfail nor fail counts as an SPF pass.
What happens if my domain has two SPF records?
RFC 7208 says multiple SPF records are not permitted for the same name, and if a receiver finds more than one, the SPF check returns permerror. Merge the mechanisms into one record that starts with v=spf1 and ends with a single all.
Do subdomains inherit the root SPF record?
No. SPF is looked up at the exact domain being checked. Google says that if you use subdomains, you must add an SPF record for each subdomain that sends mail.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- RFC 7208: Sender Policy Framework (SPF) Accessed 30 Oct 2026
- Google Workspace Admin Help: Set up SPF Accessed 30 Oct 2026
- Namecheap Knowledgebase: How do I set up host records for a domain? Accessed 30 Oct 2026
- MailerLite Help: How to authenticate a domain in Namecheap Accessed 30 Oct 2026
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.