SPF is a receiver evaluation: not a badge you win by shortening a string
An SPF policy tells a receiver which hosts may use a domain in an SMTP identity. The receiver evaluates that policy for a message using the connecting IP and MAIL FROM domain, or HELO in specified cases. A record can look tidy yet fail because its includes exceed processing limits or return an error.
The useful reframe is to diagnose the evaluation path. RFC 7208 defines mechanisms, qualifiers, recursion, result codes and limits. RFC 7208 ‘Oversized SPF’ might mean too many DNS-querying terms, an overlong DNS response, an include chain containing several policies, or a provider label that needs its own definition. These conditions do not share one universal repair.
Begin with a real bounce or trusted authentication result. Copy the SPF identity, connecting IP, result and reason. Do not assume the visible From domain was evaluated. Fixing the root domain when the message uses bounce.supplier.example changes the wrong policy. Save the evidence and name the application route before opening DNS.
The most common SPF mistake is treating the record as a character-count problem: a tool flags it “oversized” or a host says “too many lookups”, and somebody shortens whatever term looks longest. But an SPF policy is a set of authorisation rules a receiver evaluates, so the fix that works follows the evaluation path: the connecting host, the MAIL FROM identity and the include chain: not a character limit. Understanding why your domain is flagged mattering is the backbone of getting SPF right alongside DKIM.
Query the exact DNS name from the message
Retrieve TXT for the SPF identity using a command-line DNS client or a browser tool such as Google Admin Toolbox Dig. Google Admin Toolbox Dig Record the resolver, UTC time, complete answer and TTL. Query an authoritative nameserver as well as a recursive resolver when propagation or split DNS is suspected.
Find TXT strings whose combined value begins v=spf1. Long TXT data may be displayed as quoted chunks even though it forms one logical record, so do not mistake chunks for duplicates. A genuine duplicate means two separate SPF policies at the same owner name.
Confirm the DNS panel’s record name. A value intended for mail.example.co.uk can be accidentally published at mail.example.co.uk.example.co.uk when the interface appends the zone. Save the fully qualified answer, not only a dashboard screenshot.
Do not paste full private zone exports into public checkers or tickets. Public SPF records are already visible, but exports can include verification tokens, internal names and unrelated service information. Share only the queried name and relevant public answers.
For a domain that should never send, compare the existing policy with the non-sending domain protection guide before replacing it.
Merge duplicate policies only after you know who each entry authorises
RFC 7208 requires the SPF record-selection result to be one record; multiple records produce a permanent error. SPF record selection Receivers do not merge two policies in the order shown by your DNS provider. Deleting one at random can restore syntax while silently removing a legitimate sender.
Copy both policies into a change note. For each include, a, mx, ip4, ip6, exists or redirect, identify the system, business owner, provider documentation and recent message evidence. Mark unknown entries for investigation, not automatic retention or deletion.
Construct one proposed policy containing only confirmed routes. Preserve qualifier intent and place the final all mechanism deliberately. An all mechanism matches every address; terms after it cannot authorise a later service. Do not copy two complete strings together, because that can put one policy’s -all in the middle.
Stop if any active route lacks an owner or evidence. Use your sender inventory and provider logs to close the gap before publication. A temporary permanent error is harmful, but an uninformed merge can create both delivery failures and excessive authorisation.
Two SPF records almost always mean one of them was added by a supplier or inherited from an earlier setup, not that your domain simply has two lists. Merging them safely is an ownership exercise: identify who each include belongs to before you delete anything, because removing the wrong one silently drops a legitimate sender. That inventory-first discipline is shared with diagnosing SPF that passes for the wrong identity.
Walk the DNS-dependent mechanism tree
Underline every term that can cause a DNS query. RFC 7208 places a limit of ten terms involving include, a, mx, ptr, exists and redirect during one evaluation, and a receiver returns permanent error when that limit is exceeded. SPF processing limits
Follow each include recursively. Count evaluated DNS-querying terms in the route the receiver follows, not merely the includes visible on the first line. An included policy can contain more includes, a or mx lookups. DNS errors and void answers also have defined limits and can make an otherwise short-looking policy unreliable.
Record the tree with owner, purpose and result. Do not use a web tool’s single red number without saving its expanded path and test conditions. Different connecting IPs may follow different mechanisms, so test the actual IP from the message.
The ten-term limit is not a target. Leave operational headroom for provider changes where possible. If a supplier’s published include chain consumes unexpected depth, ask that supplier for its supported current design rather than altering its records or copying addresses from an incidental DNS answer.
Remove stale senders only after proving retirement
For each mechanism, ask whether the service still sends using this exact envelope domain. Confirm through service configuration, recent controlled headers, provider events and the business owner. A platform may still be needed for password resets even after its marketing account appears unused.
Retiring an include can reduce lookup depth and authorisation scope, but the saving is a consequence of accurate inventory, not the sole reason for removal. Record the owner’s confirmation, last observed use and rollback value. Disable sending in the application before removing DNS authorisation where the change process allows.
Avoid automatic ‘flattening’ that replaces provider includes with their current IP addresses. It can reduce DNS evaluation at one moment, but transfers change tracking to you. Shared services can alter networks, and stale flattened data may reject legitimate mail or keep old infrastructure authorised. Use only a provider-supported approach with explicit refresh ownership and monitoring.
Also question broad a and mx mechanisms. They authorise addresses returned by DNS, which may include web or inbound systems not intended to send. Replace them only when route evidence and provider documentation support a narrower mechanism.
Retiring an old supplier or platform is usually safe enough that its SPF include can go: but only once you have confirmed it no longer sends as that envelope domain, for example for password resets. When a domain genuinely sends no mail at all, the same evidence-gathering approach underlies securing a parked or inactive domain.
Prepare one policy with an explicit rollback
Save the current public answer, authoritative answer, DNS-provider representation and TTL. Draft the new policy in a review note. Check syntax, term order, lookup tree, expected result for every known sending IP and behaviour for an unauthorised test address. Have another administrator compare it with the sender inventory.
Choose qualifiers intentionally. -all states fail for unmatched hosts, while ~all produces softfail; the receiver decides local handling. Do not soften a policy simply to hide a permanent error. Correct the structure first and choose policy according to the domain’s owned sending design.
Publication has a trade-off. One comprehensive root-domain policy can be easy to locate but accumulates dependencies from unrelated suppliers. Purpose-specific envelope subdomains can isolate ownership and lookup budgets, but add DNS, reporting and lifecycle work. Redesign only with the affected services, not during an emergency typo repair.
Set the rollback trigger: legitimate same-route failure, wrong public name, unexpected permanent error or impact on another verified sender. Name who can restore the old value. If no one can approve or execute rollback, stop before saving.
Publish once and query the public result again
Replace the duplicate or broken policy with the reviewed single record at the intended owner name. Do not edit unrelated TXT verification records. Save the DNS audit event and UTC time. Remember that resolvers may keep the previous answer until its TTL expires.
Query the authoritative service and at least one independent recursive resolver. Confirm exactly one logical v=spf1 answer, the expected full string and the intended TTL. Expand the lookup tree again from public DNS. Check for syntax errors, loops, temporary DNS failures and permanent-error conditions.
Use Google Admin Toolbox Dig as one reproducible browser query if needed, but compare it with raw DNS output rather than treating any single interface as authoritative. Google Dig Record the result so another administrator can repeat it.
If public answers differ after the previous TTL window, stop. Investigate delegation, multiple DNS providers, split-horizon configuration or edits made in a non-authoritative panel. Repeatedly saving the same value will not correct a delegation problem.
After a repair, querying the public result and re-walking the lookup tree from real DNS is what proves the change took effect. Whether you are reading this SPF result or a DMARC alignment in the same message, knowing your way around email headers makes the whole verification quick and trustworthy.
Prove every retained route and escalate on uncertainty
Send one plain, non-sensitive message through each business-critical route affected by the policy to a mailbox you control. Keep application, account, envelope domain and visible From address representative. Open the received original and record the trusted SPF result, smtp.mailfrom identity and observed IP.
For the incident route, compare the new result with the original. The repair is proved when the exact policy evaluates without error and the authorised IP receives the expected SPF result. Also confirm DMARC separately; an SPF pass for an unaligned domain may not satisfy it. Verify bounce handling and one unauthorised laboratory IP result only in a system you control.
Monitor provider events after publication and keep the sender inventory current. A route that cannot be tested should remain an explicit risk with an owner and review date, not be silently declared healthy. Recalculate the DNS-querying path whenever a retained supplier changes its published policy, because your root record can remain byte-for-byte identical while the nested evaluation becomes deeper or starts returning errors. Record that dependency beside the supplier rather than copying its current addresses into the root policy.
Stop and escalate if lookup depth depends on undocumented supplier chains, a provider’s include is broken, an unknown sender remains, or several critical systems would need simultaneous changes. Supply the specialist with the original result, full public policy, expanded tree, message identity and planned rollback. SPF is repaired when the real evaluation is explainable and repeatable, not when a string becomes shorter.