You can add multiple senders to a single SPF record by using the include mechanism to reference each sender’s SPF record within your own. A single SPF record can technically reference many senders, but there is a hard limit of 10 DNS lookups before email receivers start failing authentication. Understanding that constraint is the key to configuring SPF correctly when multiple services send on your behalf.
The sections below walk through how the include mechanism works, what happens when you hit the lookup limit, and how to keep your SPF record clean as your sending infrastructure grows.
How many senders can a single SPF record support?
A single SPF record can reference as many senders as you need, but the practical limit is determined by DNS lookups, not the number of entries. The SPF specification caps DNS-resolving mechanisms at 10 lookups per evaluation. Each include:, a, mx, or redirect mechanism that requires a DNS query counts toward that total, regardless of how many IP addresses are ultimately returned.
In practice, most organizations run into trouble between three and six senders. A typical setup might include a transactional email provider, a marketing automation platform, a CRM, and a support tool. Each of those services adds at least one lookup, and some add two or three through nested includes. Before you know it, you are at the limit without having added anything unusual.
The safest approach is to audit your current SPF record before adding a new sender. Tools that resolve your SPF record and count lookups in real time make this straightforward, and the check takes only a few minutes.
How do you add multiple senders using the SPF include mechanism?
To add a sender to your SPF record, use the include: mechanism followed by the sender’s SPF domain. This tells receiving mail servers to fetch and evaluate that sender’s SPF record as part of your own. The basic syntax looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mailchimp.com ~all
Each include: entry points to the sending service’s published SPF record. When a receiver checks your SPF, it follows each include and validates whether the sending IP appears in any of those records. If a match is found, authentication passes.
Steps to add a new sender
- Retrieve the SPF include value from your sending service (usually found in their documentation or DNS setup guide).
- Look up your current SPF TXT record in DNS to see what is already there.
- Count how many DNS-resolving mechanisms are already in use before adding the new one.
- Add the new
include:entry before the final~allor-allqualifier. - Publish the updated record and verify it resolves correctly.
A note on the all qualifier
The qualifier at the end of your SPF record controls what happens when a sender does not match. A softfail (~all) marks unmatched mail as suspicious but still delivers it, while a hardfail (-all) instructs receivers to reject it outright. For most senders, ~all is the safer starting point when you are still consolidating your sender list.
What happens when your SPF record exceeds 10 DNS lookups?
When an SPF record requires more than 10 DNS lookups to fully evaluate, the receiving mail server returns a PermError result. A PermError is treated as an authentication failure by many receivers, which means legitimate mail from any of your authorized senders can be rejected or sent to spam, even if the sending IP is technically listed.
This is one of the most common and frustrating SPF problems organizations face. Because the failure applies to the entire record evaluation, exceeding the lookup limit does not just affect the sender that pushed you over the threshold. It can cause failures across all your senders simultaneously.
The problem is also easy to miss because lookup counts can change without you touching your record. When a third-party sending service updates their own SPF record and adds a nested include, your lookup count increases automatically. Regular SPF audits are the only way to catch this kind of silent drift before it affects deliverability.
How can you flatten or optimize an SPF record with many senders?
SPF flattening is the process of replacing include: mechanisms with the actual IP addresses they resolve to, reducing DNS lookups to near zero. Instead of referencing a sender’s SPF domain, you list their sending IPs directly in your record using ip4: or ip6: entries, which do not count as DNS lookups.
Flattening works well in theory, but it comes with a maintenance trade-off. When a sending service rotates or adds IP addresses, your flattened record becomes outdated and may start failing authentication for that sender. You either need to update it manually or use a service that automates the re-flattening process.
Manual flattening
Resolve each include: domain to its full set of IP addresses using a DNS lookup tool, then replace the include entries with those IPs directly. This works for smaller setups where sender IP ranges change infrequently, and it gives you full control over the record.
Automated SPF management tools
Several tools and services automate SPF flattening by dynamically resolving includes and keeping the IP list current. These typically work by replacing your include entries with a single managed include that they maintain on your behalf. This keeps your lookup count low without requiring manual updates every time a sender changes its infrastructure.
Should you use a subdomain for a secondary sender’s SPF record?
Yes, using a subdomain is a legitimate and often smart way to isolate a secondary sender’s SPF configuration. If you send transactional email from mail.yourdomain.com and marketing email from news.yourdomain.com, each subdomain can carry its own SPF record with its own 10-lookup allowance. This keeps your root domain’s SPF clean and avoids mixing unrelated senders.
Subdomains are particularly useful when a secondary sender has complex SPF requirements of its own, or when you want to limit the blast radius if one sender’s configuration causes problems. A misconfigured or over-limit SPF record on a subdomain will not affect authentication for your root domain or other subdomains.
There are a few things to keep in mind when going this route. The sending service needs to be configured to send from the subdomain address, not the root domain. Your DKIM and DMARC alignment also needs to account for the subdomain, especially if you are using strict alignment policies. Getting all three authentication layers working together across subdomains adds some complexity, but it is manageable with careful planning.
How Email Industries helps with SPF configuration
Managing SPF records across multiple senders is one of the most technically demanding parts of email authentication, and small misconfigurations can have a large impact on deliverability. At Email Industries, we help organizations get this right through hands-on expertise and proven tooling. Here is what we bring to the table:
- SPF audits: We review your current record, count DNS lookups, identify conflicts, and flag senders that may be causing silent failures.
- Record optimization: We help you flatten, restructure, or subdomain-isolate your SPF setup to stay within limits without losing coverage.
- Authentication alignment: We make sure SPF works in concert with DKIM and DMARC across all your sending domains and subdomains.
- Ongoing monitoring: Through our Deliverability Assurance Packages, we keep an eye on authentication health so that third-party changes do not catch you off guard.
- Full-service support: Our broader services cover everything from initial setup to long-term deliverability strategy.
If your SPF record is getting complicated or you are not sure whether your current setup is holding up, we are happy to take a look. Contact us and let’s work through it together.
Related Articles
- What questions should you ask potential full service email agencies?
- What data do you need to transfer during an email platform migration?
- How does migrating email platforms affect your ESP reputation history?
- How do you recover a domain reputation after poor warmup?
- How do you recover from a failed IP warming attempt?
- Can you run IP warming on a shared IP address?
- What happens if you skip domain warmup?
- What types of emails should you send first during IP warming?
- How many IPs do you need to warm up for a large email program?
- What is ecommerce email automation?
- How do you evaluate email marketing agency performance?
- How do email deliverability agencies stay updated on algorithm changes?
- How do deliverability agencies differ from ESP support teams?
- What are the warning signs your email delivery needs expert attention?
- What are the benefits of hiring an email agency?
