What 550 5.7.1 Means
Per RFC 7208 §4.6.4, an SPF record must require no more than 10 DNS lookups during evaluation. Each include:, a:, mx:, ptr:, and exists: mechanism counts toward the limit. Recursive includes also count. If evaluation exceeds 10 lookups, receivers return PermError and treat the result as authentication fail. Combined with DMARC enforcement, this becomes 550 5.7.1.
All major receivers enforce the 10-lookup limit. Gmail and Microsoft 365 are especially strict — they return PermError immediately and fail the message under DMARC.
Your SPF record has accumulated too many include: directives from multiple sending platforms (each platform's include itself recursively includes others); a vendor's SPF chain grew over time pushing the total past 10; or duplicate includes from migrating between platforms without removing the old.
How to Fix 550 5.7.1
- 1
Count current lookups in your SPF record
Use the SPF Generator at coldrelay.com/tools/spf-generator and paste your current SPF record. The tool walks the include chain and reports the total lookup count. Anything 10 or above is failing; anything 8-9 is at risk if vendors expand their chains.
- 2
Audit which platforms are still in use
List every include: in your SPF and ask: am I actually still sending through this platform? Common bloat: SendGrid include from a marketing campaign 3 years ago, a Mailgun include from a transactional sender you switched away from, a SaaS tool's outbound that no longer exists. Remove anything you don't actively send from.
- 3
Consolidate to fewer sending platforms
Cold email infrastructure ideally consolidates outbound to one or two platforms. If you're sending cold via ColdRelay, marketing via a marketing platform, and transactional via a separate provider, your SPF needs all three. Consider consolidating cold + marketing under ColdRelay's infrastructure to reduce the SPF chain.
- 4
Use SPF macros or alternative DNS structure
Some vendors offer 'flat SPF' records — they publish a single IP list rather than a chain of nested includes. If your vendor offers this option, switching can drop your lookup count significantly. Tools like dmarcian's SPF flattener also exist, but flattening means manual updates whenever vendor IPs change.
Note: Don't manually inline ip4: blocks from a vendor's record. Vendor IPs change; if you hard-code them you'll silently fail when they rotate.
- 5
Verify the fix with the Email Deliverability Test
After consolidating, run the Email Deliverability Test at coldrelay.com/tools/email-deliverability-test. SPF should pass without PermError. If you still see PermError, the chain is still over the limit — keep removing includes.
References
550 5.7.1 in the Cold Email Context
SPF PermError is the natural failure mode for businesses that accumulate sending tools over time without auditing SPF. Each new tool adds an include: directive, and the chain silently grows toward the 10-lookup limit until one day it tips over and everything breaks. The structural fix is consolidating outbound sending to fewer, more capable platforms. ColdRelay's outbound infrastructure covers cold email, warmup, and dedicated transactional volume from one include — replacing 3-4 separate vendor includes in many setups. The Domains page in the dashboard flags any domain whose SPF is at risk (8+ lookups) before it tips into PermError, so you can intervene before mail breaks.
Frequently Asked Questions
What counts as a DNS lookup in SPF?
Every include:, a:, mx:, ptr:, and exists: counts as 1. Recursive includes count too — if you include vendor.com and vendor.com itself includes 3 more domains, that's 4 lookups. ip4: and ip6: don't count because they don't trigger DNS resolution.
Why is the limit 10?
RFC 7208 set the limit to protect receivers from amplification attacks via malicious SPF chains, and to bound evaluation cost. Modern receivers enforce strictly because the alternative — unlimited recursion — could be exploited.
Can I work around the limit with SPF flattening?
Yes, but with downsides. Flattening manually copies the vendor's current IPs into your record as ip4: blocks. It works until the vendor changes their IPs, at which point you silently start sending unauthorized mail. Some commercial SPF flatteners auto-update; for production cold email, that's the only safe form of flattening.
Does PermError fail closed or fail open?
PermError is a definitive 'fail' under modern DMARC. Combined with p=reject, receivers reject. Combined with p=quarantine, receivers send to spam. Combined with p=none, receivers usually still deliver but flag authentication as failing. Treat PermError as a hard fail and fix it.