How to prevent email spoofing?

Preventing Email Spoofing: Complete Guide

Email spoofing—forging the sender address to appear as someone else—is one of the most common attacks. Attackers spoof your domain to send phishing emails, steal credentials, facilitate fraud, and damage your reputation. Preventing email spoofing requires implementing multiple technical controls.

Understanding Email Spoofing

How Spoofing Works

Real protocol:
Attacker → Attacker's mail server → Recipient mail server → Recipient
With fake From: [email protected]

Without authentication:
Recipient sees email from yourdomain.com
Doesn't know it came from attacker's server
Trusts email as if it came from you

Why Spoofing Is Dangerous

1. Phishing: Emails appear legitimate, trick users into clicking
2. Fraud: Fake invoices, payment requests from "CFO"
3. Reputation damage: Your domain associated with phishing/spam
4. Credential theft: Users reply with passwords or sensitive info
5. Malware distribution: Malicious attachments from "trusted" sender

The Three-Pillar Email Authentication Framework

Pillar 1: SPF (Sender Policy Framework)

Purpose: Specify which servers can send email from your domain

How it works:

1. Mail server receives email
2. Server checks SPF record for domain
3. Looks up sending server's IP in record
4. If IP listed: SPF pass
5. If IP not listed: SPF fail

SPF Record Example:

example.com TXT: v=spf1 include:_spf.google.com include:sendgrid.net ~all

Components:

• v=spf1: SPF version
• include:: Include another domain's SPF
• ip4:192.0.2.1: Specific IP allowed
• ~all: Soft fail (accept but mark)
• -all: Hard fail (reject)

Setting up SPF:

1. Create TXT record: v=spf1 [includes] [policy]
2. Include all services sending as your domain
3. Test with: dig example.com TXT
4. Use ~all initially, then -all after testing

Limitations:

• Only checks sender IP
• Doesn't authenticate message content
• Doesn't prevent display name spoofing

Example protection:

Legitimate: email from 192.0.2.1 (Google's server) → SPF pass
Spoofed: email from 192.0.2.99 (attacker's IP) → SPF fail

Pillar 2: DKIM (DomainKeys Identified Mail)

Purpose: Cryptographically sign emails to prove authenticity

How it works:

1. Mail server signs email with private key
2. Recipient mail server gets public key from DNS
3. Server verifies signature with public key
4. Valid signature: Email definitely from your domain
5. Invalid/missing: Email not authenticated

DKIM Record:

selector1._domainkey.example.com TXT: "v=DKIM1; k=rsa; p=[PUBLIC_KEY]"

Setting up DKIM:

1. Generate public/private key pair
2. Put public key in DNS TXT record
3. Configure mail server to sign with private key
4. Test with: dig selector._domainkey.example.com TXT

Example:

Legitimate: Email signed with your private key → DKIM pass
Spoofed: Email can't be signed (no private key) → DKIM fail

Advantages over SPF:

• Cryptographic proof, not just IP-based
• Survives forwarding (signature attached to message)
• Can't be spoofed with correct signature

Pillar 3: DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Purpose: Enforce SPF/DKIM alignment and set handling policy

How it works:

1. Email received
2. Check SPF result
3. Check DKIM result
4. Check if From domain aligns with SPF/DKIM domain
5. If not aligned: Apply policy (reject, quarantine, etc.)
6. Send reports to monitoring address

DMARC Record:

_dmarc.example.com TXT: "v=DMARC1; p=reject; rua=mailto:[email protected]"

Components:

• v=DMARC1: Version
• p=reject: Policy (none/quarantine/reject)
• sp=quarantine: Subdomain policy
• rua=: Aggregate report address
• ruf=: Forensic report address
• pct=: Percentage subject to policy
• adkim=s: Strict DKIM alignment
• aspf=s: Strict SPF alignment
• fo=1: Forensic options

Policies:

• p=none: No enforcement, monitoring only
• p=quarantine: Route to spam folder
• p=reject: Reject entirely (hardest fail)

Setting up DMARC:

Step 1: Monitor Phase

_dmarc.example.com: v=DMARC1; p=none; rua=mailto:[email protected]
# No enforcement, just monitoring

Step 2: Quarantine Phase (after 1-2 weeks)

_dmarc.example.com: v=DMARC1; p=quarantine; pct=50; rua=...
# Send 50% of failures to spam

Step 3: Enforcement Phase (after 1-2 weeks)

_dmarc.example.com: v=DMARC1; p=reject; pct=100; rua=...
# Reject all failures

DMARC Protection:

Attacker sends email:
- SPF fail (not on IP list)
- DKIM fail (no private key to sign)
- DMARC policy reject
- Email rejected entirely
- No phishing possible

Complete Email Spoofing Prevention Strategy

Step 1: Inventory All Senders

Find all services sending as your domain:

Legitimate senders:
- Google Workspace
- Microsoft 365
- SendGrid (marketing)
- Zendesk (support)
- DocuSign (contracts)
- Your IT department
- Any other apps/services

How to find:

• Check email headers (Received-from: fields)
• Review application configurations
• Ask department heads
• Check mail logs

Step 2: Implement SPF

Create SPF record:

# Start with ~all (soft fail)
v=spf1 include:_spf.google.com include:sendgrid.net ~all

# Breaks down to:
# - Google's servers can send
# - SendGrid's servers can send
# - Any other server: soft fail

Update DNS:

1. Add TXT record
2. Wait for propagation (4-24 hours)
3. Verify with: dig example.com TXT

Test SPF:

# Send test email
# Check SPF result in headers
Authentication-Results: example.com;
  spf=pass (google.com: domain SPF authorized)

Step 3: Implement DKIM

Generate DKIM keys:

# Using OpenDKIM
opendkim-genkey -b 2048 -d example.com -s selector1

# Creates:
# - selector1.private (private key - keep secret!)
# - selector1.txt (public key - for DNS)

Configure mail server:

# Add to OpenDKIM configuration
Domain                example.com
Selector              selector1
KeyFile               /path/to/selector1.private

Publish public key in DNS:

selector1._domainkey.example.com TXT: "v=DKIM1; k=rsa; p=[KEY]..."

Test DKIM:

# Send test email
# Check headers for DKIM signature
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
  s=selector1; [signature data]

Step 4: Implement DMARC

Create DMARC policy:

# Phase 1: Monitor
_dmarc.example.com TXT: v=DMARC1; p=none; rua=mailto:[email protected]

# Phase 2: Quarantine (after 1-2 weeks of monitoring)
_dmarc.example.com TXT: v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]

# Phase 3: Reject (after 1-2 weeks of quarantine)
_dmarc.example.com TXT: v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s

Publish DMARC record:

1. Add TXT record in DNS
2. Wait for propagation
3. Verify with: dig _dmarc.example.com TXT

Monitor reports:

• Analyze aggregate reports (rua emails)
• Identify failing legitimate senders
• Fix SPF/DKIM for those senders
• Then increase enforcement

Step 5: Subdomain Protection

Protect subdomains:

_dmarc.mail.example.com: v=DMARC1; p=reject
_dmarc.newsletters.example.com: v=DMARC1; p=reject
_dmarc.support.example.com: v=DMARC1; p=reject

Or inherit from parent:

_dmarc.example.com: v=DMARC1; p=reject; sp=reject
# sp= applies to subdomains

Additional Protections

BIMI (Brand Indicator for Message Identification)

Display logo in email clients:

default._bimi.example.com TXT: v=BIMI1; l=https://example.com/logo.svg

Requirements:

• DMARC p=reject policy
• Valid SVG logo (<32KB)
• HTTPS-hosted logo

Result: Users see your logo for authenticated emails

TLSRPT (TLS Report)

Get TLS connection failures:

_tlsrpt.example.com TXT: v=TLSRPTv1; rua=mailto:[email protected]

DANE (DNS-based Authentication of Named Entities)

Advanced certificate verification: Requires DNSSEC and complex setup, but provides strongest TLS protection

Verification and Testing

Test SPF

# Query SPF record
dig example.com TXT

# Send test email, check headers
Authentication-Results: example.com;
  spf=pass (domain designates mail.google.com as permitted sender)

Test DKIM

# Check DKIM record published
dig selector._domainkey.example.com TXT

# Send test email, look for DKIM-Signature header
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;

Test DMARC

# Check DMARC record
dig _dmarc.example.com TXT

# Send test email from authorized server
# Should pass both SPF and DKIM
# Then align correctly

Online Testing Tools

• MXToolbox (SPF, DKIM, DMARC checker)
• Google Admin Toolbox
• CheckTLS
• DMARC Report tools

Common Mistakes to Avoid

Mistake 1: Not Including All Senders in SPF

Problem:

v=spf1 include:_spf.google.com ~all
# Missing SendGrid, Zendesk, etc.

Result: Those senders fail SPF

Solution: Include all legitimate senders

Mistake 2: Too-Strict Policy Too Soon

Problem:

p=reject with untested implementation
# Legitimate mail rejected
# Service disruption

Solution: p=none → p=quarantine → p=reject gradually

Mistake 3: Not Configuring DKIM Signing

Problem:

Have DKIM public key in DNS
But mail server not actually signing messages
DKIM fails

Solution: Verify mail server signs outgoing messages

Mistake 4: Forgetting About Subdomains

Problem:

Primary domain protected
newsletters.example.com unprotected
Attacker spoofs newsletter domain

Solution: Protect subdomains with own DMARC or inherit policy

Mistake 5: Not Monitoring Reports

Problem:

DMARC reports sent but never read
Legitimate senders failing
Don't know about problems

Solution: Monitor rua/ruf reports regularly

Measuring Success

Metrics to Track

SPF coverage: % of senders aligned
DKIM coverage: % of senders signing
DMARC compliance: % of email passing DMARC
Spoofing attempts: # blocked by DMARC
User reports: # of spoofing emails reported

Dashboard Example

All mail sent from domain:
- 99% passes SPF
- 98% passes DKIM
- 97% passes DMARC alignment

Failed:
- 1% - internal system not DMARC aligned
- 1% - third-party service misconfigured
- 1% - legacy email system

Action: Fix those 3% to reach 100%

Complete Implementation Timeline

Week 1: Preparation

• Inventory all senders
• Plan SPF/DKIM/DMARC
• Collect DNS records needed

Week 2-3: Implement

• Deploy SPF record
• Generate DKIM keys
• Deploy DKIM to DNS
• Publish DMARC with p=none

Week 4-6: Monitor

• Review DMARC aggregate reports
• Identify failing legitimate senders
• Fix those senders' authentication

Week 7-8: Quarantine

• Change DMARC to p=quarantine
• Monitor for legitimate mail in spam
• Fix any remaining issues

Week 9-10: Enforce

• Change DMARC to p=reject
• Final verification
• Setup monitoring and alerting

Conclusion

Email spoofing prevention requires implementing three complementary techniques:

1. SPF: Verify sender IP
2. DKIM: Cryptographically sign messages
3. DMARC: Enforce alignment and policy

This combination protects your domain from being spoofed, phishing emails from appearing legitimate, and your reputation from being damaged.

Following a gradual rollout (monitor → quarantine → reject) minimizes disruption while maximizing protection. Monitoring reports ensures legitimate senders aren't broken in the process.

Organizations that implement all three technologies effectively eliminate nearly all email spoofing attacks against their domain.