A legitimate invoice, appointment reminder, or client update can fail an email authentication check for a surprisingly simple reason: your Sender Policy Framework (SPF) record asks the receiving server to look up too many other records. SPF flattening is one way to reduce those lookups. It can help, but only if you understand the maintenance it creates.
The straight answer: SPF flattening replaces some domain references in your SPF record with the actual Internet Protocol (IP) addresses those references currently authorize. That makes the record more direct for receiving mail servers to evaluate.
What is SPF flattening?
SPF is an email authentication standard. It lets you publish a list of servers that are allowed to send email using your domain. The list lives in the Domain Name System (DNS), the public directory that tells internet services where to find domain-related records.
A basic SPF record might authorize your primary mail provider directly. Many businesses, though, send mail through several services: a Microsoft 365 or Google Workspace mailbox, a customer relationship platform, an invoice system, an appointment tool, a marketing platform, or a help desk. Each service may ask you to add an `include` statement to SPF.
An include statement tells a receiving server, in effect, “check this other domain’s SPF record too.” That is convenient because the service maintains its own sender list. But every reference can trigger a DNS lookup.
SPF has a strict limit of 10 DNS lookups during evaluation. If the limit is exceeded, the result is commonly called an SPF PermError, meaning a permanent error in the SPF evaluation. A receiving server may treat that result cautiously, particularly when other signals do not support the message.
Flattening resolves the included records ahead of time and places their approved IP addresses in your own SPF record. Instead of asking a receiving server to follow several chains of includes, the record contains more of the answer upfront.
A simple example
Imagine your current SPF record includes a third-party sending service. That service’s record may include two more domains, and each of those could lead to additional lookups. You may have added only one include, but the total lookup count is determined by the entire chain.
A flattened version replaces that include with the service’s current sending IP addresses, such as `ip4` or `ip6` mechanisms. The receiving server can evaluate those addresses without following the outside chain.
The exact fix is not to flatten every item automatically. First, identify the full lookup path and verify which services actually send mail for your domain.
Why SPF lookup limits matter to business email
An SPF failure does not automatically mean every message goes to spam or gets rejected. Receiving systems consider multiple factors. Still, a broken SPF record removes a useful verification signal and creates an avoidable problem for mail that matters to your business.
SPF also works alongside DomainKeys Identified Mail (DKIM), which uses a cryptographic signature to show that a message was authorized by the signing domain and was not altered after signing. Domain-based Message Authentication, Reporting, and Conformance (DMARC) tells receiving servers how to handle messages that do not meet your authentication policy. DMARC also checks alignment: the domain visible in the From address must align with the domain that passes SPF or DKIM.
That distinction matters. Flattening can reduce SPF lookup problems, but it does not replace DKIM or DMARC. It also does not fix a message sent from an unauthorized platform, a damaged domain reputation, or an incorrect From address.
For a small business, the practical risk is confusion. Your office may believe a vendor is correctly configured because its include statement appears in DNS. Yet SPF can still fail if the combined record exceeds the lookup limit. Staff then see inconsistent delivery, while customers may never know an expected message was filtered or rejected.
When SPF flattening makes sense
Flattening is most useful when your SPF record is approaching or exceeding the 10-lookup limit and you have confirmed that the included service has stable, documented sending infrastructure. It may also help when nested includes make your record difficult to audit.
It is not always the best first move. If old platforms remain in your SPF record after you stopped using them, removing those obsolete entries is safer and simpler than flattening them. Many organizations accumulate SPF includes over time as departments test new tools, switch providers, or keep legacy systems active longer than expected.
Start by asking three practical questions: Which platforms send email using our domain? Which entries are no longer used? How many DNS lookups does the complete record require?
You should also confirm that you have only one SPF record. Publishing multiple SPF TXT records for the same domain can cause an SPF PermError. Combining all authorized senders into one correctly structured record is required before flattening can help.
The trade-off: flattened records can become stale
An include statement has a useful advantage. When a mail provider changes its sending IP addresses, its own SPF record can reflect that change. Your domain benefits automatically because it still points to the provider’s record.
A flattened record does not update itself unless you use a managed flattening process that regularly refreshes it. If the provider adds, removes, or retires IP addresses, your flattened list can become outdated. Mail from a newly added provider address may then fail SPF because your domain no longer authorizes it.
This is the central trade-off. Flattening lowers lookup use, but it shifts update responsibility toward you or the system managing your DNS.
Manual flattening can be reasonable for a small, stable configuration with one provider and clear change procedures. It becomes riskier when several vendors send mail, vendors change infrastructure often, or no one owns routine DNS review. In those cases, an automated service or a managed process can keep the IP list current, but it still needs monitoring and documentation.
Keep the original sources documented. Record each service, why it is authorized, the SPF mechanism it supplied, the date it was reviewed, and the person responsible for approving changes. This turns a mysterious DNS entry into an operational record your IT team can maintain.
How to approach SPF flattening safely
Before changing DNS, inventory every system that sends email as your domain. Include individual mailboxes, website forms, accounting software, marketing tools, support platforms, copiers, and applications that send system notices. A platform that sends only a few messages each month can still cause a real delivery issue when its authorization disappears.
Next, inspect your current SPF record and count DNS-querying mechanisms across all includes and redirects. Do not rely only on the number of visible includes in your own record. Nested records count too. Also review the ending policy. An SPF record commonly ends in `~all` or `-all`, but changing that policy without confirming all valid senders can create failures for legitimate mail.
Then choose the least complex correction. Remove obsolete services first. Where active services still push you over the limit, flatten only the entries that need it. Preserve records for other email authentication controls, and do not overwrite unrelated DNS entries while editing SPF.
After publishing the change, test mail from every authorized sending path. Check whether SPF passes, whether the passing domain aligns with the visible From domain for DMARC, and whether DKIM is present where your provider supports it. DNS changes can take time to appear everywhere because of caching, so document the change and retest after the record is broadly visible.
Common SPF flattening mistakes
The most common mistake is treating flattening as a one-time repair. It is an ongoing configuration choice. If nobody checks for provider IP changes, a record that works today can fail later.
Another mistake is flattening every service without first deleting unused senders. This produces a larger, harder-to-read record and can create record-length issues. DNS TXT records have formatting limits, and long SPF records may need to be split correctly by your DNS provider while remaining one logical SPF policy.
Finally, do not confuse SPF authorization with permission to send any type of mail. SPF verifies sending infrastructure. It does not make unwanted, misleading, or poorly configured messages trustworthy. Your sending practices, recipient expectations, content, DKIM, and DMARC still matter.
If you are unsure whether your SPF record exceeds lookup limits or contains stale services, run MailArrive’s free email health check and review the Report Card for a clear domain grade and the exact SPF issue to address. If the needed fix requires DNS or mail server changes your team cannot safely make, Matano IT can handle the remediation.