Understand what SPF flattening does: it resolves all include:, a:, and mx: mechanisms to their underlying ip4:/ip6: literals at publication time, eliminating DNS lookups from the evaluated record.
Identify the risk before flattening: vendor IP ranges (Google Workspace, Microsoft 365, SendGrid, etc.) change without notice; a manually flattened record goes stale silently, de-authorising legitimate mail.
If you choose manual flattening, set a calendar reminder to re-resolve all vendor ranges at least monthly; compare the new ip4: list against the published record and update immediately on any diff.
For automated flattening, use a hosted service (AutoSPF, PowerSPF, Valimail Instant SPF, or similar) that continuously resolves vendor ranges and updates your DNS record via API; your DNS nameserver must support API-driven record updates.
Consider SPF macros as an alternative to flattening: the %{i} macro embeds the sending IP in a per-lookup DNS query, eliminating large static lists entirely—supported by services like Valimail and some self-hosted setups.
After any change to a flattened record, re-validate the lookup count and test with a real send from each authorised source before declaring the change complete.
Known gotchas
Flattening creates a single point of failure: if the automation service is down or slow, your SPF record may become unresolvable or stale, causing delivery failures at scale.
Flattened records often grow very large; DNS responses exceeding 512 bytes trigger TCP fallback, and some resolvers or intermediaries drop oversized UDP responses—monitor response sizes after flattening.
Subdomains that delegate to the same ESPs need their own SPF records; flattening the apex does not automatically protect mail sent from subdomain identities.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp