If you’ve ever wondered how attackers send emails that appear to come from your bank, your boss, or even your own company — this post explains the technical mechanisms behind email spoofing and the three standards that prevent it: SPF, DKIM, and DMARC.
These aren’t just IT topics — understanding them helps you identify legitimate emails and protect your own domain from being impersonated.
The Problem: Email Was Not Built for Security
The original email protocol (SMTP, from 1982) has no authentication mechanism. Anyone can claim to be anyone. That’s why you can receive an email that appears to come from president@whitehouse.gov — there’s nothing in the core protocol preventing it.
# This is how simple email forgery is:
# Using a basic SMTP connection, you can type ANY sender address:
telnet mail.example.com 25
> HELO attacker.com
> MAIL FROM: ← Sender claimed, not verified!
> RCPT TO:
> DATA
> Subject: Urgent wire transfer request
> From: CEO John Smith
>
> Please wire $50,000 immediately...
> . SPF, DKIM, and DMARC were created to solve this problem by allowing domain owners to cryptographically prove their identity.
SPF (Sender Policy Framework)
SPF lets domain owners publish a list of IP addresses authorized to send email on their behalf. When your mail server receives an email from company.com, it checks: “Is this IP address allowed to send for company.com?”
# How SPF works:
# 1. Domain owner publishes SPF record in DNS:
example.com TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"
# Breaking this down:
# v=spf1 → This is an SPF record
# ip4:192.0.2.0/24 → Allow emails from this IP range
# include:_spf.google.com → Also allow Google's servers (for Gmail)
# -all → FAIL (reject) any other sender
# 2. Receiving server checks SPF:
# Email arrives from IP 203.0.113.5 claiming to be from example.com
# DNS lookup: does 203.0.113.5 appear in example.com's SPF record?
# NO → SPF FAIL → email is likely spoofed
# Check your domain's SPF record:
nslookup -type=TXT yourdomain.com | grep spf
# Or online: mxtoolbox.com/spf.aspxSPF Limitation
SPF only checks the “envelope sender” (technical header), not the “From” header you actually see in your email client. Attackers can pass SPF while still showing a fake display address.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing emails. The receiving server can verify the signature to prove the email actually came from the claimed domain and wasn’t modified in transit.
# How DKIM works:
# 1. Sending server signs the email with a private key:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=abc123... ← Cryptographic signature of email headers and body
# 2. Public key is published in DNS:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."
# 3. Receiving server verifies:
# - Downloads public key from DNS
# - Verifies signature against the email content
# - If signature matches: DKIM PASS (email wasn't tampered with)
# - If signature fails: DKIM FAIL (email was modified or forged)
# Check DKIM for a domain:
nslookup -type=TXT selector1._domainkey.yourdomain.comDMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when SPF or DKIM fails, and sends you reports on email authentication results from around the world.
# DMARC record example:
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"
# Breaking this down:
# v=DMARC1 → This is a DMARC record
# p=reject → Policy: REJECT emails that fail SPF/DKIM
# (other options: none = monitor only, quarantine = spam folder)
# rua=mailto:... → Send aggregate reports to this address
# pct=100 → Apply to 100% of emails (start with lower pct when testing)
# DMARC policies (implement in order):
# p=none → Monitor mode: collect reports, don't reject anything
# p=quarantine → Send failing emails to spam folder
# p=reject → Block all failing emails completelyHow to Implement Email Authentication for Your Domain
Step-by-Step Implementation
# Step 1: Set up SPF (Google Workspace example)
# Add this DNS TXT record at your domain registrar:
# Name: @ (root domain)
# Value: "v=spf1 include:_spf.google.com ~all"
# (Use -all instead of ~all for strict mode once confirmed working)
# Step 2: Enable DKIM in your email provider
# Google Workspace: Admin Console > Apps > Google Workspace > Gmail
# > Authenticate email > Generate new record
# Copy the TXT record and add it to your DNS
# Step 3: Add DMARC record
# Start with monitoring mode:
# Name: _dmarc
# Value: "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
# Step 4: Review DMARC reports (after 1-2 weeks)
# Free tools: dmarc.postmarkapp.com or dmarcanalyzer.com
# Look for: are legitimate sources passing? Any unexpected sources?
# Step 5: Move to p=quarantine, then p=reject
# Once confident all legitimate email passes, enforce rejectionChecking Email Authentication on Received Emails
# Gmail: Click three dots > Show original
# Look for:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of sender@example.com designates
209.85.220.41 as permitted sender) smtp.mailfrom=sender@example.com;
dkim=pass header.i=@example.com header.s=google header.b=abc123;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
# All three PASS = legitimate email
# Any FAIL = suspicious or spoofed emailWrap Up
SPF, DKIM, and DMARC work together as a layered email authentication system. If you own a domain, implementing all three stops attackers from impersonating you — and helps your legitimate emails avoid spam folders. Start with DMARC in monitoring mode (p=none) to see what’s out there, then gradually tighten the policy.