Dangling SPF: The Attack Vector Hiding in Your TXT Record

You’re staring at an Authentication-Results header, and it makes no sense. The email is a blatant, high-stakes business email compromise (BEC) attempt, aimed squarely at your CFO. Yet, every signal says it's legitimate. SPF passed. DKIM passed. And because of that, DMARC passed, sailing right past your `p=reject` policy. You check the sender's IP; it's not on any known blocklist. You check the domain's a uthentication records again. It's all there. It's perfect. And it's a lie.

The source of this highly authenticated, malicious email isn't a zero-day in a mail transport agent (MTA) or a compromised user account. The vulnerability is hiding in plain sight, in a single, forgotten line within a DNS TXT record you probably haven’t touched in years.

This is the world of dangling SPF records. It’s a classic subdomain takeover attack, but instead of a CNAME, the target is the trust you delegate via your Sender Policy Framework. For an attacker, it’s a cheap, effective way to inherit your domain's reputation and bypass your strongest email security controls.

How a Benign SPF `include` Becomes a Foothold

Let’s get grounded in RFC 7208. The Sender Policy Framework (SPF) is a simple system. A domain owner publishes a TXT record that lists the IP addresses authorized to send email on its behalf. When an MTA receives an email, it checks the `MAIL FROM` address domain, looks up its SPF record, and verifies the connecting IP is on the list. `include` is one of the mechanisms defined in the standard. Instead of listing IPs directly, `include:domain.com` tells the receiving server, 'Go look up the SPF record for domain.com. Any IP address they authorize is also authorized for me.'

This is a powerful and necessary feature. You don’t want to be updating your SPF record with dozens of IP addresses every time a third-party sender like your CRM or marketing automation platform changes its infrastructure. You delegate that responsibility by including their dedicated SPF domain (e.g., `_spf.vendorsaas.com`). It is, fundamentally, an act of trust. You are tethering your domain’s sending reputation to their operational security and DNS hygiene.

The vulnerability emerges when that trust relationship expires in practice but not in configuration. Imagine your marketing team ran a trial with a new email service provider, `coolmailer.net`, three years ago. Your IT admin dutifully added `include:coolmailer.net` to your company's SPF record. The trial ended, the company moved on, but nobody told the admin. A year later, `coolmailer.net` went out of business and their domain registration lapsed. Your SPF record, however, still contains that `include`. It's a pointer to a location that no longer exists—a dangling pointer, waiting for someone to claim the abandoned property.

Reconnaissance: Hunting for Dangling Pointers

The Attacker's Workflow

For an attacker, finding these dangling records is a straightforward reconnaissance exercise that is trivial to automate. The process begins with a target domain, let's say `examplecorp.com`.

First, they perform a DNS lookup for the TXT record of `examplecorp.com`. They parse the result, looking for `v=spf1` and collecting every domain specified in an `include:` mechanism. This process is recursive. If `examplecorp.com` includes `_spf.thirdparty.com`, and `_spf.thirdparty.com` includes `_spf.another.net`, the attacker's script follows the chain, building a comprehensive list of all delegated domains.

With a list of dozens of included domains, the next stage is a batch `whois` lookup. The script iterates through each domain, checking its registration status. Most will come back as registered. But the attacker isn't looking for most. They're looking for the one that returns `NOT FOUND`, `Available`, or `No match for domain`. That’s the jackpot.

Why This Works So Often

This attack vector persists because of organizational entropy. Companies are acquired. Products are sunsetted. Marketing campaigns end. The IT team that provisions access for a third-party sender is rarely the same team that is notified when the business relationship terminates. SPF records become a graveyard of forgotten partnerships, and without active auditing, there's no process to clean the tombstones.

Weaponization: From Registration to Malicious MTA

Once an attacker identifies an unregistered domain in a target's SPF chain, the exploit is trivial and cheap. Let's say they found `defunct-marketing-tool.com` is available, included by our target `examplecorp.com`.

For about $10, the attacker registers `defunct-marketing-tool.com`. Now they have full control over its DNS records. Their first move is to create a TXT record for the domain they just bought. On their DNS provider's dashboard, they add an SPF record that authorizes their own infrastructure—a mail server they control at IP address `198.51.100.42`.

examplecorp.com. IN TXT "v=spf1 include:_spf.google.com include:defunct-marketing-tool.com ~all"

# Attacker registers defunct-marketing-tool.com and adds:
defunct-marketing-tool.com. IN TXT "v=spf1 ip4:198.51.100.42 -all"

With that in place, the trap is set. The attacker spins up an MTA on their server at `198.51.100.42`. By simply owning the dangling domain and pointing an SPF record at their own server, they have effectively granted themselves permission to send email as `examplecorp.com`. The original, legitimate SPF record now works for the attacker.

The Payoff: Fully Authenticated Phishing Past `p=reject`

Here's why this is so devastating. It's not just about getting an SPF `pass` verdict. It's about achieving DMARC alignment, which is the key to bypassing modern email defenses. DMARC, defined in RFC 7489, fights phishing by checking that the domain in the user-visible `From:` header is 'aligned' with the domains authenticated by SPF and DKIM. A simple SPF `pass` isn't enough if the domains don't match.

In our attack scenario, the attacker wants to send an email as `ceo@examplecorp.com`. They craft the email and send it from their malicious server at `198.51.100.42`. They set the `MAIL FROM` envelope sender address to `anything@examplecorp.com`.

When a receiving mail server gets this email, the DMARC evaluation process kicks in. First, it extracts the `MAIL FROM` domain, `examplecorp.com`, and requests its SPF record. The record `v=spf1 include ... include:defunct-marketing-tool.com ~all` is returned. The receiver dutifully checks the sending IP `198.51.100.42` against all mechanisms. It follows the `include` to `defunct-marketing-tool.com`, retrieves the attacker's record `v=spf1 ip4:198.51.100.42 -all`, and finds a match. The SPF verdict is `pass`.

The View from the `Authentication-Results` Header

Now for the crucial part: DMARC alignment. The SPF-authenticated domain is `examplecorp.com`. The `From:` header domain is also `examplecorp.com`. They match. The alignment check passes. The final DMARC verdict is `pass`. Even if `examplecorp.com` has a strict `p=reject` policy, this email is considered authentic and is delivered straight to the inbox. The `Authentication-Results` header will look something like this:

`Authentication-Results: mta.receiver.com; spf=pass (sender IP is 198.51.100.42) smtp.mailfrom=examplecorp.com; dkim=pass (signature was verified) header.d=examplecorp.com; dmarc=pass action=none header.from=examplecorp.com`

The attacker just used a $10 domain registration to completely bypass the target's DMARC enforcement and send a fully authenticated phishing email. With a valid DKIM key (if also compromised or if DMARC requires only one of SPF or DKIM to align), the mail is indistinguishable from a legitimate internal message.

Countermeasures: Taming Your Trust Delegations

The Fallacy of 'Set and Forget'

The most important defense is a mental shift. Your SPF record is not a static piece of infrastructure to be configured once and then ignored. It is a living document that maps your organization's current, active digital-trust relationships. Each `include` statement is a liability that must be actively managed.

Some suggest 'SPF flattening'—replacing all `include` mechanisms with the underlying `ip4` and `ip6` addresses—as a solution. This is a fragile and dangerous approach. It might protect against this specific attack, but it breaks the delegation model, requires constant maintenance, and will almost certainly cause you to hit the 10 DNS lookup limit imposed by RFC 7208, leading to legitimate mail being rejected.

Building an Auditing Workflow

The correct approach is continuous, automated auditing. This doesn't require a massive budget. A simple script, run as a weekly cron job, can provide immense protection. This script should perform the exact same reconnaissance steps an attacker would: recursively resolve all `include` chains in your SPF record and perform a `whois` lookup on every single delegated domain.

The script's output should be an alert. If any domain in the chain comes back as unregistered, your security team needs to be paged. That `include` must be removed from your SPF record immediately. For more advanced protection, the script can also check domain expiration dates and alert on any domain set to expire within the next 90 days, giving you time to contact the vendor or remove the delegation before it becomes a dangling pointer.

Finally, this needs to be part of your vendor off-boarding checklist. When your organization terminates a contract with a SaaS provider, someone must be responsible for confirming their `include` is removed from your SPF record, their public keys are removed from your DNS for DKIM, and their reporting endpoints are removed from your DMARC record. Treat it with the same seriousness as deactivating their user accounts.

The takeaway

An SPF record is more than a technical setting; it's an attack surface. Every `include` is a key you've given to another party, and you're responsible for making sure they don't drop it on the ground for someone else to pick up. The dangling SPF exploit isn't a flaw in the protocol itself but a failure of operational hygiene.

The trust you delegate must be verified. Don't wait for a perfectly authenticated phish to land in your CFO's inbox to realize a forgotten vendor has become your biggest email security liability. Continuous monitoring of these DNS-based trust relationships, whether through homegrown scripts or a platform like MailSleuth.AI, is the only way to ensure your email authentication framework remains a shield, not an open door.