Email Envelope Spoofing & SPF

Timeline: The Cat and Mouse

1982 ← Attack emerges → 2006 ← Industry responds → 2015 ← Attackers adapt → Present

The Evolution

Key Events with Sources

Overview

Before SPF, SMTP had no mechanism to verify that the server sending an email was authorized to send on behalf of the claimed domain. Attackers could send email from any server claiming to be ceo@yourbank.com and recipients had no way to verify the claim.

The Attack

How SMTP Works (The Problem)

SMTP is a 1982 protocol designed for a trusting internet. When you send an email, your mail server connects to the recipient’s server and says:

MAIL FROM: <ceo@bigbank.com>
RCPT TO: <victim@target.com>
DATA
Subject: Urgent Wire Transfer

Please wire $50,000 to account...

The receiving server had no way to verify that the sending server was actually authorized to send mail for bigbank.com. It just accepted the claim.

Envelope vs. Header Addresses

Email has two “from” addresses that confuse everyone:

Attackers could forge both independently. SPF only validates the envelope from.

Attack Scenarios

Business Email Compromise (BEC):

MAIL FROM: <ceo@company.com>
From: CEO Name <ceo@company.com>
To: accounts@company.com
Subject: Urgent Wire Transfer

Please process this immediately. I'm in a meeting.

Credential Phishing:

MAIL FROM: <security@bigbank.com>
From: BigBank Security <security@bigbank.com>
To: customer@gmail.com
Subject: Account Verification Required

Click here to verify your account...

Malware Delivery:

MAIL FROM: <hr@target.com>
From: HR Department <hr@target.com>
To: employee@target.com
Subject: Updated Benefits Enrollment

Please review the attached document...

How SPF Works

The Defense Mechanism

SPF allows domain owners to publish a DNS TXT record listing which IP addresses are authorized to send mail for their domain.

Example SPF record for example.com:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

This says:

• v=spf1 — This is an SPF record
• ip4:192.0.2.0/24 — IPs in this range can send for us
• include:_spf.google.com — Google’s mail servers can send for us (we use Google Workspace)
• -all — Reject mail from anyone else (hard fail)

SPF Qualifiers

The Validation Process

1. Attacker sends email claiming MAIL FROM: <ceo@bigbank.com> from IP 198.51.100.5
2. Receiving server extracts domain bigbank.com from envelope
3. Server queries DNS for bigbank.com TXT record
4. SPF record says only 192.0.2.0/24 is authorized
5. 198.51.100.5 is not in that range → SPF Fail
6. Server rejects or quarantines the email

Attacker Adaptation

SPF has significant limitations that attackers exploit:

Bypass Techniques

1. Cousin Domains

SPF validates the envelope domain, so attackers register similar domains:

• bigb4nk.com (substituted character)
• bigbank-security.com (added suffix)
• bigbank.co (different TLD)

The attacker controls these domains and can set up valid SPF records.

2. Envelope/Header Mismatch

SPF only checks the envelope MAIL FROM, not the From: header users see:

MAIL FROM: <anything@attacker.com>     ← SPF checks this (passes)
From: CEO <ceo@bigbank.com>            ← User sees this (spoofed)

This attack works until DMARC closes the gap.

3. Compromised Infrastructure

If attackers compromise a server that’s in the SPF record, they can send as the domain legitimately:

• Compromised web server that’s also authorized for mail
• Compromised third-party email service
• Compromised employee mailbox

4. Forwarding Breaks SPF

When email is forwarded, the original SPF check fails because the forwarder’s IP isn’t in the original domain’s SPF:

sender@company.com → employee@firm.com → employee@gmail.com
                                         ↑
                           Forwarding server IP fails SPF

This led to SPF being too aggressive being problematic for legitimate mail.

Current State

Status: Limited Effectiveness (alone)

SPF is necessary but not sufficient. It solves one specific problem (envelope spoofing) but leaves gaps:

Detection Guidance

Log Analysis

Look for SPF failures in mail logs:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of ceo@bigbank.com does not designate 198.51.100.5 as permitted sender)

SIEM Queries

Alert on SPF failures from sensitive domains:

email.authentication.spf.result:fail
AND email.from.domain:("yourdomain.com" OR "partner.com")

SPF Record Auditing

Regularly check your SPF records:

dig +short TXT yourdomain.com | grep spf

Common misconfigurations:

• Missing -all (using ~all or ?all)
• Too many DNS lookups (max 10)
• Overly broad includes (authorizing services you don’t use)
• No SPF record at all

SPF Weaknesses and Improvements

SPF introduced its own attack surface and implementation challenges:

Lookup Limit Exploitation

RFC 7208 limits SPF to 10 DNS lookups. Organizations with complex cloud infrastructure often exceed this limit, causing SPF to permanently fail (PermError). Attackers exploit broken SPF records where legitimate and spoofed mail are indistinguishable.

See: SPF Lookup Limit Exploitation

Misconfiguration Exploitation

Common misconfigurations like +all (permit everyone), ~all (soft fail), overly permissive includes, and missing subdomain records create exploitable gaps that attackers actively scan for.

See: SPF Misconfiguration Exploitation