04 Aug 20265 minutes read
Kiara SaloojeeDMARC EnthusiastSPF Record Audit: Finding and Fixing Syntax Issues
SPF record audit overview:
- Syntax validation alone doesn’t mean an SPF record is protecting the domain.
- An SPF record audit checks syntax, lookup count, sender mapping, and ownership.
- RFC 7208 caps SPF at 10 DNS lookups; exceeding it returns a PermError.
- Qualifiers (
~all,-all,?all) determine how unauthorized messages are handled. - Consolidation is staged: baseline, confirm removals, flatten, deduplicate, then monitor.
An SPF record can pass every syntax validator on the market and still fail to protect your domain. That gap is an ownership problem, rooted in records assembled incrementally over years rather than designed and maintained deliberately.
For enterprises managing dozens of domains, multiple business units, and a growing list of authorized sending vendors, fragmented and undocumented SPF records create audit risks that matter in regulated industries.
An SPF record audit surfaces mechanisms that no longer map to active senders, records approaching the SPF DNS lookup limit, and ownership gaps that leave a record unmaintained. This post covers a structured audit workflow and a consolidation process for resolving syntax issues.
Sendmarc’s SPF Record Checker validates a record’s syntax and structure, confirms which IP addresses are authorized, and flags excessive DNS lookups before they cause delivery failures, which turns an SPF record audit into a controlled review rather than a trial-and-error exercise.
Use the SPF Record Checker to catch these issues before starting a full SPF record audit.
How to Perform an SPF Record Audit
An SPF record audit has three objectives: confirm the record is syntactically valid and within the SPF DNS lookup limit, confirm every authorized mechanism maps to a known and active sender, and confirm the record has a clear owner and change process going forward.
Step 1: List All Domains and Subdomains
Pull a complete list of every domain and subdomain your organization controls. Include parked domains and legacy domains from acquisitions. For each one, retrieve the current SPF record using a DNS lookup:
Step 2: Count SPF DNS Lookups
For each SPF record, manually trace the lookup chain. Count every include, a, mx, and exists mechanism. Then, for each include, open its own SPF record and count its mechanisms too. RFC 7208 imposes a hard SPF DNS lookup limit of 10. Anything approaching or exceeding that limit needs consolidation before it triggers a PermError.
This is where fragmented records from years of additions typically surface their real cost. A record that looks like it has five mechanisms may resolve to 14 lookups once nested include chains are counted.
Step 3: Map Mechanisms to Active Senders
For each mechanism in each record, identify the owner and confirm the sender is still active:
- Confirm the vendor is still contracted and actively sending email for this domain.
- Confirm the IP range belongs to infrastructure still in production use.
- Confirm the
includeis still maintained by the vendor, not abandoned.
Mechanisms that can’t be mapped to an active sender are candidates for removal. Do not remove them without first confirming with the relevant department.
Step 4: Review Qualifier Consistency
Check that every mechanism uses an appropriate qualifier. Flag any ? (neutral) qualifiers for immediate review, since it provides no protection. Check whether ~all is the intended long-term setting, or whether the plan was always to move to -all and that change just never happened.
If DMARC is set to p=reject and the SPF record uses -all, confirm the combination isn’t blocking legitimate email.
Step 5: Document Ownership and Change Controls
For compliance purposes, the SPF record for each domain should have a named owner, a documented approval process for changes, and a record of when it was last reviewed. In regulated industries, the absence of this documentation is itself an audit finding.
SPF Consolidation Workflow: Reducing Syntax Issues
Consolidating a fragmented SPF record is a controlled process. The goal is a record that stays well within the SPF DNS lookup limit while still authorizing every active sender.
- Baseline first. Before making any changes, document the current record exactly as published and confirm current delivery rates for all email streams. You need a baseline to detect regressions.
- Identify removals. Start with mechanisms that map to decommissioned vendors or IP ranges that have been reassigned. These are safe to remove after confirmation.
- Replace nested
includeswith flattened IP ranges. Some third-party sending services publish stable, documented IP ranges that can be expressed asip4blocks instead ofincludechains. Flattening reduces lookup count but requires monitoring when vendor IP ranges change. - Consolidate duplicate mechanisms. Remove
ip4entries that fall within an existing CIDR block. Removeincludesthat duplicate coverage already provided by another mechanism. - Test in staging where possible. For companies with a test domain, publish the revised record on the test domain and run delivery tests before applying to production.
- Publish and monitor. After publishing, monitor DMARC aggregate reports for any increase in SPF failures. These reports show which senders are actually passing or failing SPF.
- Update documentation. Record the new state, the rationale for each remaining mechanism, and the owner for each authorized sender.
How Sendmarc Helps
An SPF record audit is a snapshot of what a record authorizes at one point in time. Managing SPF syntax across dozens of domains is difficult without continuous visibility into what’s actually authorized and what’s actually sending.
Sendmarc surfaces your full sender inventory from DMARC aggregate report data, giving continuous, unified visibility into SPF configurations across every domain and business unit rather than a static point-in-time view of the published record.
That visibility supports the audit trail regulated organizations need to demonstrate compliance to risk committees, and it reduces the manual investigation typically required to map mechanisms back to active senders.
Explore the Sendmarc Platform to see how it simplifies SPF record audits at enterprise scale.
