Alright, let's say you've accumulated ESPs like they're trading cards. Marketing swore each one was "best-in-class" for a different use case—transactional, newsletters, promotions, alerts, and probably one for sending "happy birthday" emails that nobody reads.
Now you're staring at your DNS, realizing SPF has a hard limit of 10 DNS lookups, and you've got five vendors plus your own infrastructure. The classic "too many cooks" problem, but for your domain's reputation.
The common advice is to chain includes, but that's a house of cards. Vendor A includes B, which includes C, and suddenly you're five lookups deep before you've even added your own mail servers. One vendor changes their SPF record and your delivery tanks because you blew the lookup limit.
So, what's the *actual* play here?
1. Audit first. Do all five ESPs *actually* send mail for your domain, or did you just add them during a PoC two years ago? I've seen records with includes for services the company hasn't used since the last rebrand.
2. Consider flattening. Some providers offer dedicated IPs and will give you a static SPF record (a simple `ip4:` entry). That's zero lookups. Push for it. It turns a vendor lookup into a single, static line.
3. The nuclear option: a dedicated subdomain for each high-volume ESP. It's more setup, but it isolates reputation and keeps each SPF record simple. The "newsletters.yourdomain.com" subdomain only needs to know about its one ESP.
Are we still trying to make the monolithic, five-vendor SPF record work, or is that just asking for intermittent failures that are impossible to debug? I'm skeptical of any "best practice" that involves delicate lookup chains.
cg
cg
I'm the sales ops lead at a 250-person SaaS shop that sends a stupid amount of email. We've got Salesforce for CRM and five ESPs in prod: SendGrid, HubSpot, Braze, Amazon SES, and our own Postfix servers.
1. **Real SPF Lookup Count.** Vendor SPF includes are often nested mines. A single `include:spf.protection.outlook.com` can eat 3-4 of your 10 lookups itself. You need to audit every `include` with a checker like MxToolbox. Our "simple" Braze include chain was five lookups deep.
2. **Flattening Feasibility and Cost.** Getting a static IP record (like `ip4:192.0.2.0/24`) from your ESP is the win, but it's a paid add-on or enterprise-tier feature. For SendGrid, that's a dedicated IP at $90+/month. For transactional stuff, it's worth it. For the birthday emails, it's not.
3. **Vendor SPF Volatility.** They change their SPF infra, you break. We had a 12-hour delivery blackhole because a vendor added a new `include` that pushed us over 10. The bigger the vendor (Microsoft, Google), the more their SPF record is a moving target you can't control.
4. **The Redirect Alternative.** Some ESPs offer a `redirect=` modifier instead of `include`. It's still one lookup, but it's cleaner - you're just pointing to their final record. Fewer vendors support it. It's less common but ask for it.
You need to pick your battles. Dedicated IP flattening for your high-volume, reputation-critical streams (probably transactional). For the rest, consolidate if you can and accept the lookup risk, or move to a subdomain. I'd push for a dedicated IP from your primary transactional ESP and move low-volume marketing to a subdomain like `news.yourdomain.com`.
If your budget is tight, tell us your monthly send volume for each stream. If you can't use subdomains, say why.
CRM is a necessary evil
You're spot on about the audit first step. I've seen orgs with SendGrid and Mailchimp includes that haven't sent a single email from them in two years, but nobody cleaned up the DNS. It's a simple win that costs nothing.
One thing I'd add to your flattening point: even if you get dedicated IPs from your ESPs, watch out for their failover setups. Some vendors will give you a `ip4:` for your dedicated IP, but then also include a broader `include:` for their fallback pool. That eats a lookup anyway. You have to explicitly ask them to exclude the fallback from your SPF record, or accept that you might lose delivery if your dedicated IP goes down.
Also, there's a quieter pain point: SPF's 10-lookup limit isn't the only constraint. Some DNS providers have a 512-byte response limit for UDP queries, and if you flatten everything into a massive list of IPs, you'll hit that before you hit the lookup limit. I've seen records with 40 `ip4:` entries that still fail validation because the response gets truncated. So flattening isn't a cure-all, it just moves the bottleneck.
What's your approach when a vendor refuses to give you a static IP and you're already at 7 lookups?
Keep it constructive.