Email Spoofing Prevention: SPF, DKIM, and DMARC Explained

Email spoofing is one of the oldest and most effective attack vectors still in widespread use. An attacker sends a message that appears to come from your domain — your brand, your executive team, your support address — and recipients have no way to tell it is forged unless you have configured the right DNS records. This guide explains exactly how spoofing works at the protocol level and walks through the complete technical stack to stop it.

How Email Spoofing Works

The Simple Mail Transfer Protocol (SMTP) was designed in 1982 without authentication. The MAIL FROM envelope address and the From: header address are both free-text fields that any sender can set to any value. When a mail server receives a message claiming to come from cfo@yourcompany.com, it has no built-in way to verify that claim.

Attackers exploit this in three common ways:

Direct domain spoofing — the From: header exactly matches your domain (yourcompany.com)
Display name spoofing — the display name says "Your Company Finance" but the actual address is finance@attacker.com
Cousin domain spoofing — the attacker registers yourcompany-support.com or yourcornpany.com and sends from there

The first type is the most dangerous and the one that SPF, DKIM, and DMARC are specifically designed to stop.

SPF: Authorizing Sending Sources

Sender Policy Framework (SPF) is a DNS TXT record that lists every IP address and mail service authorized to send email on behalf of your domain.

How SPF works

A receiving mail server gets a message claiming to be from yourcompany.com
It performs a DNS TXT lookup for yourcompany.com
It checks whether the sending IP is listed in the SPF record
If the IP is not listed, the SPF check fails

SPF record structure

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all

Key components:

v=spf1 — required version tag
ip4: / ip6: — explicit IP addresses or CIDR ranges
include: — delegate to another domain's SPF record (for third-party senders like GSuite, Mailchimp, SendGrid)
-all — hard fail any source not listed (preferred over ~all softfail)

SPF limitations

SPF only checks the envelope MAIL FROM address, not the From: header that recipients see. An attacker can pass SPF by using their own domain in the envelope while spoofing your domain in the visible From: header. This is why SPF alone is not sufficient — you also need DKIM and DMARC.

SPF also breaks when email is forwarded, because the forwarding server's IP is not in your SPF record.

DKIM: Cryptographic Email Signing

DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to every outgoing message. The receiving server fetches your public key from DNS and verifies the signature, proving the message came from your infrastructure and was not altered in transit.

How DKIM works

Your mail server signs the message headers and body using a private key
The signature is added as a DKIM-Signature header
The receiving server reads the d= (domain) and s= (selector) values from the header
It queries {selector}._domainkey.{domain} for the public key
It verifies the signature against the public key

Example DKIM-Signature header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.com; s=mail2026;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=<base64-encoded-signature>

DKIM DNS record

mail2026._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

DKIM survives forwarding because the signature travels with the message. However, DKIM alone does not prevent spoofing of the From: header either — it only proves the signing domain matches, which could be any domain the attacker controls.

DMARC: Tying It All Together

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the policy layer that makes SPF and DKIM meaningful. It requires that at least one of them aligns with the From: header domain, and it tells receiving servers what to do when alignment fails.

DMARC alignment

SPF alignment — the domain in MAIL FROM matches the From: header domain
DKIM alignment — the d= value in the DKIM signature matches the From: header domain

If an attacker spoofs From: cfo@yourcompany.com but sends through their own infrastructure, neither SPF nor DKIM will align with yourcompany.com, and DMARC will fail.

DMARC record structure

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; ruf=mailto:forensics@yourcompany.com; pct=100; adkim=s; aspf=s"

Key parameters:

p= — policy: none (monitor only), quarantine (send to spam), or reject (block delivery)
rua= — aggregate report destination (daily XML summaries from receiving servers)
ruf= — forensic report destination (per-failure reports)
pct= — percentage of messages the policy applies to (use 100 for full enforcement)
adkim= — DKIM alignment mode: s (strict, exact domain match) or r (relaxed, subdomain match allowed)
aspf= — SPF alignment mode: s or r

Deployment path

Move through policy levels as you gain confidence:

Start with p=none and collect aggregate reports for 2–4 weeks
Analyze reports to identify all legitimate sending sources
Ensure all legitimate sources pass SPF or DKIM alignment
Move to p=quarantine with pct=10, then pct=50, then pct=100
Move to p=reject; pct=100 once you are confident in your sending infrastructure

Common Misconfigurations to Avoid

SPF record with too many lookups — SPF has a 10 DNS lookup limit. Every include: directive counts. Exceeding this causes SPF to permerror, which many receivers treat as a fail. Use tools like MXToolbox SPF Analyzer to count your lookups.

Missing SPF for subdomains — If you send from mail.yourcompany.com, that subdomain needs its own SPF record or a wildcard.

DMARC p=none left indefinitely — Monitor mode is for discovery only. Leaving it there permanently provides no protection. Set a calendar reminder to move to quarantine within 30 days of deployment.

Not protecting parked domains — Every domain you own, including ones you do not send email from, should have a strict DMARC policy. Attackers target parked domains precisely because owners often forget to protect them.

v=spf1 -all

_dmarc.parkeddomain.com  TXT  "v=DMARC1; p=reject;"

Monitoring and Ongoing Maintenance

DMARC aggregate reports are XML files that detail which sources are sending on behalf of your domain, whether they pass SPF and DKIM, and how many messages are involved. Parsing these manually is impractical. Use a DMARC reporting service such as Postmark, Dmarcian, or Valimail to get readable dashboards.

Watch for:

New sending sources appearing in reports (new SaaS tools, new offices)
SPF failures from known-good sources (misconfigured mail servers)
DKIM failures after key rotation (old selector still referenced)
Forensic reports showing active spoofing attempts

Reviewing reports weekly when you first deploy and monthly once enforcement is stable keeps your configuration accurate as your sending infrastructure evolves.