The Operator's Guide to Exploiting Permissive SPF Records

You just found it. After hours of DNS reconnaissance against a target organization, a single TXT record lights up your screen. It’s not a leaked credential or an exposed service, but something just as valuable: a Sender Policy Framework (SPF) record ending in `?all`.

For a red team operator, this is gold. It’s a subtle but significant crack in the target's email security posture. Most security teams focus on the obvious threats, but a permissive SPF record is an engraved invitation to bypass foundational email authentication, making targeted business email compromise (BEC) campaigns drastically more effective.

This isn't about brute-force spamming. This is about surgically precise spoofing. It’s about making a fraudulent email from `ceo@target.com` look legitimate enough to bypass not just human suspicion, but the very protocols designed to stop it. And it all starts with understanding one misconfigured character.

Finding the Cracks: DNS Recon for Permissive records

Your first step is mapping the target's email infrastructure. The SPF record, defined in RFC 7208, is a public DNS TXT record. Anyone can query it. Simple command-line tools like `dig` or `nslookup` are your workhorses here.

A typical query looks like this: `dig TXT target-domain.com`. You're specifically looking for the string `v=spf1`. What follows is a list of mechanisms (like `ip4:`, `include:`, `a:`) that define authorized sending sources. But our focus is on the very end of that string, specifically the `all` mechanism and its qualifier.

Parsing the Payload

You'll get a response that might look something like `v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.123 ?all`. The initial mechanisms list the legitimate senders—Microsoft 365, Mailchimp, a corporate mail server. The final piece, `?all`, is our entry point. It’s the Neutral qualifier, and its presence signals a weakly configured policy.

While manual queries work for a single target, effective reconnaissance requires scale. Simple bash scripts can loop through a list of domains, running `dig` and `grep`-ing for `?all` or, even better, `+all`. This automates the discovery of domains across a company's entire portfolio, subsidiaries included, which are often less stringently managed.

The Meaning of the Mechanisms: +, -, ~, and ?

An SPF record is a machine-readable instruction for a receiving mail server. When an email arrives claiming to be from `user@target-domain.com`, the receiver checks the source IP address against the list in `target-domain.com`'s SPF record. The qualifier on the `all` mechanism tells the receiver what to do if the sender's IP isn't on the list.

The Four Verdicts

`+` (Pass): The IP is an authorized sender. The qualifier is often implicit; `a` is the same as `+a`. An `+all` literally means any IP address on the internet is a valid sender.

`-` (Fail): The IP is not authorized. This is a hard fail. The instruction is explicit: this email is fraudulent, and the DMARC policy should be enforced (quarantine or reject).

`~` (SoftFail): The IP is probably not authorized. This is a weaker signal than Fail. It suggests the message should be scrutinized more heavily or marked as suspicious, but not necessarily rejected outright. It's often used by organizations afraid of breaking email forwarding.

`?` (Neutral): The SPF record makes no statement about the IP's validity. This is the key. The receiver's verdict is `neutral`. It's not a pass, but critically, it's not a fail. The email is treated as if no SPF record existed at all.

Weaponizing Neutral: A '?all' Spoofing Scenario

Let’s put this into action. You've identified that `globalcorp.com` uses `v=spf1 ... ?all`. Your goal is to send a plausible spoofed email from the CFO to an employee in the finance department, initiating a fraudulent wire transfer.

You don't need to compromise any of GlobalCorp's authorized servers. You can send the email from any server you control. When your email hits the recipient's inbox at `acme-corp.com`, their mail server performs an SPF check. It fetches `globalcorp.com`'s SPF record, sees your server's IP is not in any of the approved mechanisms, and evaluates the `?all` directive.

The result is `spf=neutral`. It doesn't fail. This is where DMARC (RFC 7489) comes in. DMARC aligns the results of SPF and DKIM. If the domain has a weak DMARC policy like `p=none`, or no DMARC record at all, the `neutral` SPF result doesn't trigger any punitive action. The email sails right through to the inbox, often without even a warning banner.

Authentication-Results: mta.receiver.com; spf=neutral (sender IP is 198.51.100.10) smtp.mailfrom=cfo@globalcorp.com; dmarc=none (p=none) header.from=globalcorp.com — Example Authentication-Results Header

This header tells the story. SPF produced a `neutral` verdict. Because DMARC was set to `none`, this non-passing result was ignored. The attack succeeded not by breaking encryption or guessing passwords, but by exploiting a permissive policy that was configured by the target themselves. You walked right through the front door because they left a note saying not to worry about unfamiliar visitors.

The Ultimate Footgun: Why 'v=spf1 +all' Is an Open Invitation

If `?all` is leaving the door unlocked, `+all` is putting up a neon sign that says "Welcome, Spoofers!". It is a catastrophically bad configuration that is, alarmingly, still found in the wild. It's worse than having no SPF record at all.

An Explicit Declaration of Trust

A record like `v=spf1 +all` explicitly tells every mail server on Earth that *every IP address on the internet is an authorized sender for this domain*. It doesn't just result in `neutral`; it results in an SPF `pass` for any email, sent from anywhere, claiming to be from that domain.

This configuration completely negates the purpose of SPF. More dangerously, it provides a `pass` verdict that can help satisfy DMARC's alignment requirements. An attacker can send an email from their own server, and the recipient's mail gateway will see a valid SPF `pass`, giving the message a veneer of legitimacy that a `neutral` result doesn't. You will almost never see this on a primary corporate domain, but you will find it on marketing subdomains, temporary project domains, and other forgotten digital assets — all of which can be used to build trust in a larger campaign.

From Red to Blue: Finding and Fixing Risky Qualifiers

Pivoting to a defensive mindset, how do you prevent this? The fix is conceptually simple: never use `?all` or `+all`. Your `all` mechanism should always be either `~all` (SoftFail) or `-all` (Fail).

Remediation and Validation

`~all` is the cautious choice. It tells receivers to accept the mail but mark it as suspicious. This is a common starting point for organizations with complex mail flows who worry that a stricter policy might block legitimate-but-funky emails, like those from archaic listservs or broken forwarders. It prevents an SPF `pass` for unauthorized senders and will cause a DMARC failure.

`-all` is the secure state. It is an unambiguous instruction to reject mail from any IP not explicitly listed in your record. This provides the strongest signal to receiving systems and is the ultimate goal for any mature email security program. Moving from `~all` to `-all` requires careful monitoring of DMARC reports to ensure you're not dropping legitimate mail.

Regularly audit your DNS. Use online SPF validators to check your records for syntax errors, lookup limits, and, most importantly, permissive qualifiers. This isn't a one-time fix. Every time a new marketing tool or third-party service is onboarded, there's a risk that a well-meaning admin will add an `include:` that chains to another permissive record, or simply relaxes the policy to `?all` to "make things work."

The takeaway

A permissive SPF record is a symptom of a deeper issue: a disconnect between policy and practice. It represents a a gap that attackers, whether red teamers or real adversaries, are skilled at finding and exploiting. It bypasses the perimeter by twisting a security control into an enabler.

Fixing your SPF record is a high-impact, low-effort security win. Stop telling the world you're unsure who sends your email. Tell them with confidence. Your goal should be an unambiguous `-all`. Analyze your mail flow, check your DMARC reports with a platform like MailSleuth.AI to understand your sending sources, and close the door for good.