Practical troubleshooting guide · The business scenario is illustrative, not a client case study. Administrative changes require authorised access.
A business adds another email-sending tool and an authentication check starts reporting too many SPF lookups. The useful first step is to identify the domain being checked and the services that still send for it. Save the current record before anyone edits DNS. Removing an unfamiliar entry without checking its owner can interrupt another legitimate sending route.
Confirm the domain and the actual error
Collect the diagnostic or Authentication-Results from one affected example. SPF evaluates the relevant envelope-sender domain; the visible From address may differ. Establish which domain failed and whether the result is a permanent error, a policy failure or something else. Under RFC7208, evaluation of DNS-causing SPF terms has a limit of ten, including nested evaluation. This is not a count of how many TXT records you can see. A record that looks short can still include services that perform further lookups.
Build a sender inventory before removing entries
Make one row per sending route: staff email, website notifications, invoicing, booking messages and marketing mail where applicable. Record the service owner, envelope-sender domain, published SPF requirement, last confirmed use and a safe test method. Use the provider’s current documentation rather than an old setup email. Mark an unknown entry for investigation instead of assuming it is obsolete. This inventory is a working record for your administrator; it should not contain account passwords, API keys or customer message bodies.
Evaluate the current record and its dependencies
An administrator should inspect the SPF record for the failing domain and evaluate its nested references. Microsoft documents lookup-causing terms including include, a, mx, exists, ptr and redirect; ip4 and ip6 do not require those lookups. A second SPF record for the same domain is not a way to gain another allowance. Keep the complete original value, test time and evaluator result in the change record. A single tool’s headline result should be checked against the actual sending example and current provider requirements.
Agree a narrow change with a rollback
Google recommends removing duplicate or unused sending references after checking that they are no longer needed. Ask each service owner before retiring an entry. Replacing a provider’s include with a hand-copied list of current IP addresses can become stale when that provider changes its infrastructure. Any redesign of sending subdomains or record management needs a maintained plan. Record exactly what will change, who approved it, the previous DNS value and the rollback condition. Avoid weakening unrelated filtering or authentication policies to silence the error.
Retest the business routes that depend on the record
After an authorised change has propagated sufficiently for the check, evaluate the record again and send harmless tests through each retained route. For each test, record its time zone, receiving system, SPF result and relevant DKIM and DMARC results. Passing SPF alone does not establish DMARC alignment or inbox placement. A website notification and an ordinary staff email may use different domains, so keep their results separate. Retain the diagnostic if the receiving system still reports an error.
Use a record the next administrator can understand
Keep the sender inventory alongside the before-and-after DNS values, approval, test results, unresolved issue and review owner. Add the same check to the next sending-tool onboarding or retirement. This gives a future administrator a reason for each retained reference. If you ask Cyber Bounds to investigate, start with the failing domain, sending tool and error category; agree how to share headers privately. The checklist supports a controlled investigation and does not promise that every message will reach an inbox.
Make it actionable
Your next steps
- Identify the SPF-evaluated domain and preserve the actual diagnostic.
- Save the current DNS value before a change.
- Confirm the owner and purpose of every retained sending reference.
- Evaluate nested lookups and keep one valid SPF record per domain.
- Approve a narrow change, retain rollback and retest each legitimate sending route.
Official reference
Google: Troubleshoot SPF issues
Microsoft: Set up SPF to identify valid email sources
RFC Editor: RFC7208, Sender Policy Framework
Guide date: October 22, 2026. Product features and requirements can change. The business checklists above are practical suggestions from Cyber Bounds.
Put the next step into practice
Help with email deliverability.
Help your quotes, invoices, and everyday messages reach the people waiting for them. Tell us about your situation and we’ll discuss a suitable scope and quote.
Email us about this guide