Domain Spoofing Attacks: How SPF, DKIM, and DMARC Prevent Email Impersonation

Email spoofing is fundamentally an identity-verification flaw in legacy SMTP. SMTP was designed to transport messages without cryptographic proof that the sending infrastructure is authorized to represent the domain in the From: header.

An attacker can easily connect to any unauthenticated Mail Transfer Agent (MTA) and transmit:

MAIL FROM: <attacker@evil.com>
From: CEO <ceo@company.com>
Subject: Urgent Wire Transfer Required

To prevent Business Email Compromise (BEC), executive impersonation, and phishing, modern email security employs a defense-in-depth triad:

1. SPF (RFC 7208): Authorizes which IP addresses and sending hosts can emit mail for a domain.
2. DKIM (RFC 6376): Cryptographically signs message headers and body content with a private key verified via DNS public keys.
3. DMARC (RFC 7489): Bridges authentication to the user-visible From: header and instructs receiving MTAs how to handle failures (none, quarantine, reject).
4. ARC (RFC 8617): Preserves authentication signatures across intermediaries, mailing lists, and forwarding relays.
5. BIMI & VMC: Displays verified company brand logos in supporting mail clients once strict DMARC enforcement is active.

# Query authoritative SPF, DKIM, and DMARC DNS records
dig +short TXT company.com
dig +short TXT _dmarc.company.com
dig +short TXT google._domainkey.company.com

30-Second Triage Table: Common Authentication Failures & Remedies

1. The Multi-Layered Email Authentication Pipeline

When an inbound email arrives at a receiving MTA (Google Workspace, Microsoft 365, Postfix), it passes through a multi-stage evaluation pipeline:

Inbound SMTP Connection
       │
       ▼ [ 1. Ingress Connection & Envelope Check ]
┌────────────────────────────────────────────────────────┐
│ Mail Transfer Agent (MTA) Ingress                      │
│ - Captures Connecting IP (e.g., 198.51.100.25)        │
│ - Inspects RFC 5321.MailFrom (Envelope / Return-Path)  │
└──────────────┬─────────────────────────────────────────┘
               │
               ▼ [ 2. SPF Evaluation (RFC 7208) ]
┌────────────────────────────────────────────────────────┐
│ SPF Policy Verification                                │
│ - Resolves TXT record for Envelope Domain              │
│ - Evaluates IP against authorized CIDR blocks          │
│ - Output: Pass, Fail, SoftFail, PermError              │
└──────────────┬─────────────────────────────────────────┘
               │
               ▼ [ 3. DKIM Cryptographic Verification (RFC 6376) ]
┌────────────────────────────────────────────────────────┐
│ DKIM Signature Verification                            │
│ - Reads 'd=' (Domain) and 's=' (Selector) from header  │
│ - Fetches Public Key from selector._domainkey.domain   │
│ - Computes Body Hash (bh=) & Verifies RSA/Ed25519 Sig  │
│ - Output: Pass, Fail, TempError                        │
└──────────────┬─────────────────────────────────────────┘
               │
               ▼ [ 4. DMARC Alignment & Enforcement (RFC 7489) ]
┌────────────────────────────────────────────────────────┐
│ DMARC Alignment Engine                                 │
│ - Compares RFC 5322.From (Visible From) against:       │
│   a) SPF Envelope Domain (SPF Alignment)               │
│   b) DKIM d= Signature Domain (DKIM Alignment)         │
│ - DMARC PASSES if EITHER (SPF OR DKIM) is PASS + ALIGNED│
└──────────────┬─────────────────────────────────────────┘
               │
        ┌──────┴─────────────────────────┐
        │                                │
        ▼ [ DMARC Pass ]                 ▼ [ DMARC Fail ]
┌──────────────┐                 ┌──────────────────────────┐
│ INBOX        │                 │ Evaluate DMARC Policy:   │
│ (Deliver)    │                 │ ├── p=none       ──► Deliver (Report only)
└──────────────┘                 │ ├── p=quarantine ──► Spam Folder
                                 │ └── p=reject     ──► SMTP 550 Drop
                                 └──────────────────────────┘

[!IMPORTANT] The DMARC Passing Rule: DMARC succeeds if either SPF or DKIM passes and is cryptographically aligned with the domain shown in the user-visible From: header.

2. Envelope Sender vs. Header Sender (RFC 5321 vs. RFC 5322)

The most common source of security confusion is the difference between the Envelope Sender and the Header Sender:

SMTP Envelope (RFC 5321 - Hidden from User)
MAIL FROM: <bounces@mailgun.org>   <--- Evaluated by SPF

Message Payload (RFC 5322 - Displayed in Email Client)
From: Billing Dept <billing@company.com>  <--- Evaluated by DMARC
To: customer@victim.com
Subject: Invoice Overdue

• RFC 5321.MailFrom (Return-Path / Envelope Sender): Used by mail servers for bounce routing. SPF only evaluates this address.
• RFC 5322.From (From: Header): Displayed to end users in Outlook, Gmail, or Apple Mail.
• Why Attackers Exploit This: An attacker can configure SPF perfectly on attacker.com, set MAIL FROM: <hacker@attacker.com> (SPF passes), but set From: ceo@company.com. Without DMARC, the spoofed email lands in the inbox.

3. Sender Policy Framework (SPF) Deep-Dive (RFC 7208)

An SPF record is a single DNS TXT entry published on your domain defining authorized outbound email infrastructure.

; Production SPF Record Example
company.com. IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com include:sendgrid.net -all"

Breakdown of Mechanisms

• v=spf1: Mandatory version tag. (A domain must have exactly one SPF record).
• ip4: / ip6:: Explicit IPv4/IPv6 CIDR ranges authorized to send mail directly. (Consumes 0 DNS lookups).
• include:: Recursively queries another domain's SPF record. Essential for SaaS providers (Google Workspace, SendGrid, Zendesk).
• a / mx: Authorizes the domain's A or MX records. (Consumes DNS lookups—use explicit ip4: instead where possible).
• -all (Hard Fail): Any IP not listed above is explicitly unauthorized and must fail SPF.
• ~all (SoftFail): Unauthorized IPs receive a soft failure (used during migration).

Generate optimized SPF strings with the Pingzo DNS SPF Generator.

The RFC 7208 10-DNS-Lookup Limit

To prevent denial-of-service attacks against DNS root servers, RFC 7208 dictates that evaluating an SPF record cannot trigger more than 10 DNS lookups (include, a, mx, ptr, redirect, exists).

Your Domain: 3 includes (Google, SendGrid, Salesforce)
├── include:_spf.google.com  ──► 3 internal nested lookups
├── include:sendgrid.net     ──► 2 internal nested lookups
└── include:_spf.salesforce.com ──► 6 internal nested lookups
Total DNS Lookups = 11 (EXCEEDS LIMIT!) ──► Evaluator returns "PermError" (SPF Fails!)

Resolving Lookup Exhaustion (SPF Flattening)

When your vendor stack exceeds 10 lookups:

1. Consolidate Vendors: Remove decommissioned marketing tools and test domains.
2. Subdomain Delegation: Move marketing and transactional streams to dedicated subdomains (marketing.company.com and billing.company.com), each maintaining its own 10-lookup budget.
3. Automated Dynamic Flattening: Use automated CI/CD jobs to resolve SaaS include: domains into raw ip4: CIDR ranges, updating DNS automatically upon vendor IP shifts.

4. DKIM: Public-Key Cryptographic Signatures (RFC 6376)

DKIM provides non-repudiation and tamper detection by attaching a cryptographic signature to every outbound email.

The Cryptographic Lifecycle

1. Outbound MTA (Signer)
   ├── Normalizes headers & body (Canonicalization: c=relaxed/relaxed)
   ├── Hashes body (SHA-256) ──► Produces 'bh=' (Body Hash)
   ├── Signs selected headers + bh= using Private Key (RSA-2048 / Ed25519)
   └── Attaches 'DKIM-Signature' header to message

2. Inbound MTA (Verifier)
   ├── Extracts 'd=company.com' and 's=selector1' from DKIM header
   ├── Queries DNS: selector1._domainkey.company.com TXT
   ├── Retrieves Public Key
   ├── Recomputes body hash & compares against 'bh='
   └── Validates RSA/Ed25519 signature against header bytes

Anatomy of a DKIM DNS Record & Signature

; DKIM Public Key published in DNS
selector1._domainkey.company.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0r1m..."

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=company.com;
  s=selector1; t=1712000000;
  h=from:to:subject:date:message-id:content-type;
  bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
  b=Dz4xW1v7Q+...

Canonicalization: Simple vs. Relaxed

• c=simple/simple: Requires exact byte-for-byte fidelity. If an intermediate MTA re-wraps long lines or normalizes CRLF line endings, the signature breaks.
• c=relaxed/relaxed: Recommended for production. Ignores minor whitespace differences, header casing, and trailing whitespace in the body.

5. DMARC: Alignment, Reporting & Staged Enforcement (RFC 7489)

DMARC unites SPF and DKIM by enforcing Identifier Alignment with the user-visible From: address.

; Hardened Production DMARC Record
_dmarc.company.com. IN TXT "v=DMARC1; p=reject; pct=100; aspf=r; adkim=r; rua=mailto:dmarc-reports@company.com; ruf=mailto:dmarc-forensics@company.com"

Identifier Alignment Mechanics

The 3-Stage DMARC Deployment Strategy

Never enable p=reject on Day 1. You risk dropping legitimate invoice, support, or marketing emails.

Phase 1: Monitoring & Discovery (Week 1–4)
v=DMARC1; p=none; rua=mailto:dmarc@company.com
└── Collect XML aggregate reports. Identify all shadow IT & legitimate third-party senders.

Phase 2: Quarantine (Week 5–8)
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@company.com
└── Failed emails routed to Spam folder. Validate zero false positives on business mail.

Phase 3: Hard Enforcement (Week 9+)
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@company.com
└── Receiving MTAs reject unauthorized spoofed mail at SMTP handshake (HTTP 550 Drop).

Verify your DNS records and authoritative name servers with the Pingzo DNS Lookup Tool.

6. ARC (Authenticated Received Chain) & Email Forwarding

When a user sets up auto-forwarding (e.g., user@company.com $\to$ personal@gmail.com), the forwarding MTA changes the connecting IP, breaking SPF. If the forwarding server also appends a disclaimer to the body, it breaks DKIM.

ARC (RFC 8617) solves this by allowing intermediate forwarders to cryptographically seal the original authentication results:

Original Sender ──► Forwarder (Validates SPF/DKIM & signs ARC-Seal) ──► Final Destination
                                                                        └── Evaluates ARC Chain
                                                                            Confirms initial sender was authentic!

7. BIMI: Brand Indicators for Message Identification

BIMI allows organizations that have achieved full DMARC enforcement (p=quarantine at 100% or p=reject) to display authenticated brand logos next to emails in Gmail, Apple Mail, and Yahoo Mail.

; BIMI DNS Record Example
default._bimi.company.com. IN TXT "v=BIMI1; l=https://company.com/assets/logo.svg; a=https://company.com/assets/vmc.pem"

BIMI Prerequisites:

1. DMARC at Enforcement: p=quarantine; pct=100 or p=reject across the root domain.
2. SVG Tiny P/S Format: Logo formatted to the strict SVG Tiny Portable/Secure specification.
3. Verified Mark Certificate (VMC): A digital certificate issued by a trusted CA (DigiCert, Entrust) proving trademark ownership of the logo.

Verify your TLS endpoints hosting the BIMI SVG and VMC with the Pingzo SSL Inspector.

8. Live CLI Diagnostics & Header Inspection Runbook

Step 1: Query Authoritative DNS Records

# Query SPF Record
dig +short TXT company.com

# Query DMARC Record
dig +short TXT _dmarc.company.com

# Query DKIM Selector Public Key
dig +short TXT google._domainkey.company.com

Step 2: Validate DKIM Keys with opendkim-testkey

# Verify DNS syntax and key integrity for selector
opendkim-testkey -d company.com -s google -vvv

Expected output: opendkim-testkey: key OK.

Step 3: Inspect Raw Authentication-Results Headers

In any received email, view the raw RFC 822 source headers:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@mail.company.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounces@mail.company.com;
       dkim=pass header.i=@company.com header.s=selector1 header.b=Dz4xW1v7;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=company.com

Check header formatting and edge propagation using the Pingzo HTTP Header Checker.

9. Continuous DNS Drift & Health Monitoring

Email authentication depends entirely on DNS availability. A single accidental DNS edit or expired third-party SaaS delegation can break outbound company email delivery worldwide.

1. DNS Record Drift Telemetry: Use Pingzo Uptime Monitoring to continuously poll your root TXT, _dmarc, and _domainkey records for unauthorized deletions or modifications.
2. SPF Lookup Depth Alerts: Automatically compute the recursive DNS lookup count of your SPF record. Trigger alerts when the count reaches 8 lookups before hitting the RFC 7208 ceiling of 10.
3. DKIM Key Age & Rotation Tracking: Alert on DKIM selectors older than 180 days to enforce regular cryptographic key rotation.

Test host reachability with the Pingzo Ping Test.

Frequently Asked Questions

If I have SPF with -all, why do I still need DMARC?

SPF only authenticates the envelope sender (MAIL FROM: / Return-Path:), which is invisible to end users. An attacker can pass SPF using their own domain while placing your company's domain in the visible From: header. DMARC is required to enforce alignment between the authenticated domain and the user-visible From: address.

Why does email forwarding break SPF?

SPF validates the IP address of the server connecting to the receiving MTA. When an email is forwarded, the connecting IP belongs to the forwarding server (e.g., an intermediate forwarding service), not the original sender. Because the forwarder's IP is not in the original sender's SPF record, SPF evaluation fails.

What is the difference between rua and ruf in DMARC?

• rua (Aggregate Reports): Daily XML summaries sent by mailbox providers detailing message counts, sending IPs, and SPF/DKIM pass/fail statistics.
• ruf (Forensic / Failure Reports): Redacted real-time copies of individual messages that failed DMARC, used for deep forensic analysis of active spoofing attacks.