The IT JanitorCleaning up one tenant at a time

Mail Sorcery

How To Fix SPF: A Practical Cleanup Guide

Before You Continue

If SPF itself still feels a bit fuzzy, start here:

./demystifying-spf.md

For background on how SPF records get messy, see ./how-can-you-break-spf.md, ./spf-dns-lookup-limit.md, and ./spf-breaking-during-forwarding.md. Then continue with this guide.

Before adding another SPF include, try finding out what the existing ones are doing. Radical, I know.

Fixing a messy SPF record isn’t glamorous work, but it’s some of the most satisfying cleanup you’ll do all quarter. Here’s how to do it properly instead of just hacking at it until mail flows again.

Step 1: Identify Every Legitimate Sender

You cannot fix what you don’t understand. Before touching a single character in the SPF record, build a full list of every system that legitimately sends mail as this domain.

Sources to check:

  • Message trace in the Microsoft 365 admin center or Exchange Online, going back at least 90 days
  • DMARC aggregate reports, which show every sending source claiming to use your domain, including ones you’ve forgotten about
  • The current SPF record itself, mechanism by mechanism
  • Conversations with the business: marketing, sales, finance, and support teams often know about tools IT was never told about

Step 2: Check The Usual Categories

Walk through each of these deliberately, rather than relying on memory:

  • CRM platforms
  • ERP systems
  • Ticketing platforms
  • Marketing platforms
  • Transactional mail services
  • Company website contact forms
  • Internal apps that send notification emails
  • Scanners and multifunction printers
  • Any third-party app integrated with the mailbox

Step 3: Read The DMARC Reports Properly

DMARC aggregate reports (the XML reports sent to a rua address) list every IP address that has sent mail claiming your domain, along with whether SPF and DKIM passed. This is the single most reliable way to catch senders you didn’t know existed. A tool that parses these reports into a readable dashboard will save you hours compared to reading raw XML.

Step 4: Remove What’s No Longer In Use

For every system on the SPF record, ask: is this still actively sending mail? If message trace and DMARC reports show no activity from a given source in the last 90 days, it’s a strong candidate for removal. Document the decision before removing it, in case it resurfaces later.

Step 5: Avoid Duplicate SPF Records

Check for multiple v=spf1 TXT records on the same domain. If you find more than one, merge them into a single record. Two SPF records is not “extra protection,” it’s an invalid configuration that most receivers reject.

Step 6: Validate Syntax

SPF syntax is unforgiving. A single misplaced colon or missing space can invalidate the entire record. Use an SPF syntax validator before publishing any change, every time, no exceptions.

Step 7: Check The DNS Lookup Count

Use an SPF lookup checker to count the fully resolved number of DNS lookups, including nested includes. If you’re near or over the 10 lookup limit, see ./spf-dns-lookup-limit.md for how that limit works, and ./spf-flattening-explained.md for one possible way to reduce it.

Step 8: Document Every Entry

For every mechanism in the SPF record, keep a short note: which system it represents, who owns it, and when it was added or last verified. Future you, or whoever inherits this domain, will be grateful. This single habit prevents the “DO NOT REMOVE, MAIL MAY BREAK” scenario from ever happening again.

Step 9: Move From ~all To -all Only When Confident

~all (soft fail) tells receivers to accept but flag mail from unlisted sources. -all (hard fail) tells receivers to reject it outright. Moving to -all too early, before you’re confident every legitimate sender is accounted for, will break real mail. Run with ~all and monitor DMARC reports for a few weeks first.

Step 10: Combine With DKIM And DMARC

SPF cleanup alone isn’t a complete fix. Pair it with DKIM signing for every legitimate sending system, and a DMARC policy that ties both together. This is the combination that actually protects your domain and improves deliverability.

Practical Cleanup Checklist

  • Pull 90 days of message trace data
  • Review DMARC aggregate reports
  • List every legitimate sending system
  • Confirm current SPF record contents
  • Remove unused or deprecated entries
  • Merge duplicate SPF records into one
  • Validate SPF syntax
  • Check total DNS lookup count
  • Document ownership of each entry
  • Confirm DKIM is configured for all senders
  • Confirm DMARC policy is in place
  • Move to -all only after monitoring ~all results

Suggested Image

A checklist clipboard graphic with DNS record icons being sorted into two piles, one labeled “Keep” and one labeled “Remove,” with a small magnifying glass hovering over the record for inspection.

Continue Reading

Sponsored