SPF flattening is the practice of replacing include: mechanisms with explicit ip4: and ip6: ranges, eliminating DNS lookups at the cost of taking on maintenance responsibility. This article explains when flattening is appropriate, how to do it safely, the operational trade-offs, and how to decide between manual, scripted and hosted flattening services for a UK business.
SPF's 10-lookup limit is the immediate driver. A domain that needs to authorise Microsoft 365, Google Workspace, Mailchimp, SendGrid, Salesforce, a marketing automation tool and a monitoring platform will routinely sit at 12 or more lookups — above the ceiling. Without flattening, the only alternatives are reducing the number of senders (organisationally difficult) or switching to a hosted SPF service (commits to a vendor dependency).
Flattening trades DNS lookups for IP-address specificity. An include: costs at least one lookup but shields you from upstream change; an ip4: range costs zero lookups but freezes the list of authorised IPs at the moment you captured them. The whole engineering question of flattening is how to trade those two costs in a way that fits the organisation's appetite for DNS change management.
Conceptually, flattening replaces this:
v=spf1 include:spf.protection.outlook.com -allwith this (after expanding Microsoft's current IP ranges):
v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14
ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 -allBehind the scenes, the expansion process:
spf.protection.outlook.com.ip4:, ip6: ranges directly.include:, recurse — fetch that domain's SPF, and so on.a or mx mechanism, resolve to the underlying IP addresses.v=spf1 ... string.The emitted record is lookup-free (or near-lookup-free, depending on whether you retained any a/mx mechanisms) and valid under RFC 7208.
For a one-off flattening exercise on a small UK business domain, the manual process takes about an hour:
dig TXT firm.co.uk and record the exact record. Save this as the rollback baseline.include:. For each, drill down to identify the IP ranges it ultimately authorises.dig TXT spf.protection.outlook.com and any _netblocks records it contains. Gather every ip4: and ip6: range.a and mx mechanisms. Note the current A and MX results. These may need updating too if underlying infrastructure changes.v=spf1 at the start and your ~all or -all at the end.Manual flattening does not scale beyond the first deployment. A scripted approach lets you re-run the expansion regularly without human effort:
Open-source tooling for this includes spf-flattener (Python), unfuck-spf (Go), and several vendor-neutral scripts hosted on GitHub. The typical UK small-team deployment is a GitHub Actions workflow that runs weekly and opens a pull request on the infrastructure repository when ranges have drifted.
The scripted approach captures most of the benefit of flattening while offloading the drift-detection problem to automation. The remaining risk is that the automation itself fails — a broken cron job that silently fails to update a record for three months is as dangerous as not flattening at all. Alerting on job success (not just failure) is essential.
Commercial platforms offer managed SPF flattening as a service. You publish a single include: pointing at their macro, and they maintain the underlying range expansion for you.
v=spf1 include:spf.vendor.com -allBehind that include, the vendor resolves to a continuously-updated list of IP ranges matching your configured upstream senders. When Microsoft rotates its ranges, the vendor updates the macro within hours; your SPF automatically inherits the change without any local action.
| Vendor | Offering | Notes |
|---|---|---|
| Valimail Monitor | Hosted SPF (with DMARC reporting) | Enterprise-focused; strong UK public sector footprint. |
| EasyDMARC | Hosted SPF plus DMARC | SMB-friendly pricing. |
| Red Sift Pulse | Full email posture management including SPF | UK-founded; used by UK financial services. |
| dmarcian | Hosted SPF tool alongside DMARC reporting | One of the oldest DMARC-focused vendors. |
| Autospf | Dedicated SPF flattening service | Niche; low cost. |
| Provider | Change cadence | Flattening recommendation |
|---|---|---|
| Microsoft 365 | 3-4 times a year | Hosted service preferred; manual flattening requires quarterly audit. |
| Google Workspace | 2-3 times a year | Hosted service strongly preferred — nested macros change often. |
| Amazon SES | 1-2 times a year | Manual flattening acceptable with annual review. |
| SendGrid | Rarely | Manual flattening acceptable. |
| Mailchimp | Rarely | Manual flattening acceptable. |
| Salesforce | Several per year (nested) | Hosted service preferred. |
| SmartXHosting email | Managed centrally | No flattening needed — include:_spf.smartxhosting.uk is a stable single-lookup include. |
| On-premises mail server | Under your control | Use ip4: directly; no flattening needed as you already know the IP. |
Flattening is not a one-off event. Sustainable operations require:
The most common failure mode. Provider rotates IPs, your flattened record is not updated, mail from the new IPs fails SPF.
Mitigation: scripted or hosted flattening, DMARC aggregate report monitoring, quarterly audits.
If your flattening expands include:spf.protection.outlook.com to Microsoft's entire IP space rather than just the Exchange Online outbound ranges, you may be authorising any Microsoft customer's mail to pass SPF on your domain. This breaks the security model.
Mitigation: rigorously follow the actual mechanism expansion — do not substitute broader ranges. Hosted services handle this precisely.
An aggressively flattened SPF can exceed the 450-byte safe limit. Beyond this, DNS truncation, TCP fallback and some caching resolvers behave unpredictably.
Mitigation: CIDR aggregation, removal of unused senders, subdomain partitioning of sender classes.
A flattening cron job that fails silently for months produces the same outcome as never having flattened at all.
Mitigation: positive-confirmation alerting (alert on success, not failure), scheduled manual verification quarterly.
A flattened SPF is harder to read. An engineer looking at the record cannot quickly see "we send through Microsoft 365, Mailchimp and SendGrid" — they see a list of IP ranges.
Mitigation: maintain a separate, human-readable sender inventory document. Most hosted services provide this as part of their admin UI.
include:_spf.smartxhosting.uk macro is centrally managed and consumes one (rarely two) DNS lookups regardless of backend infrastructure changes. Customers on Business Email or Business Email Server plans can rely on the include as a stable, low-cost anchor for their SPF — then flatten or add ranges only for non-SmartXHosting senders if the lookup count demands it.
The question "should I flatten?" has no universal answer. Use this framework to decide for a specific UK domain:
| Condition | Points |
|---|---|
| Current SPF lookup count is over 10 | +5 (mandatory action) |
| Current count is 8-9 (approaching the ceiling) | +3 |
| Current count is under 7 | 0 (no action needed) |
| More than half your senders are big-cloud providers (Microsoft, Google) | -3 (favour hosted service over manual) |
| Most senders have stable IP ranges (smaller providers, on-premises) | +2 (manual flattening viable) |
| Team has CI/CD DNS automation | +2 (scripted flattening viable) |
| Team has no DNS automation, no capacity for new process | +3 for hosted service, -3 for manual |
| Budget exists for a paid hosted service | +2 for hosted |
| Regulated sector (financial services, healthcare, public sector) | +2 for hosted (audit trail), -1 for manual (risk) |
If the total leans positive for hosted, buy a service. If it leans positive for scripted, invest in automation. If you are at zero, wait — the problem might solve itself through sender consolidation.
| Approach | Lookup cost | Maintenance | Risk | Cost |
|---|---|---|---|---|
| Status quo (include-based, under 10 lookups) | 1-9 | Low | Low | £0 |
| Manual flattening (one-off) | 0-1 | Very high — manual quarterly review | High — drift between reviews | £0 in direct cost, staff time only |
| Scripted flattening (automated) | 0-1 | Medium — automation maintenance | Medium — automation failure risk | Engineering setup time, minimal ongoing |
| Hosted flattening service | 1-2 | Low — vendor-managed | Low — vendor SLA | £50-£500/month typical |
| Sender consolidation (fewer senders) | Lower baseline | Low once done | Low | Licence consolidation savings offset |
| Subdomain partition (sender per subdomain) | Each subdomain has own 10 budget | Medium — per-subdomain SPF | Low | DNS management only |
An underused strategy: rather than flattening a single domain's SPF, split senders across subdomains. Each subdomain publishes its own SPF, each gets its own 10-lookup budget, each can have its own DMARC policy.
firm.co.uk. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
news.firm.co.uk. IN TXT "v=spf1 include:servers.mcsv.net -all"
invoices.firm.co.uk. IN TXT "v=spf1 include:sendgrid.net -all"
alerts.firm.co.uk. IN TXT "v=spf1 include:_spf.pagerduty.com -all"Four domains, each at 1-3 lookups, none at risk of hitting the ceiling. The trade-off is coordination: every sending service has to be configured to use its dedicated subdomain as the From: address, and users need training to recognise that invoices come from [email protected] rather than [email protected].
For UK organisations with multi-brand structures or many independent SaaS senders, subdomain partitioning often scales better than flattening.
Q: Is flattening standards-compliant?
A: Yes. RFC 7208 places no restriction on which mechanisms are used — a flattened record built from ip4: and ip6: is as compliant as one built from include:. The resulting evaluation behaves identically from the receiver's perspective.
Q: Will flattening improve my deliverability?
A: Only if you were failing SPF evaluation (PermError) due to the 10-lookup limit. Flattening removes that failure mode. If SPF was already passing, flattening has no deliverability impact.
Q: How big can a flattened SPF record get before it becomes a problem?
A: The practical safe size is around 450 bytes including quotes and separators. Under a modern EDNS0 setup you can go to 4,096 bytes, but some older resolvers truncate at 512 bytes. Aim small; split into subdomains if you are pushing size.
Q: If I use a hosted flattening service, does my SPF look different to receivers?
A: Yes — to receivers, your SPF simply becomes v=spf1 include:vendor.com -all. They do not know flattening is happening behind the scenes. Evaluation behaves normally; the lookup budget is whatever the vendor's macro consumes.
Q: Can I mix flattened IP ranges with include: mechanisms?
A: Yes, and this is a common pattern. Flatten the providers that rarely change (SendGrid, Mailchimp, Postmark, your own infrastructure), keep include: for providers that change often (Microsoft, Google). Best of both worlds.
Q: Does flattening affect how DMARC reports look?
A: No. DMARC aggregate reports show source IPs and SPF results; they do not care how the SPF record was constructed. Reports look identical whether you use includes or flattened ranges.
Q: If I switch email provider, do I have to re-flatten?
A: Yes. Any change to the set of underlying senders requires re-flattening. This is one of the maintenance costs of the approach.
Q: Can flattening increase security as well as fix deliverability?
A: Marginally. By enumerating specific IP ranges rather than following nested includes, you have more visibility over exactly who is authorised. But a stale flattened record is less secure than a live include, because it may continue to authorise ranges the provider has moved away from (and which might now be used by someone else).
Q: How do I audit a hosted SPF service is working correctly?
A: Inspect the current expansion through the vendor's admin UI. Cross-check by resolving the published macro with dig and confirming the IP ranges match your expected senders. Most vendors provide a changelog of expansion updates.
Q: What is the expected lifecycle of a flattened SPF?
A: Treat it as a living artefact. Review every 90 days at minimum. Any time you onboard a new sender, update the flattened record. Any time DMARC reports show a SPF failure for a known sender, investigate and update. Done properly, a flattened SPF is as reliable as an include-based one — just with more operational rigour required.
Q: Do UK regulators view flattened SPF differently from include-based SPF?
A: No. The ICO, NCSC and sector regulators care about the outcome — that your domain has effective email authentication — not the implementation mechanism. Both flattened and include-based approaches are acceptable.
Q: Can I partially flatten a record — keep some includes, hard-code others?
A: Yes, and this is often the practical compromise. Keep include: for the stable, reliable macros (major providers with good macro discipline) and hard-code ip4: for legacy senders that have no include. Total lookup count drops without taking on all the maintenance overhead.
Q: What happens to DKIM and DMARC when I flatten SPF?
A: Neither is affected. SPF, DKIM and DMARC are independent records. Flattening SPF leaves DKIM selectors and DMARC policies untouched.
Q: If a hosted SPF vendor's service is slow or unreliable, does that affect my email deliverability?
A: Yes — SPF evaluation happens during the SMTP conversation, so any delay in the vendor's DNS response delays mail acceptance. Serious vendors publish their DNS response times and SLAs; check these before committing. Multi-homed DNS infrastructure and global Anycast are the table stakes.
Q: Are there any UK-specific legal or compliance considerations around hosted SPF services?
A: Minor. Using a hosted service means that a third party sees which providers you send through, which is generally low-sensitivity information. For organisations subject to particular data residency rules (some public sector bodies, Ministry of Defence suppliers), check the vendor's data-handling locations and ensure they meet your requirements. For the vast majority of UK businesses there is no compliance concern.