SPF ~all? Game On. A Red Teamer's Guide to Permissive Records

The DNS query returns almost instantly. `v=spf1 include:_spf.google.com include:sendgrid.net ~all`. That tilde is the only invitation I need. For a red teamer, finding a `~all` (SoftFail) qualifier in a Sender Policy Framework (SPF) record is like discovering the guards at a secure facility have been told to let suspicious people in, but to 'maybe raise an eyebrow' while doing it.

SPF, defined in RFC 7208, is supposed to be a simple declaration: here is the exclusive list of servers authorized to send email for my domain. Anything else is a forgery. But the protocol’s flexibility, particularly its qualifiers, creates a trust gap that is trivial to exploit. The difference between the `-all` (Fail) and `~all` (SoftFail) mechanisms isn't academic; it's the difference between a blocked phish and a successful breach.

This isn't a theoretical vulnerability. It’s a common, practical lapse in email hygiene that provides a foothold for sophisticated Business Email Compromise (BEC) and phishing campaigns. Let's walk through how to find these weak points and turn them into weapons.

The Hunt: Automating Recon for Permissive Policies

Your first step isn't targeted, it's broad. You need to map the target's entire email-sending infrastructure. This means finding every domain and subdomain they own, because a forgotten marketing subdomain can be the weak link that compromises the parent brand.

Mass Enumeration and DNS Querying

Start by building a comprehensive list of domains. Use tools like amass or subfinder against your primary target domain. Once you have a list of hundreds, or even thousands, of subdomains, it's time to script the search. A simple shell loop piping targets to `dig txt` or `nslookup -q=TXT` is all you need. Filter the output for records containing `v=spf1`.

What you're looking for are not just the records themselves, but the mechanisms within them. Pay close attention to `include:` statements. Each one is a potential rabbit hole of another organization's SPF policy, which might itself be permissive. A recursive script that resolves these `include` chains is essential for deep reconnaissance. An SPF record is only as strong as its weakest included policy.

Decoding the DNS: From `~all` to Overly Broad Ranges

Once you have a collection of SPF records, the analysis begins. You're hunting for any deviation from a strict, hardened policy. The gold standard is a record ending in `-all`. Anything else is a finding.

The Hierarchy of Weakness

The most obvious flaw is the qualifier. `+all` is a mythical creature, but it exists; it explicitly authorizes any IP address on the internet to send mail for the domain. It’s a complete surrender. More common and nearly as dangerous are `?all` (Neutral) and `~all` (SoftFail). Why? Because many mail servers and Secure Email Gateways (SEGs) are configured to be lenient. A `softfail` verdict is often treated as a pass-with-a-warning, not a definitive failure. If other signals like DKIM pass, the email sails right through.

A 'softfail' result should be treated as somewhere between 'fail' and 'neutral'/'none'. The receiver cannot conclude that the mail is illegitimate, and ought not to reject the mail on that basis alone. — RFC 7208, Section 8.5

Beyond the Qualifier

Beyond the qualifier, look for oversized IP ranges. An `ip4:10.0.0.0/8` in a public SPF record is a disaster. But even a `/23` or `/22` for a cloud provider is a massive attack surface. If you can provision a VM within that authorized netblock, you have an SPF-authorized sending IP. Also, check for the number of `include` and `redirect` mechanisms. If an SPF record requires more than 10 total DNS lookups to resolve, it returns a `permerror`. Many gateways fail open on a `permerror`, treating it as a pass. This creates a denial-of-service condition against the security policy itself.

The Spoofing Playbook: Weaponizing the Trust Gap

Finding a permissive record is step one. Weaponizing it is where the real tradecraft comes in. Your goal is to find a server within the authorized IP space that you can control, even temporarily.

Finding Your Foothold

This is a methodical process. For every `include:` statement, investigate the service. Does `include:mailgun.org` exist? Check if Mailgun offers a free trial. Does the record point to `_spf.an-old-crm.com`? See if you can register an account. For every `ip4:` or `ip6:` mechanism, check the IP space. Is it a public cloud provider like AWS, GCP, or Azure? Use a tool to map those IP ranges to specific services and regions. Your objective is simple: rent a cheap VPS or serverless function that gets assigned an IP address inside that authorized CIDR block.

The beauty of this particular spf misconfiguration exploit is that you aren't breaking into their infrastructure. You're simply using a service they have publicly declared as trusted. You're walking in through the front door they left unlocked.

Crafting the Payload

With your authorized sending IP secured, you can now set up your own mail server. A simple Postfix installation is sufficient. Now, you craft the phishing email. The sender address uses the target domain (`ceo@bigcorp.com`), but it's sent from your server. When the target's mail gateway receives it, the first thing it does is check SPF. It looks up `bigcorp.com`, sees your IP is in an authorized range, and returns an SPF `pass` or `softfail`. This initial verdict is often enough to grant the message a higher trust score, helping it bypass content filters, sandboxes, and executive impersonation rules that might otherwise catch it.

Case Study: Bypassing a SEG from an Unmonitored Provider

Let's make this concrete. During a recent engagement, we targeted a company whose primary domain had a `~all` qualifier. Their SPF record was a mess of nested includes, a symptom of years of adding marketing tools without ever cleaning up.

One included domain, `_spf.legacy-email-sender.com`, belonged to a marketing platform they'd churned from years ago. A quick search revealed this platform not only still existed but offered a generous free tier. We signed up, validated a control domain, and were given access to their sending infrastructure. The IPs they used were, of course, listed in their `_spf` record.

We crafted a simple BEC email pretending to be the CFO asking an accounts payable clerk to process an urgent invoice. We set the `From:` header to the CFO's real email address and sent it through the legacy marketing platform's SMTP relay. The target's expensive Secure Email Gateway received the message and performed its checks.

Authentication-Results: seg.bigcorp.com; dkim=none; dmarc=pass (p=none) header.from=bigcorp.com; spf=softfail (sender IP is 198.51.100.23) smtp.mailfrom=bigcorp.com

Look at that header. The `spf=softfail` was ignored because the company's DMARC policy was set to `p=none`. Since SPF didn't produce a hard `fail`, the gateway considered the alignment check for DMARC to be a success. The lack of a DKIM signature didn't matter. The email landed in the clerk's inbox, stamped with the perceived authority of their own domain. Game over.

The Defender's Playbook: Eliminating Permissive SPF

As a defender, you can't afford to be lenient. Permissive email authentication is an unforced error. Hardening your SPF policy is one of the highest-impact security tasks you can perform, and it costs nothing but time.

Audit, Consolidate, and Prune

Your first job is to get a handle on every IP and service authorized to send on your behalf. Flatten your `include` statements and investigate each one. If you no longer use a vendor, remove their `include` statement immediately. For IP addresses, be as specific as possible. Don't use a `/24` if you only send from two hosts. This isn't just about security; it also helps you stay under the 10-lookup limit and avoid `permerror` results.

Embrace the Hard Fail

There is only one acceptable qualifier for a domain that has enumerated all its sending sources: `-all`. Replace every `~all` and `?all` with `-all`. The common argument against this is that it breaks email forwarding. While true in some cases, this is a solved problem. The Authenticated Received Chain (ARC), specified in RFC 8617, was designed precisely to preserve authentication results across hops. Major providers like Google and Microsoft already support ARC. Prioritizing the convenience of a few broken forwarders over the security of your entire domain is a poor trade-off.

Finally, a strong SPF record is only half the battle. It must be paired with a DMARC (RFC 7489) policy of `p=quarantine` or, ideally, `p=reject`. DMARC is what tells receiving mail servers what to do when SPF or DKIM fails. Without an enforcement policy, your SPF record is just a suggestion.

The takeaway

An SPF record is not a static piece of IT infrastructure. It's a dynamic security policy that reflects your trusted sending relationships. Treating it as a set-it-and-forget-it DNS entry is negligent. Every `include:` is a liability, and every `~all` is a bug waiting to be exploited.

Regular, automated auditing of your sending domains isn't optional; it's a core function of a modern security program. This means recursively resolving all mechanisms and validating that your policy remains as strict as you designed it. Constant monitoring, whether through custom scripts or platforms like MailSleuth.AI, is the only way to turn this constant threat of an SPF misconfiguration exploit into a proactive, hardened defense.