Free toolNo sign-up
DNS Lookup
Use Sendmarc's DNS lookup tool to instantly analyze domain records, verify configurations, and detect DNS issues for better performance.
Blog article
- 8 minutes read
Waseem OsmanDMARC EnthusiastSPF a Record: It Might Authorize More Than You Think
SPF a record overview:
- The
amechanism can authorize infrastructure you don’t control, not just your own. - Softfail plus a stale SPF
arecord hides spoofing risk unless you’re actively monitoring it. - SPF passing on the wrong source doesn’t stop DMARC from passing on it too.
Your SPF record may authorize the a record of an unvetted third party, and your email administrator may never know until a spoofing attempt reaches your customers, partners, or suppliers.
That is not a hypothetical edge case. It is a structural risk in SPF’s evaluation of authorized senders, and it particularly affects enterprises with hybrid environments, multi-tenant infrastructure, and domains where DNS ownership has shifted over time.
This post is an operational guide for CISOs, email administrators, and risk officers who need to audit SPF a record risk systematically, before a deliverability failure or a spoofing incident occurs.
Check your SPF record to see what your current configuration authorizes.
Why SPF a Records Are Important
SPF works by publishing a TXT record in the DNS that lists authorized sending sources. Most teams focus on the include and ip4 mechanisms.
Few pay close attention to the a mechanism, which tells receiving servers to check an SPF a record and authorize any IP address it returns.
The a mechanism is legitimate and useful. It allows organizations to map a hostname to an ip4 address. The problem isn’t the mechanism itself; it’s what happens when the SPF a record it references no longer points to infrastructure you control.
Suppose a domain’s SPF record includes a:mail.partner-domain.example.com. When that record was written, your company controlled that subdomain. Since then, it’s been transferred to a third party.
The record still authorizes the IP address the SPF a record resolves to. If the SPF a record now points to an IP owned by an external party, you’ve authorized unvetted infrastructure to send as your domain.
The SPF a Record Softfail Gap
Many enterprise SPF records still use ~all (softfail) rather than -all (hard fail). Softfail tells receiving servers that messages from unauthorized sources should be flagged but not necessarily rejected. Combined with a stale or misconfigured SPF a record, this creates a scenario where:
- An email from an unvetted IP passes SPF because the
arecord authorizes it. - An email from a legitimate sender fails SPF because the
arecord has drifted.
Neither outcome is visible without active monitoring. The first represents a direct spoofing and BEC risk that undermines email spoofing prevention efforts.
The second creates a deliverability problem that manifests as intermittent inbox placement failures. This is exactly the kind of fault that is difficult to trace back to a DNS misconfiguration.
DMARC enforcement compounds this. If SPF passes on the wrong source, DMARC may still pass alignment, which means your enforcement policy doesn’t catch the issue.
SPF a Record Audit Steps: Identifying Misaligned Records
The following steps make up a structured SPF a record audit. Apply them to every domain that sends email.
Step 1: Extract All a Mechanisms from Your SPF Records
For each domain, retrieve the full SPF TXT record.
Document every a mechanism, including those nested inside include references. Nested include chains are where stale a mechanisms often hide.
If your SPF record includes third-party senders, such as marketing platforms, HR systems, or transactional tools, those providers’ SPF records may themselves contain a mechanisms that resolve to infrastructure you have no visibility into.
Step 2: Resolve Each Referenced SPF a Record and Verify Ownership
For every a mechanism, resolve the current a record.
Then verify:
- Whether the returned IP belongs to infrastructure your organization controls.
- Whether the IP is assigned to a cloud provider that may be shared with other tenants.
- Whether the IP has been repurposed, transferred, or left pointing to a temporary resource.
In multi-tenant environments, this step often surfaces IP addresses that belong to former providers. These are the scenarios where a single misconfigured SPF a record can create authorization risk across multiple domains.
Step 3: Count Your DNS Lookups
SPF enforces a limit of 10 DNS lookups during evaluation. Every include, a, mx, and exists mechanism that requires a DNS query counts toward this limit.
If your record exceeds 10 lookups, receiving servers return a PermError, and SPF fails. This means your messages may get rejected outright.
Count the lookups across your full SPF chain, including nested include references. Each a mechanism pointing to an external IP increases the lookup count without necessarily improving security.
Safe Validation Before Enforcement
Moving to SPF -all (hard fail) or DMARC p=reject without validating your SPF a record first risks interrupting critical email flows.
The validation sequence that reduces SPF a record risk:
- Map all sending sources before updating any DNS record. Use DMARC aggregate reports to identify every IP currently sending as your domain. Compare those IPs against what your SPF record actually authorizes. Discrepancies indicate either unauthorized senders or a misconfigured
amechanism. - Test a record changes in staging where possible. If you’re updating an SPF
arecord as part of a migration or decommission, check which SPF records reference that record before making the change. Enterprise DNS management processes should recognize that changes toarecords can affect email security and deliverability. - Move to
-allonly after your sending sources are mapped and authorized. Softfail shouldn’t be a permanent configuration. Once you’ve confirmed that every authorized sender passes SPF consistently, the risk of moving to hard fail is low. - Re-audit after any infrastructure change. SPF
arecord modifications, third-party sender additions, cloud migrations, and M&A activity all create conditions where previously audited SPF records drift out of alignment. Buildarecord verification into your change management process.
How Sendmarc Helps
Auditing SPF a record risk manually is feasible for a single domain. It doesn’t scale across dozens of domains, multiple departments, and a vendor ecosystem that changes quarterly.
Sendmarc provides continuous visibility into who’s actually sending as your domains, including the sources your SPF record may be authorizing through stale or misconfigured a records.
For teams preparing to move from p=none to p=reject, Sendmarc’s DMARC Platform supports a structured enforcement path: Identify unauthorized senders, validate authorized ones, and move to enforcement without guesswork.
Get the latest email security updates delivered to your inbox each month
Is Your Domain Protected?
Get your domain’s security score in seconds.
Check your impersonation, privacy, and branding ratings.
If you’re at risk of impersonation, one of our experts will be in touch to assist.
