Home › Blog › Email Security Testing
June 27, 2026 · 11 min read · Email Security

Email Security Testing: SPF, DKIM, DMARC and Mail Server Vulnerabilities

Email is one of the most attacked surfaces in any organisation, yet it rarely appears on a web application pentest scope. That's a mistake. A domain with weak email authentication lets attackers send convincing phishing emails that appear to come from your company. A misconfigured mail server can leak internal hostnames, relay spam, or disclose user accounts. Testing email security is not optional — it's part of any thorough AppSec assessment.

This guide covers the full email security testing methodology: DNS record validation (SPF, DKIM, DMARC), SMTP reconnaissance, open relay testing, header analysis, and subdomain-level spoofing. All examples use command-line tools available on Kali Linux.

Why Email Security Belongs in Web App Testing

Your application sends emails — password resets, notifications, invoices, 2FA codes. If an attacker can spoof your domain, they can phish your users with messages that look legitimate. Email authentication failures are a direct path to account takeover at scale.

Beyond spoofing, mail servers can expose:

Phase 1: DNS Record Enumeration

Start with passive enumeration. You need to understand what the domain's DNS says about its email infrastructure before touching anything live.

MX Records

MX records identify which mail servers accept inbound email for the domain.

# Basic MX lookup
dig MX example.com +short

# With full output to see TTLs
dig MX example.com

# Using nslookup
nslookup -type=MX example.com

Note all MX hostnames and resolve them to IPs. Each one is a potential test target.

SPF Records

SPF (Sender Policy Framework) defines which servers are authorised to send email on behalf of a domain. It's a TXT record on the domain itself.

# Look up SPF record
dig TXT example.com | grep spf

# Expected output example:
# "v=spf1 include:_spf.google.com include:mailgun.org ~all"

Key SPF mechanisms to understand:

Exploitable misconfiguration: Domains using ~all (softfail) instead of -all (hardfail) are vulnerable to spoofing when the recipient's mail server doesn't enforce DMARC. Many corporate mail filters accept softfail messages with a warning rather than rejecting them.

SPF Lookup Count

RFC 7208 limits SPF to 10 DNS lookups during evaluation. Exceeding this causes a "permerror" which many mail servers treat as a pass. If a domain has complex SPF with many include: directives, count the lookups — a permerror effectively disables SPF.

# Use online tools or manually trace includes:
dig TXT _spf.google.com | grep spf
# Then trace each nested include recursively and count

DKIM Records

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify message integrity. You need to know the selector name to look up the public key — selectors are typically found in email headers.

# Common selector names: default, google, mail, dkim, s1, s2, k1
# Format: {selector}._domainkey.{domain}
dig TXT default._domainkey.example.com
dig TXT google._domainkey.example.com

# If you have access to a legitimate email from the domain,
# check the DKIM-Signature header for the s= (selector) field:
# DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; ...

DKIM findings to look for:

DMARC Records

DMARC ties SPF and DKIM together and specifies what to do when both fail. Without DMARC, a domain with SPF and DKIM is still vulnerable to display-name spoofing.

# DMARC record lives at _dmarc.{domain}
dig TXT _dmarc.example.com

# Example output:
# "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

DMARC policy values:

Policy Effect Risk
p=none Monitor only — no enforcement Critical — domain is spoofable
p=quarantine Failing email goes to spam Medium — spoofed mail may reach users
p=reject Failing email is rejected outright Low — correct configuration

Also check pct= (percentage of email subject to the policy) — a value less than 100 means partial enforcement. And check subdomain policy with sp= — many organisations lock down the root domain but leave subdomains open.

Automated DNS Check

# Quick automated check with dig and bash
domain="example.com"
echo "=== MX ===" && dig MX $domain +short
echo "=== SPF ===" && dig TXT $domain | grep spf
echo "=== DMARC ===" && dig TXT _dmarc.$domain +short
echo "=== DKIM (default selector) ===" && dig TXT default._domainkey.$domain +short

Phase 2: SMTP Reconnaissance

Once you have the MX hostnames, connect to the SMTP servers directly. This reveals server software versions, supported capabilities, and potential misconfigurations.

Banner Grabbing

# Connect using netcat or telnet
nc -v mail.example.com 25
# Or:
telnet mail.example.com 25

# Expected server greeting:
# 220 mail.example.com ESMTP Postfix (Ubuntu)

# For port 587 (submission) or 465 (SMTPS)
nc -v mail.example.com 587
openssl s_client -connect mail.example.com:465

The banner often reveals the mail server software (Postfix, Sendmail, Exchange, Exim) and version. Check this against CVE databases for known vulnerabilities.

EHLO Enumeration

# After connecting, send EHLO to see supported extensions
EHLO test.example.com

# The server responds with supported capabilities:
# 250-mail.example.com
# 250-PIPELINING
# 250-SIZE 52428800
# 250-VRFY              <- user enumeration possible
# 250-ETRN
# 250-STARTTLS
# 250-AUTH PLAIN LOGIN
# 250 8BITMIME

Look for VRFY and EXPN — these allow username enumeration. If present, test them:

# User enumeration via VRFY
VRFY admin
VRFY postmaster
VRFY root
VRFY sales

# Server responses:
# 252 2.0.0 admin   <- user likely exists
# 550 5.1.1 admin...User unknown  <- user does not exist

TLS Configuration

# Test TLS on SMTP submission (587)
openssl s_client -starttls smtp -connect mail.example.com:587

# Check the certificate and cipher suite in the output
# Look for: TLSv1.2 or TLSv1.3 (reject TLS 1.0/1.1)
# Check certificate validity and hostname match

# Full TLS audit with nmap
nmap -p 25,465,587 --script ssl-enum-ciphers mail.example.com

Phase 3: Open Relay Testing

An open relay accepts email from any sender and forwards it to any recipient. This turns your mail server into a spam relay and is one of the oldest email security failures.

Scope requirement: Open relay testing actively attempts to send email through the server. Always confirm explicit written authorisation before running these tests. Successful relay could result in actual spam delivery.

# Manual open relay test via SMTP
# Connect to port 25 on the target MX
nc -v mail.example.com 25

# After banner:
EHLO test.com
MAIL FROM: <attacker@external.com>
RCPT TO: <victim@external.com>

# A vulnerable server accepts both commands.
# A secure server rejects RCPT TO for non-local recipients:
# 554 5.7.1 Relay access denied
# Automated test with nmap
nmap -p 25 --script smtp-open-relay --script-args smtp-open-relay.domain=example.com mail.example.com

Common relay misconfigurations:

Phase 4: Email Spoofing Tests

Even with SPF and DKIM in place, there are spoofing vectors that survive strict DNS records. The most common is display-name spoofing — the attacker sets a legitimate-looking From display name while using a different envelope address.

Direct Domain Spoofing

Test whether you can send email that claims to be from the target domain. Use a test mail account you control:

# Using swaks (Swiss Army Knife for SMTP)
# Install: apt install swaks

# Attempt to spoof the target domain
swaks --to your-test-account@gmail.com \
      --from spoofed@example.com \
      --server mail.example.com \
      --body "SPF spoofing test"

# If this lands in the inbox (not spam), SPF/DMARC is misconfigured

Subdomain Spoofing

Many organisations lock down their primary domain but forget about subdomains. Check whether subdomains have their own SPF/DMARC or inherit the parent policy:

# Check if subdomains are explicitly covered
dig TXT _dmarc.subdomain.example.com
# If no record exists, the subdomain inherits via sp= in parent DMARC
# If parent DMARC has no sp= or sp=none, subdomain is unprotected

Lookalike Domain Check

Attackers often register lookalike domains (examp1e.com, example-security.com). Check whether common lookalikes have been registered and whether they have SPF/DMARC that could send convincing phishing:

# Generate lookalike candidates
# Tools: dnstwist
pip install dnstwist
dnstwist example.com --registered

# Check if any registered lookalikes have MX records
for domain in $(dnstwist example.com --registered -f list); do
    dig MX $domain +short | grep -q . && echo "$domain has MX"
done

Phase 5: Email Header Analysis

When you receive a legitimate email from the target (marketing email, password reset, etc.), analyse the headers. They reveal internal infrastructure, routing paths, and authentication results.

# In Gmail: open email → three-dot menu → Show original
# In Outlook: open email → File → Properties → Internet headers

# Key headers to analyse:
# Received: - full delivery path, reveals internal hostnames and IPs
# Authentication-Results: - SPF/DKIM/DMARC pass/fail for this message
# X-Originating-IP: - sometimes reveals sender's real IP
# X-Mailer: - reveals email client or sending library
# DKIM-Signature: - find the 's=' selector for DKIM record lookup
# Message-ID: - domain in Message-ID should match From domain

Internal information that commonly leaks through headers:

Phase 6: MTA-STS and DANE

Modern email security includes MTA-STS (SMTP MTA Strict Transport Security) and DANE (DNS-based Authentication of Named Entities), which prevent downgrade attacks on SMTP transport encryption.

# Check MTA-STS policy
# Policy is served over HTTPS at: https://mta-sts.{domain}/.well-known/mta-sts.txt
curl https://mta-sts.example.com/.well-known/mta-sts.txt

# Expected output:
# version: STSv1
# mode: enforce        <- "testing" or "none" means not enforced
# mx: mail.example.com
# max_age: 86400

# Check MTA-STS DNS record
dig TXT _mta-sts.example.com

# Check TLSRPT (TLS reporting)
dig TXT _smtp._tls.example.com

Findings Classification

Finding Severity Business Impact
No SPF record High Domain freely spoofable for phishing
SPF with +all Critical Any server authorised to send — SPF useless
DMARC p=none High Monitoring only, no enforcement — spoofing succeeds
No DMARC record High SPF/DKIM results not enforced at recipient
Open relay High Server used for spam, IP reputation destroyed
VRFY/EXPN enabled Medium Username enumeration enables targeted attacks
STARTTLS not enforced Medium SMTP traffic downgraded to cleartext in transit
Weak DKIM key (<1024 bits) Medium Signatures forgeable with sufficient compute
Internal IPs in headers Low-Info Infrastructure enumeration aids further attacks

Remediation Recommendations

When you find email security issues, these are the specific remediation steps to recommend:

Scan your web application's email touchpoints automatically. Ironimo detects security misconfiguration across your web stack including email-related endpoints — password reset flows, notification triggers, and contact forms that expose your email infrastructure.

Start free scan

Tools Summary

Related guides

Subdomain Takeover Detection and Prevention Information Disclosure Vulnerabilities Testing DNS Security Testing: Rebinding and Hijacking SSL/TLS Security Testing and Configuration OWASP A05 Security Misconfiguration Testing