Introduction
What SPF is and why it matters for UK businesses
SPF failures are usually not your DNS provider’s fault—they’re almost always caused by too many DNS lookups or conflicting records that you’ve inherited from previous email providers. If your mail keeps bouncing or landing in spam, a misconfigured SPF is often the culprit, and it’s fixable in under an hour.
A well configured SPF record sits alongside DKIM and DMARC. Together, they strengthen email authentication and reduce the chances of messages being marked as spam or rejected by recipient systems.
- Protects brand reputation by reducing spoofed messages
- Improves inbox placement with major providers
- Supports legal and regulatory expectations around data and payments
The current landscape of email authentication in the UK and globally
Globally, providers like Google, Yahoo, and Microsoft increasingly enforce authentication for bulk senders. This means a broken SPF record can block legitimate communication with customers. In the UK, many SMEs rely on Microsoft 365 or third party email gateways, making a correctly configured SPF essential.
- Bulk senders face stricter requirements to prove legitimate sources
- DNS record health directly affects deliverability and customer reach
- Ongoing audits are needed to keep SPF aligned with changing sending sources
Practical steps to harden SPF without slowing you down
Start with a current inventory of all sending sources, including marketing platforms, CRM systems, and transactional email services. For each source, add its authorized sending IPs or include mechanisms that cover entire domains.
- Run a test by sending emails from every authenticated source to internal accounts and verify that none fail with SPF or DKIM alignment errors.
1. SPF basics: how SPF works and what can go wrong
SPF syntax essentials and common misconfigurations
SPF uses a DNS TXT record to declare approved sending hosts. The record begins with v=spf1 and ends with an on or -all qualifier. Common mistakes include multiple SPF records, syntax errors, and missing or overly broad qualifiers.
Real world example: a mid market business runs services from on-prem mail servers and a cloud marketing platform. Their SPF must unify both sources without creating conflicts or DNS lookups drag.
Practical steps to tighten SPF:
- Consolidate to a single v=spf1 record that lists all sending IPs and includes only from trusted domains.
- Prefer -all for strict enforcement once you verify sources, or ~all during testing.
- Limit DNS lookups by avoiding excessive includes and using ip4/ip6 blocks where possible.
Understanding mechanisms (include, ip4, ip6, all) and qualifiers
The include mechanism adds another domain’s SPF policy to your own. The ip4 and ip6 mechanisms specify allowed address ranges. The all mechanism functions as a catchall for any source not matched previously. Qualifiers modify how each mechanism is treated during evaluation, shaping whether a host passes, fails, or is neutral.
Practical examples you can apply now:
- Use include:spf.protection.outlook.com to cover Office 365 senders, then verify mail flow from that service.
- Annotate with ip4:203.0.113.45/32 to authorize a specific mail gateway.
- Place -all at the end after verifying legitimate sources to reduce spoofing.
Common missteps to avoid
- Exceeding DNS lookup limits by nesting too many includes.
- Overly permissive qualifiers such as +all that bypass checks.
- Placing mechanisms outside the v=spf1 block, which renders the policy invalid.
2. The 6 most common SPF failures and how to fix them
Too many DNS lookups and the include chain problem
SPF validation can fail when the record triggers more DNS lookups than allowed. Each include or redirect adds to the total. Keep the lookup count under the limit by consolidating providers and avoiding deep include chains.
- Audit each include and remove redundant ones
- Prefer direct IPs or consolidated domains where possible
- Combine multiple sends through a single authorized gateway if feasible
Unbalanced or missing redirects and wildcards
A mismatched redirect or an unhelpful wildcard can cause unintended rejections. Use redirects intentionally and avoid broad wildcards that authorize unknown sources.
- Verify any redirect points to a valid SPF policy
- Avoid using +all or broadly permissive patterns
- Test changes with a controlled sender set
Incorrect domain alignment and multiple domains in use
The domain checked for SPF is not always the From domain. If you send from more than one domain, ensure each has a corresponding SPF record or a shared, properly aligned policy.
- Align envelope sender and header From where possible
- Maintain a single authoritative policy per domain when feasible
- Document domain relationships to prevent drift
Missing or excessive authorized senders
SPF records must list every legitimate sender without over-sharing. Missing providers break delivery; excessive entries raise lookup counts and risk failures.
- Regularly review approved senders against actual traffic
- Move third-party senders to a controlled include list
- Keep the record concise and well-scoped
DNS TXT record formatting errors and syntax mistakes
Syntax mistakes cause the entire SPF policy to be ignored. Simple typos, missing quotes, or misordered terms disrupt evaluation.
- Validate syntax with a trusted checker
- Ensure the record begins with v=spf1 and ends with -all or ~all
- Avoid multiple SPF TXT records for the same domain
Expired or misnamed included domains
Includes pointing to dead or renamed domains render the policy ineffective. Keep includes current and monitor changes in partner domains.
- Periodically verify all included domains are active
- Update or remove expired or renamed includes promptly
- Maintain a changelog for SPF adjustments
3. How to audit and maintain a healthy SPF in a UK SME
Setting a single, authoritative SPF record per domain
Start with one clear policy per domain to avoid conflicting records that trigger DNS lookups and authentication failures. Keep the record concise and scoped to legitimate sending sources.
Document which services are authorized and where updates originate. A single source of truth reduces drift and makes future audits faster and more reliable.
Regular audits and change controls
Schedule periodic reviews of the SPF policy to reflect new partners or changes in sending volumes. Pair audits with a formal change-control process to capture approvals and implementation dates.
Track DNS changes and verify that every modification preserves a valid policy, avoids duplicates, and stays within lookup limits.
4. SPF with Microsoft 365 and widely used email services
Configuring SPF for Microsoft 365 correctly
Publish a single, authoritative SPF record for your domain that includes Microsoft 365 as a sending source. Use the Microsoft 365 mechanism and avoid conflicting records.
- Use a v=spf1 include:spf.protection.outlook.com ~all structure
- Keep the total DNS lookup count under the limit by consolidating sources
- Test changes with real email traffic to confirm alignment
Adding third-party mail services and gateways without breaking SPF
When you work with external senders, add them through controlled includes rather than broad allowances. This preserves deliverability without expanding exposure.
- Translate each partner’s sending domain into an explicit include or IP range
- Document every addition and review quarterly for drift
- Avoid duplicating entries or creating multiple policy sources per domain
Special considerations for MOERA and onmicrosoft.com scenarios
MOERA domains are managed by Microsoft; if you rely solely on an onmicrosoft.com path, the SPF policy may already be in place. Ensure any gateway or redirect still feeds into a compliant SPF.
- Monitor MOERA usage to prevent unintended policy splits
- For hybrid deployments, align envelope and header domains to minimize conflicts
- Keep a clear record of how onmicrosoft.com domains relate to customer domains for audits
5. Diagnosing SPF failures: tools and practical tests
SPF validation tests and what to look for in results
Run tests to reveal how your policy is evaluated by recipient servers. Look for a clear pass or fail on the SPF check and note the DNS lookup count. High lookups can cause failures even with a seemingly correct record.
A mid size firm sends from three subdomains. A test shows 8 DNS lookups total, just over the typical 10 lookup limit, prompting a fail. Another example, a startup consolidates SPF to a single include mechanism and reduces lookups by 40 percent, improving pass rates during peak campaigns.
Key indicators include alignment between the envelope source and the domain being checked, and whether the policy ends with a strict or relaxed qualifier. Record the exact mechanism that is evaluated during validation to pinpoint misconfigurations.
Actionable tip: keep a running log of SPF validation results tied to campaign sends. Note the envelope domain, the receiving domain, the type of mechanism evaluated, and the final qualifier used.
Using SPF checkers and interpreting results without over-reliance on fragile data
SPF checkers automate syntax and lookup analysis, but they depend on current DNS visibility. Use them as a baseline, not a final verdict. Cross-check findings with your DNS provider’s propagation status and recent changes.
- Verify syntax, single TXT record presence, and total lookup count
- Confirm all intended senders are represented in the record
- Ensure the record ends with a proper qualifier such as ~all or -all
- Test after any IP range expansion or vendor integration
What to do when SPF passes but deliverability still suffers
A pass does not guarantee inbox placement. Issues can stem from DKIM, DMARC, or domain reputation. Review alignment across headers and verify that the sending domain matches the domain used in authentication checks.
Practical steps: run end to end mailbox tests for key domains, monitor bounce patterns, and schedule quarterly audits of third party senders. If you spot misalignment, adjust the return-path domain or update DKIM selectors to restore alignment.
Scenario What to check Action SPF pass, DKIM fail Header vs. envelope alignment Validate DKIM setup and key rotation SPF pass but deliverability poor DMARC policy, reputation, and mail flow Review DMARC alignment, monitor sender reputation Frequent DNS propagation delays Propagation status across domains Coordinate with DNS provider, schedule tests after changes 6. Step-by-step fix: from broken to compliant SPF in a typical UK business
Mapping your legitimate sending sources
Start with a comprehensive inventory of every system that sends on your domain. Include corporate mail servers, marketing platforms, CRM gateways, and partner relays. For a typical UK business, this might cover an on prem SMTP server, a marketing automation tool, and a third party billing portal all sending under the same domain.
- List each sender’s domain or IP range
- Note expected sending patterns and volumes
- Identify any shared gateways or intermediaries
Constructing a robust v=spf1 string
Create a single authoritative SPF record that accurately reflects all approved sources. Keep the total DNS lookups under the limit and prefer explicit IPs or tightly scoped includes. Map each source to a precise include or an IP4/IP6 block and verify correctly before going live.
- Include each legitimate source with precise mechanisms
- Avoid wildcard qualifiers that broaden access
- End with a conservative qualifier such as ~all or -all based on risk tolerance
Deploying and verifying the update across DNS and mail streams
Publish the updated SPF TXT record in DNS and monitor propagation across interfaces. Validate mail streams to ensure alignment with recipient checks. Roll out in stages to catch early issues without impacting deliverability.
- Test with representative messages from each source
- Check that DMARC and DKIM configurations remain in sync
- Document changes and schedule periodic audits for drift
