Email Domain Spoofing & DMARC

Timeline: The Cat and Mouse

2007 ← Attack emerges → 2012 ← Industry responds → 2015 ← Attackers adapt → Present

The Evolution

Key Events with Sources

Overview

SPF validated envelope senders. DKIM validated message integrity. But neither required the authenticated domain to match what users see in the From: header, and neither told receivers what to do on failure. DMARC closes these gaps by requiring alignment between authenticated domains and the visible sender, plus specifying a policy for handling failures.

The Attack

The Alignment Gap

Before DMARC, this email would pass both SPF and DKIM:

MAIL FROM: <bounce@attacker.com>          ← SPF passes (attacker's domain)
DKIM-Signature: d=attacker.com; ...       ← DKIM passes (attacker's signature)
From: ceo@bigbank.com                     ← User sees this (spoofed!)

Both authentication mechanisms pass, but neither validates that the visible From: header is legitimate. The user sees ceo@bigbank.com and trusts it.

The Policy Gap

Even when SPF or DKIM failed, receivers had no guidance:

• Should I reject the message?
• Should I quarantine it?
• Should I accept it and hope for the best?

Without policy, most receivers accepted failures to avoid blocking legitimate mail. Attackers exploited this permissiveness.

Real-World Attack Patterns

CEO Fraud / BEC:

Envelope: bounce@randomdomain.com      (SPF pass)
DKIM: d=randomdomain.com               (DKIM pass)
From: CEO Name <ceo@yourcompany.com>   (Spoofed)
Subject: Urgent - Wire Transfer Needed

Vendor Impersonation:

Envelope: notification@attacker.com
From: accounts@trustedvendor.com
Subject: Invoice #12345 - Payment Required
Attachment: invoice.pdf (malware)

Internal Phishing:

Envelope: alerts@evilsite.com
From: IT Support <support@yourcompany.com>
Subject: Password Expires in 24 Hours
Body: Click here to reset...

How DMARC Works

The Defense Mechanism

DMARC adds three critical components:

1. Alignment — Authenticated domain must match From: header domain
2. Policy — Domain owner specifies what to do on failure
3. Reporting — Receivers send reports back to domain owner

DMARC Record Anatomy

Published as DNS TXT record at _dmarc.example.com:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; adkim=s; aspf=r

Policy Options

Alignment Explained

Relaxed Alignment (default):

• From: user@mail.example.com
• SPF/DKIM domain: example.com
• Result: Pass (organizational domain matches)

Strict Alignment:

• From: user@mail.example.com
• SPF/DKIM domain: example.com
• Result: Fail (exact domain doesn’t match)

The Full Authentication Flow

┌─────────────────────────────────────────────────────────┐
│                   Incoming Email                        │
│  Envelope: bounce@mail.example.com                      │
│  DKIM: d=example.com                                    │
│  From: user@example.com                                 │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│  1. SPF Check                                           │
│     Domain: mail.example.com                            │
│     Result: PASS                                        │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│  2. DKIM Check                                          │
│     Signing Domain: example.com                         │
│     Result: PASS                                        │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│  3. DMARC Alignment Check                               │
│     From Domain: example.com                            │
│     SPF Aligned? mail.example.com → example.com (YES)   │
│     DKIM Aligned? example.com → example.com (YES)       │
│     Result: PASS                                        │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│  4. Apply Policy                                        │
│     DMARC Result: PASS                                  │
│     Action: DELIVER                                     │
└─────────────────────────────────────────────────────────┘

DMARC Failure Example

┌─────────────────────────────────────────────────────────┐
│                   Spoofed Email                         │
│  Envelope: attacker@evil.com                            │
│  DKIM: d=evil.com                                       │
│  From: ceo@bigbank.com                                  │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│  1. SPF Check: evil.com → PASS                          │
│  2. DKIM Check: d=evil.com → PASS                       │
│  3. DMARC Alignment:                                    │
│     From: bigbank.com                                   │
│     SPF domain: evil.com → NOT ALIGNED                  │
│     DKIM domain: evil.com → NOT ALIGNED                 │
│     Result: FAIL                                        │
│  4. Policy (bigbank.com): p=reject                      │
│     Action: REJECT                                      │
└─────────────────────────────────────────────────────────┘

Attacker Adaptation

Post-DMARC Attack Vectors

1. Cousin Domains (Lookalikes)

DMARC protects bigbank.com but not similar domains:

• bigb4nk.com — Character substitution
• bigbank-secure.com — Added words
• bigbank.co — Different TLD
• bígbank.com — Homograph (Unicode)

Attackers register these, set up their own SPF/DKIM/DMARC, and send authenticated spoofs.

2. Display Name Abuse

DMARC doesn’t validate display names:

From: "ceo@bigbank.com" <random@attacker.com>

The actual address is attacker.com (passes DMARC for attacker’s domain), but users see “ceo@bigbank.com” in some email clients.

3. Subdomain Exploitation

If bigbank.com has p=reject but doesn’t have records for subdomains:

From: ceo@mail.bigbank.com

May not be covered if subdomain policy (sp=) isn’t set.

4. Compromised Third Parties

If your domain authorizes a third-party sender (newsletter service, CRM) and that service is compromised, attackers can send authenticated email as you.

5. p=none Exploitation

Many domains deploy DMARC with p=none for monitoring and never upgrade to enforcement. Attackers check DMARC records before spoofing:

dig +short TXT _dmarc.target.com
# v=DMARC1; p=none; ...  ← No enforcement, safe to spoof

Current State

Status: Active Defense (but not complete)

DMARC at p=reject effectively prevents direct domain spoofing. However:

2024 Gmail/Yahoo Requirements

Major providers now require DMARC for bulk senders:

• Must have DMARC record (at minimum p=none)
• SPF and DKIM must pass
• From header must align
• Easy unsubscribe required

This has accelerated DMARC adoption significantly.

Detection Guidance

DMARC Report Analysis

Aggregate reports (RUA) show authentication results for your domain:

<record>
  <source_ip>198.51.100.5</source_ip>
  <count>1000</count>
  <policy_evaluated>
    <disposition>reject</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
</record>

This shows someone trying to spoof your domain from IP 198.51.100.5—investigate.

What to Monitor

• Legitimate failures — Your own systems failing DMARC (misconfiguration)
• Spoofing attempts — External IPs failing DMARC for your domain
• Volume spikes — Sudden increase in failures may indicate active campaign
• New sources — Unknown IPs attempting to send as you

DMARC Record Auditing

Check your DMARC configuration:

dig +short TXT _dmarc.yourdomain.com

Common issues:

• p=none deployed and never upgraded
• Missing subdomain policy (sp=)
• Report addresses that don’t exist or aren’t monitored
• Overly relaxed alignment (adkim=r; aspf=r) when strict would work

Recommended Implementation Path

1. Deploy p=none
   ↓
2. Monitor reports for 2-4 weeks
   ↓
3. Fix legitimate authentication failures
   ↓
4. Move to p=quarantine
   ↓
5. Monitor for false positives
   ↓
6. Move to p=reject
   ↓
7. Maintain and monitor ongoing

Defense in Depth

DMARC is essential but should be combined with:

• User training — Recognize cousin domains and display name tricks
• Lookalike domain monitoring — Alert on registration of similar domains
• Email security gateways — Additional content/behavioral analysis
• BIMI — Visual verification for authenticated senders