Introduction

A mail migration can move users to the new platform while the SPF record still includes the old provider. Mail may continue to send for a while, but the domain keeps authorizing infrastructure that should have been retired, which creates unnecessary complexity and can hide which outbound path is still active.

Treat this as a sender-inventory and DNS-authentication problem instead of a simple TXT-record cleanup. Start by identifying every system that still sends mail for the domain, because removing an old SPF include too early can break a sender that the migration plan missed.

Symptoms

  • The SPF record still references the old mail provider after migration
  • DNS includes both the previous and current mail services
  • Outbound mail works, but it is unclear which provider is still authorized to send
  • Deliverability troubleshooting is harder because multiple legacy includes remain
  • SPF lookups are growing more complex after the cutover
  • The issue appeared after moving mailboxes, relays, or transactional mail services

Common Causes

  • The old provider include was never removed from the SPF record
  • One application or device still sends through the previous mail platform
  • The migration updated user mailboxes but not every outbound sender
  • DNS cleanup was postponed after cutover and never revisited
  • Multiple overlapping SPF changes were made without rechecking the final sender inventory
  • The old provider stayed authorized because removing it was considered risky without validation

Step-by-Step Fix

  1. Review the current SPF record and list every include, IP, and sending mechanism it authorizes, because you need a full picture before deciding whether the old provider can be removed safely.
  2. Identify every active sender for the domain, including user mailboxes, applications, scanners, websites, and relays, because one forgotten sender often explains why the legacy include was left behind.
  3. Check recent message headers or provider logs to see whether any live mail still leaves through the old platform, because DNS cleanup should follow observed sending behavior rather than assumptions.
  4. Compare the old provider include with the new platform’s outbound requirements, because overlapping authorizations can hide stale routing and make the final SPF policy harder to maintain.
  5. Remove the old provider from SPF only after confirming nothing still depends on it, because an unused include adds risk and lookup cost without any benefit.
  6. Retest outbound mail from each important sender after the SPF update, because user mail, app mail, and relay mail can follow different routes even under the same domain.
  7. Verify that SPF alignment still works with your DKIM and DMARC setup, because SPF cleanup should reduce ambiguity without creating a new authentication mismatch.
  8. Watch for DNS propagation and cached SPF results during validation, because some test systems may keep showing the previous policy briefly after you publish the corrected record.
  9. Document the final approved senders and the reason each SPF mechanism remains in place, because future migrations become much easier when the domain’s outbound mail inventory is explicit.