SPF Bypass

This attack focuses on bypassing Sender Policy Framework (SPF) email authentication to send spoofed emails that appear to come from a legitimate domain.

Attack Summary: Bypassing SPF authentication to send spoofed emails that appear to come from a legitimate domain.

Background: Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email authentication method designed to detect forged sender addresses during the delivery of email. SPF allows domain owners to specify which mail servers are authorized to send email on behalf of their domain.

SPF works by:

The domain owner publishes an SPF record in their DNS, listing authorized mail servers
When a receiving mail server gets an email, it checks the sender's domain SPF record
The receiving server verifies that the sending mail server is authorized in the SPF record
If the sending server is not authorized, the email may be rejected or flagged

Despite its widespread adoption, SPF has several limitations and vulnerabilities that can be exploited to bypass its protection.

Attack Methodology

This attack involves exploiting various limitations and vulnerabilities in SPF to send spoofed emails that bypass SPF checks.

Return-Path vs. From Header Mismatch

Exploiting the difference between envelope and header addresses

This variant exploits the fact that SPF only checks the envelope sender (Return-Path) and not the From header that is displayed to users.

Return-Path vs. From Example

Exploiting the difference between envelope and header addresses

# Send an email with a legitimate Return-Path but a spoofed From header telnet mail.example.com 25 HELO attacker.com MAIL FROM: legitimate@attacker.com RCPT TO: victim@target.com DATA From: ceo@trusted-company.com To: victim@target.com Subject: Urgent Wire Transfer Please process this wire transfer immediately. . QUIT

Explanation: In this example, the attacker uses their own domain (attacker.com) in the MAIL FROM command, which will pass SPF checks because the attacker controls the SPF record for attacker.com. However, the From header displayed to the recipient shows ceo@trusted-company.com, making it appear that the email came from the CEO of a trusted company.

How It Works

Attacker sends an email using their own domain in the MAIL FROM command
The receiving server checks the SPF record for the attacker's domain
The SPF check passes because the attacker controls the SPF record for their domain
The email is delivered with a spoofed From header
The recipient sees the spoofed From header, not the legitimate Return-Path

Null Return-Path

Using a null Return-Path to bypass SPF

This variant exploits the fact that some mail servers do not properly handle emails with a null Return-Path.

Null Return-Path Example

Using a null Return-Path to bypass SPF

# Send an email with a null Return-Path telnet mail.example.com 25 HELO attacker.com MAIL FROM: <> RCPT TO: victim@target.com DATA From: ceo@trusted-company.com To: victim@target.com Subject: Urgent Wire Transfer Please process this wire transfer immediately. . QUIT

Explanation: In this example, the attacker uses a null Return-Path (MAIL FROM: <>), which is typically used for bounce messages. Some mail servers do not properly check SPF for emails with a null Return-Path, allowing the attacker to spoof the From header.

Null Return-Path Handling

Different mail servers handle null Return-Paths differently:

Skip SPF: Some servers skip SPF checks for null Return-Paths
Check domain in From: Some servers check the SPF record for the domain in the From header
Accept without checking: Some servers accept emails with null Return-Paths without any checks
Reject: Some servers reject emails with null Return-Paths

SPF Softfail Exploitation

Exploiting SPF softfail policies

This variant exploits domains that use SPF softfail (~all) instead of hardfail (-all) policies.

SPF Softfail Example

Exploiting SPF softfail policies

# Check for domains with softfail policies dig +short TXT example.com # Example output v=spf1 include:_spf.google.com ~all # Send a spoofed email from a domain with a softfail policy telnet mail.example.com 25 HELO attacker.com MAIL FROM: spoofed@example.com RCPT TO: victim@target.com DATA From: spoofed@example.com To: victim@target.com Subject: Urgent Wire Transfer Please process this wire transfer immediately. . QUIT

Explanation: In this example, the attacker identifies a domain (example.com) that uses a softfail policy (~all) in its SPF record. The attacker then sends an email spoofing this domain. Because the domain uses a softfail policy, the email may still be delivered even though it fails SPF checks, possibly with a warning or a higher spam score.

SPF Policy Types

SPF records can specify different policy types:

-all (hardfail): Unauthorized servers should be rejected
~all (softfail): Unauthorized servers should be accepted but marked
?all (neutral): No policy statement about unauthorized servers
+all (pass): All servers are authorized (dangerous)

SPF Record Limitations

Exploiting limitations in SPF records

This variant exploits various limitations in SPF records, such as the maximum number of DNS lookups.

SPF Lookup Limitation Example

Exploiting the maximum DNS lookup limitation

# Check for domains with complex SPF records dig +short TXT complex-example.com # Example output v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org include:sendgrid.net include:spf.mandrillapp.com include:servers.mcsv.net include:_spf.createsend.com include:amazonses.com include:spf.messagelabs.com include:mail.zendesk.com ~all # Send a spoofed email exploiting the lookup limitation telnet mail.example.com 25 HELO attacker.com MAIL FROM: spoofed@complex-example.com RCPT TO: victim@target.com DATA From: spoofed@complex-example.com To: victim@target.com Subject: Urgent Wire Transfer Please process this wire transfer immediately. . QUIT

Explanation: In this example, the attacker identifies a domain (complex-example.com) with a complex SPF record that includes many other domains. SPF has a limit of 10 DNS lookups, and if this limit is exceeded, the SPF check may fail open (allowing the email) or perma-fail (rejecting all emails, including legitimate ones). The attacker exploits this limitation to send a spoofed email.

SPF Record Limitations

SPF has several limitations that can be exploited:

Maximum 10 DNS lookups: SPF has a limit of 10 DNS lookups
Maximum 255 characters: DNS TXT records are limited to 255 characters
No support for nested includes: SPF doesn't handle nested includes well
No wildcards for subdomains: SPF doesn't support wildcards for subdomains
No redirect loops: SPF doesn't handle redirect loops well

Impact

This attack allows attackers to:

Send spoofed emails that bypass SPF checks
Make emails appear to come from legitimate domains
Conduct phishing attacks with higher success rates
Potentially damage the reputation of legitimate domains

Detection

Organizations can detect these attacks by:

Implementing additional email authentication mechanisms (DKIM, DMARC)
Checking for mismatches between Return-Path and From header
Monitoring for emails with null Return-Paths
Checking for emails that exploit SPF record limitations

Mitigation

To protect against these attacks, organizations should:

Implement DMARC: DMARC can help prevent From header spoofing
Use hardfail: Use -all (hardfail) in SPF records instead of ~all (softfail)
Simplify SPF records: Keep SPF records simple to avoid exceeding the 10 DNS lookup limit
Check both headers: Configure mail servers to check both Return-Path and From header
Reject null Return-Paths: Configure mail servers to reject emails with null Return-Paths from untrusted sources
Implement DKIM: DKIM can provide additional authentication that SPF doesn't cover

Testing

Security professionals can test for this vulnerability using the following approach:

Check the target domain's SPF record for weaknesses
Test sending emails with mismatched Return-Path and From headers
Test sending emails with null Return-Paths
Test sending emails that exploit SPF record limitations
Check if the emails are delivered and how they are displayed to recipients

References

RFC 7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email." https://tools.ietf.org/html/rfc7208
RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance (DMARC)." https://tools.ietf.org/html/rfc7489
Chen, J., Duan, H., Weaver, N., Paxson, V., & Jiang, J. (2021). "Measuring and Mitigating Email Sender Spoofing Attacks." In Proceedings of the 30th USENIX Security Symposium.
Foster, I. D., Larson, J., Masich, M., Snoeren, A. C., Savage, S., & Levchenko, K. (2015). "Security by Any Other Name: On the Effectiveness of Provider Based Email Security." In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security.

Previous: DKIM Bypass Next: Header Manipulation