It is safe when it is maintained. The risk with flattening is staleness, not the technique — a record that is re-resolved continuously tracks vendor changes, while a hand-built one silently rots. That maintenance is the part we automate.
Smart SPF
SPF lists who may send mail for your domain. It also has a hard ceiling of ten DNS lookups, and most growing organisations hit it without noticing.
Every include: in your SPF record costs a DNS lookup, and the services you include bring their own. Add Microsoft 365, a marketing platform, a helpdesk, a payroll system and an e-signature tool, and you can cross ten lookups without adding a tenth entry.
Past that limit the result is PermError. Receiving servers stop evaluating and treat SPF as failed — for all your mail, including the legitimate kind. Worse, it fails quietly: nothing in your DNS looks wrong, and the only symptom is deliverability slowly getting worse.
DMARCS resolves your full include chain, flattens it to the underlying networks, and publishes a single record that stays within the limit. You keep one hostname in your DNS and the platform maintains what sits behind it.
Because vendors change their sending infrastructure without telling anyone, the record is re-resolved continuously. When a provider adds a network, your record follows automatically instead of failing silently until someone notices.
Lookup limit enforced
DNS record to manage
Manual flattening
Most teams try this once with a spreadsheet and a text editor.
It works on the day you do it. Flattening replaces vendor includes with the IP ranges behind them, which is fine until one of those vendors moves to a new range — at which point their mail starts failing SPF and nobody connects the two events.
It also removes the safety net. A hand-flattened record is a static snapshot with no owner and no review date. Six months later nobody remembers which ranges belong to which service, so nothing can safely be removed and the record only grows.
Automating it keeps the benefit and removes the decay. The record reflects what your vendors publish today, not what they published the afternoon someone had time to rebuild it.
Something not covered here? Talk to our team.
It is safe when it is maintained. The risk with flattening is staleness, not the technique — a record that is re-resolved continuously tracks vendor changes, while a hand-built one silently rots. That maintenance is the part we automate.
Yes. You add the service in the platform and the published record updates. The point is that you stop editing raw DNS for routine sender changes, which is where most SPF outages originate.
No. SPF breaks on forwarded mail and only checks the envelope sender, which recipients never see. It is one input to DMARC alignment, not a defence on its own — which is why we treat it as part of a DMARC rollout rather than a standalone product.
It is the result when SPF evaluation exceeds ten DNS lookups or hits a syntax fault. Receivers stop processing and treat the check as failed, so legitimate mail is affected as much as forged mail.
