What an SPF record is and how receivers use it
SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers may send mail using that domain in the envelope sender, the MAIL FROM address also called the Return-Path. When a receiving server gets a message, it looks up the SPF record for the envelope domain, walks the mechanisms in order, and stops at the first one that matches the connecting IP. The qualifier on that mechanism decides the result: pass (+), fail (-), softfail (~) or neutral (?). If nothing matches, the trailing all mechanism sets the default.
Mechanisms are simple. ip4 and ip6 list addresses or CIDR ranges directly. a and mx say "whatever the A or MX records of this hostname point to". include pulls in another domain's SPF record, which is how you authorize a provider: include:_spf.google.com means "any IP Google publishes may send as me". A domain can have only one SPF record; two records starting with v=spf1 is a permanent error and receivers treat it as no SPF at all.
SPF alone is weak, because the envelope sender is invisible to the reader and easy to set. Its real value comes through DMARC, which checks that the SPF-authenticated domain aligns with the visible From header. That is why a cold email domain needs SPF, DKIM and DMARC together rather than any one of them.
The 10 DNS lookup limit, and why it silently breaks SPF
RFC 7208 caps the number of DNS-querying mechanisms at 10 per evaluation. include, a, mx, redirect, exists and ptr each cost one lookup, and every include is followed recursively, so the includes inside your provider's record count against your total. ip4 and ip6 are free. Exceed the limit and receivers return permerror, which DMARC treats as an SPF failure. There is no warning; the record simply stops working, usually the day a new marketing tool was added.
The generator counts your direct lookups and adds an estimate for the nested includes of each provider. Google Workspace's include, for example, pulls in three netblock records, so it costs about four lookups on its own. The estimates change as providers restructure their records, which is why the tool flags anything at 8 or above as close to the limit rather than waiting for 11.
- Only include providers that send from this exact domain. A CRM that sends from your primary domain has no place in a secondary domain's record.
- Prefer ip4 and ip6 for servers you control; they never count toward the limit.
- If you cannot get under 10, move low-volume tools to a subdomain with its own SPF record.
- Never use ptr. It is deprecated, slow, and counts as a lookup.
Which policy to use: ~all, -all or ?all
The all mechanism sets the result for any IP that matched nothing else. ~all (softfail) says unlisted senders are probably not legitimate; -all (fail) says they definitely are not; ?all (neutral) says nothing. For DMARC purposes softfail and fail are the same, both count as an SPF fail, so ~all loses no protection once DMARC is in place. It does avoid one problem: a few receivers reject mail on SPF -all at connection time, before DKIM and DMARC are evaluated, which breaks forwarded mail that would otherwise have passed on DKIM.
The practical recommendation for cold email domains is ~all together with a DMARC policy that will eventually reach reject. Move to -all only when every sending source has been verified through DMARC reports for several weeks. ?all should never be published; it gives receivers no signal and offers no spoofing protection. +all authorizes the whole internet and is treated by many filters as a spam signal in itself.
SPF for cold email: one record per secondary domain
Since February 2024, Gmail and Yahoo require every sender to authenticate with SPF or DKIM, and senders of 5,000 or more messages a day to a provider to publish SPF, DKIM and DMARC and keep spam complaints under 0.3%. Microsoft applied matching requirements to Outlook.com in 2025. Cold email teams typically spread volume across several secondary domains, and each one is a separate sending domain in the eyes of these rules. Each needs its own SPF record listing only the provider that hosts its inboxes, usually Google Workspace or Microsoft 365.
Do not copy your primary domain's record onto secondary domains. The primary record lists your CRM, billing tool, support desk and newsletter platform, none of which send from the outreach domain, and the extra includes waste lookups and widen the attack surface. A secondary domain record is usually a single include and ~all, well under the limit. After publishing, use the checker above to confirm the live record matches, then set up DKIM and DMARC. ColdBox runs the same verification on every connected domain and alerts you if a record changes or disappears.