We will analyze SPF strictly from a red team / adversarial security standpoint, focusing on real exploitation logic and defensive blind spots.

1. Threat Modeling

Within the email security pipeline:

SMTP connection
   ↓
SPF validation (IP ↔ envelope-from)
   ↓
DKIM validation (signature)
   ↓
DMARC alignment check
   ↓
Spam / SOC filtering rules

SPF is the first-layer weak binding validation mechanism. Its core question is:

“Is this IP authorized to send mail on behalf of this envelope domain?”

SPF is not an identity authentication system.
It is a source authorization declaration system.

2. Common Red Team Exploitation Paths

1️⃣ Header-From Spoofing (SPF Design Limitation)

SPF validates only:

1	MAIL FROM:

But users see:

From:

If the target domain:

Has SPF configured
But does NOT enforce or strictly configure DMARC

You can construct:

1 2	MAIL FROM: attacker@legit-spf-domain.com From: ceo@target.com

As long as the first domain passes SPF,
the receiving server may accept the email,
while the visible sender appears as target.com.

⚠ This is the most common real-world CEO spoofing model.

2️⃣ Triggering PermError via the 10 DNS Lookup Limit

SPF RFC enforces:

Maximum of 10 DNS lookups.

Red team strategy:

Recursively expand include chains.
Identify domains close to the 10-lookup threshold.
Exploit DNS delays or timeouts.
Trigger SPF PermError.

The issue:

Some gateways treat PermError as Neutral.
Neutral often does not trigger rejection.

This is essentially a policy downgrade attack.

3️⃣ Abuse of SoftFail (~all)

If a domain uses:

1	v=spf1 include:xxx ~all

Red team actions:

Directly spoof the domain.
Many servers will not hard reject.
Combine with social engineering for high success rates.

Common enterprise misconception:

“We have SPF, therefore we are protected.”

But ~all is merely advisory.

4️⃣ Third-Party Include Supply Chain Risk

Typical enterprise SPF:

include:_spf.google.com
include:spf.protection.outlook.com
include:mailgun.org
include:zendesk.com

Risk factors:

Third-party service abuse
Poor account isolation
API key leakage
Overly broad vendor SPF policies

Attack path:

Obtain legitimate sending API access.
Send mail from authorized infrastructure.
SPF Pass + DKIM Pass.
If DMARC policy = none → delivery succeeds.

This is one of the most dangerous real-world paths.

5️⃣ Subdomain Coverage Gaps

Many enterprises configure:

1	example.com

But ignore:

1 2	finance.example.com secure.example.com

If subdomains lack SPF and DMARC:

You can spoof:

1	ceo@finance.example.com

Visual deception success rate is extremely high.

6️⃣ Forwarding Chain Confusion

SPF does not support forwarding.

Attack model:

Use legitimate relays.
Or leverage open forwarding systems.
Trigger SPF Fail → system falls back to DKIM.
If DKIM alignment is not strict → bypass possible.

This is an authentication chain fragmentation attack.

7️⃣ DMARC Alignment Abuse

DMARC supports two alignment modes:

relaxed
strict

If relaxed alignment is used:

1 2	mail.example.com news.example.com

You may craft malicious subdomains
that still satisfy relaxed alignment.

3. Blue Team Defensive Maturity Levels

Level 0

No SPF
No DKIM
No DMARC

Fully spoofable.

Level 1

SPF with ~all
No DMARC

Highly vulnerable to CEO spoofing.

Level 2

SPF -all
DKIM enabled
DMARC policy=none

Still exploitable via alignment weaknesses.

Level 3 (Enterprise Recommended)

SPF -all
Mandatory DKIM signing
DMARC policy=quarantine or reject
Strict alignment
Subdomain coverage

4. Red Team Assessment Methodology

Step 1 — DNS Enumeration

1 2	dig txt target.com dig txt _dmarc.target.com

Collect:

SPF structure
include count
Presence of ~all
DMARC policy

Step 2 — Include Expansion

Recursively measure:

Total DNS lookup count
Proximity to 10-query limit
Third-party dependencies

Step 3 — Subdomain Enumeration

Identify:

Subdomains without SPF
Subdomains without DMARC
Relaxed alignment usage

Step 4 — Controlled Delivery Testing

Testing matrix:

Test Case	Objective
SPF Pass + DMARC None	Delivery acceptance
SPF SoftFail	Rejection behavior
Header-From spoof	Inbox placement
Subdomain spoof	DMARC enforcement

5. Real-World Conditions for Successful Attacks

Attacks commonly succeed when:

DMARC policy = none
SPF uses ~all
Relaxed alignment
Weak inbound filtering
SOC does not monitor DMARC reports

6. Core Insight

SPF itself is not a vulnerability.
It is a weak trust declaration protocol.

Real risk arises from:

Misconfiguration
Over-reliance on SPF alone
Lack of DMARC enforcement
Third-party supply chain exposure

7. Advanced Perspective

At a higher architectural level:

SPF is the control plane
DKIM is the data plane
DMARC is the policy plane

Attacks often occur in the gaps:

Authentication inconsistency exploitation

congdong007

Deep Dive SPF from an Offensive–Defensive Perspective