Hosted SPF flattening

SPF is the oldest of the three email-authentication standards, and it is the one most likely to break quietly. It works by listing which mail servers are allowed to send for your domain. The catch is a hard limit of ten DNS lookups, and once you add a few SaaS senders you sail past it without noticing. When that happens your SPF returns a permerror, receivers stop trusting it, and your DMARC starts failing too. This page explains how SPF is evaluated, how the lookup limit traps growing organisations, and how hosted, auto-flattened SPF keeps you compliant without hand-editing a TXT record every time a provider changes its IP ranges.

What SPF actually does

SPF stands for Sender Policy Framework, defined in RFC 7208. It is a single TXT record published at the root of your domain that starts with v=spf1 and lists the sources permitted to send mail using your domain in the envelope. A simple record looks like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Each mechanism tells a receiving mail server something different. ip4: and ip6: name addresses directly. a and mx authorise the hosts in your A and MX records. include: pulls in another domain's SPF record, which is how SaaS providers hand you their sending infrastructure. The final mechanism, all, is the catch-all that decides what happens to everything not matched above.

How a receiver evaluates SPF

When a message arrives, the receiving server looks at the envelope sender, also called the Return-Path or MAIL FROM, not the address your recipient sees in their inbox. It takes the domain from that envelope sender, fetches that domain's SPF record, and checks whether the connecting IP address is authorised. The evaluation walks through your mechanisms left to right and returns one of several results: pass, fail, softfail, neutral, none, temperror, or permerror.

The result that matters most for deliverability is the one nobody plans for: permerror. It means the record could not be evaluated correctly, and the most common cause by far is exceeding the DNS lookup limit.

The ten-DNS-lookup limit

RFC 7208 caps the number of DNS lookups an SPF evaluation may perform at ten. Mechanisms that trigger a lookup include include:, a, mx, ptr, and exists:, plus any redirect= modifier. Crucially, the count is recursive. If you include a provider whose SPF record itself contains three more includes, all of those count against your ten.

The limit exists to stop a single SPF check from hammering DNS, but it was set in an age when most organisations sent mail from one or two systems. A modern company sends from many.

Why it is so easy to exceed

Count the lookups in a realistic small-business setup. You run Microsoft 365 for staff email, you use Google Workspace for one acquired team, you send invoices through a CRM, your support desk replies from a help-desk tool, and marketing goes out through a campaign platform. Each one hands you an include:, and several of those includes expand into multiple nested includes behind the scenes. Five providers can easily resolve to twelve or more lookups, and you never see the nesting because it lives in the providers' records, not yours.

This is what makes the limit so deceptive. Your own record might contain only five or six mechanisms, which looks safe at a glance. The lookups that tip you over are hidden one or two levels down, inside records you do not control and cannot edit. A syntax checker that reads your record will tell you it is valid. A receiver that resolves it fully will tell you it is broken. Those two answers disagree precisely because the cost lives in the expansion, not the text.

A worked example: creeping past ten

Here is a record that looks tidy and still fails. We will count the lookups it generates, including the nested ones.

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:spf.mandrillapp.com include:servers.mcsv.net include:_spf.salesforce.com include:helpscoutemail.com ~all

Six includes, twelve lookups, and the record is over the limit before you have added a single direct IP. The owner did nothing wrong. They added the providers their business needed, one at a time, and the eleventh and twelfth lookups arrived silently when Google or another provider added an include to its own record. The result is permerror, and SPF now fails for every message, even mail from legitimate senders that should have passed.

Why permerror also breaks DMARC

DMARC passes a message if either SPF or DKIM passes and aligns with the visible From domain. If your SPF is in permerror, the SPF half of that test is gone. Now every message has to rely on DKIM alone. That is fine if your DKIM signing is solid across every sending source, but it rarely is on day one, and forwarded mail that strips your only working signal will then fail DMARC outright.

So a broken SPF record does not just dent SPF. It removes one of the two pillars DMARC stands on, which makes any move toward a DMARC enforcement policy of p=quarantine or p=reject far riskier than it should be.

SPF flattening, and the maintenance trap

The standard fix is flattening. Instead of leaving an include: in place, you resolve it down to the underlying IP ranges and publish those as ip4: and ip6: mechanisms. IP mechanisms cost zero DNS lookups, so a flattened record can authorise dozens of sending IPs while staying well under ten.

The idea is sound. Done by hand it is a trap. Providers change their IP ranges whenever they please, and they do not tell you. The day Microsoft or your marketing platform rotates a block of addresses, your hand-flattened record points at IPs they no longer use and stops pointing at the ones they do. Legitimate mail starts failing SPF, and you are back to chasing a deliverability problem you thought you had solved months ago. A flattened record is only as current as the last time someone remembered to re-resolve it.

How DMARC Engine hosts and auto-flattens SPF

We host your SPF record and keep it correct for you. You point one DNS entry at us, and from then on we manage the contents.

• We resolve your includes to their current IP ranges and publish a flat record that stays comfortably under the ten-lookup limit.
• We re-check the upstream sources on a schedule. When Microsoft 365, Google Workspace, your CRM or any other provider changes its published ranges, we pick up the change and update your record automatically. No manual re-flattening.
• You keep adding and removing senders by editing a managed list, not by counting lookups in your head or auditing nested includes.
• If an upstream change would push you toward the limit or drop a sender, we surface it rather than letting your record fail quietly.

The result is an SPF record that behaves like a static, lookup-free one but tracks reality. You get the deliverability of flattening without the perishable maintenance that makes hand-flattening dangerous. When you onboard a new sender or retire an old one, you change a managed list rather than re-resolving ranges and re-counting lookups at two in the morning before a campaign goes out.

The limits of SPF on its own

Even a perfect SPF record cannot carry email authentication by itself, for two structural reasons.

SPF does not survive forwarding

When a message is forwarded, the forwarding server connects from its own IP, which is not in your SPF record, so SPF fails at the final destination. Mailing lists and ".forward" rules break SPF constantly. This is the single biggest reason you cannot rely on SPF alone, and it is why DKIM, which travels with the message as a signature, matters.

SPF ignores the address your recipient sees

As noted above, SPF authenticates the envelope domain, not the visible From header. A message can pass SPF and still display a spoofed brand in the inbox. Only DMARC alignment ties authentication back to the From domain your customer actually reads.

For both reasons, SPF is necessary but not sufficient. Pair it with DKIM signing so authentication survives forwarding, and put DMARC on top to enforce alignment and collect reports.

SPF best practice

• Publish exactly one SPF record. Two v=spf1 TXT records on the same domain is itself a permerror. Merge them into one.
• Use ~all (softfail) while you stabilise, then move to -all (hardfail). Softfail asks receivers to accept-but-mark unauthorised mail; hardfail tells them to reject it. Tighten to -all once you are confident every legitimate source is listed, and lean on DMARC to enforce the outcome.
• Remove nested and redundant includes. If you no longer use a provider, drop its include. Every stale include: spends lookups you will want back.
• Avoid ptr entirely. It is slow, unreliable, and deprecated by RFC 7208.
• Watch the lookup count, not just the syntax. A syntactically valid record can still fail on lookups, which is the failure mode tools that only check syntax miss.

SPF at a glance

See where your SPF stands

If you run more than two or three sending services, there is a real chance your SPF record is already at the edge of the limit or past it, and you simply have not been told. A free scan resolves your record exactly as a receiver would, counts every lookup including the nested ones, and shows you whether you are in permerror today. From there you can hand the record to us to host and flatten, or fix it yourself with the lookup count in front of you.

SPF is straightforward in principle and quietly fragile in practice. The lookup limit punishes growth, hand-flattening rots as providers re-IP, and a record stuck in permerror drags your DMARC down with it. Hosting and auto-flattening turn it back into the set-and-forget control it was meant to be, so SPF does its job and lets DKIM and DMARC do theirs. Run a scan, see your real lookup count, and decide from facts rather than guesswork.