Email Spoofing: How Attackers Forge Your Domain and How to Stop Them

Email spoofing is the act of forging the sender address on an email so it appears to come from someone else, typically a trusted person or organization. Unlike spam, spoofed emails are crafted to exploit trust: they impersonate a CEO, a bank, a vendor, or a colleague. The recipient sees a familiar name and acts on it.

This is not a theoretical attack. Business Email Compromise (BEC) caused $2.9 billion in losses in 2023 according to the FBI IC3 report, making it the single most costly category of cybercrime by reported losses. The median wire transfer in a BEC attack was $50,000. And the underlying technique in the majority of cases is email spoofing.

Sources: FBI IC3 Report 2023, Deloitte Cyber Threat Report 2024, Valimail Email Fraud Landscape 2024

How email spoofing works

Email was designed in 1982 (RFC 822) with no built-in authentication. The SMTP protocol lets any sender specify any address in the From: header. There is no verification at the protocol level. This is equivalent to writing any return address on a physical letter.

A spoofed email requires only a few lines of raw SMTP:

EHLO attacker.com
MAIL FROM:<ceo@yourcompany.com>
RCPT TO:<finance@yourcompany.com>
DATA
From: John Smith <ceo@yourcompany.com>
To: finance@yourcompany.com
Subject: Urgent wire transfer needed
Date: Mon, 25 Mar 2026 09:00:00 +0100

Please process a $47,000 transfer to the attached
account by end of day. I'm in meetings and can't talk.
.
QUIT

The MAIL FROM (envelope sender) and the From: header (display sender) can both be forged independently. Most email clients only show the From: header, making the forgery invisible to the recipient.

The five types of email spoofing

Domain spoofing is the most dangerous because the email looks identical to a legitimate one. Without SPF, DKIM, and DMARC, there is no technical mechanism for the receiving server to distinguish it from a real email.

SPF: Sender Policy Framework

SPF (RFC 7208) lets a domain owner publish a DNS TXT record listing the IP addresses authorized to send email for that domain. When a receiving server gets an email claiming to be from yourcompany.com, it looks up the SPF record and checks whether the sending IP is authorized.

; SPF record for yourcompany.com
yourcompany.com. IN TXT "v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.10 -all"

; Breakdown:
; include:_spf.google.com  → Allow Google Workspace servers
; include:amazonses.com    → Allow Amazon SES (transactional email)
; ip4:203.0.113.10         → Allow this specific server
; -all                     → REJECT everything else (hard fail)

The critical detail is the -all vs ~all distinction. A hard fail (-all) tells receivers to reject unauthorized senders. A soft fail (~all) merely flags them, and most receivers still deliver to inbox. According to Valimail, 57% of domains still use ~all or no SPF at all.

SPF alone has a critical limitation: it only validates the envelope sender (MAIL FROM), not the header From: that users see. An attacker can pass SPF by using their own domain in the envelope while spoofing the visible From: header. This is why DKIM and DMARC are essential.

DKIM: DomainKeys Identified Mail

DKIM (RFC 6376) adds a cryptographic signature to every outgoing email. The sending server signs selected headers and the body with a private key. The public key is published in DNS. The receiving server verifies the signature, confirming two things: the email was authorized by the domain owner, and the content was not tampered with in transit.

; DKIM signature header (added by sending server)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.com; s=google;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AXNxP0QktZ...long base64 signature...

; DNS TXT record (public key)
google._domainkey.yourcompany.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgk..."

; Verification: receiving server fetches the public key from DNS
; and verifies the signature against the email content.

DKIM protects against content tampering and confirms domain authorization, but it does not tell the receiving server what to do when verification fails. That is where DMARC comes in.

DMARC: Domain-based Message Authentication

DMARC (RFC 7489) is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication: nothing (p=none), quarantine it (p=quarantine), or reject it outright (p=reject). It also enables reporting so domain owners can see who is sending email using their domain.

; DMARC record for yourcompany.com
_dmarc.yourcompany.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-rua@yourcompany.com; ruf=mailto:dmarc-ruf@yourcompany.com; pct=100"

; Breakdown:
; p=reject       → Reject emails that fail DMARC (production policy)
; sp=reject      → Same policy for subdomains
; adkim=s        → Strict DKIM alignment (d= must exactly match From:)
; aspf=s         → Strict SPF alignment (MAIL FROM must match From:)
; rua=mailto:... → Aggregate reports (daily XML summaries)
; ruf=mailto:... → Forensic reports (individual failure details)
; pct=100        → Apply policy to 100% of emails

The key concept is alignment. DMARC requires that either SPF or DKIM authenticates the domain in the visible From: header, not just the envelope sender. This closes the gap that SPF alone leaves open.

Only 17% of domains worldwide enforce DMARC with p=reject. This means 83% of domains are either partially protected or fully spoofable. The gap is even wider for SMBs, where DMARC adoption at enforcement level drops below 5%.

Deploying DMARC: the correct sequence

Deploying DMARC incorrectly can break legitimate email delivery. The standard approach is a phased rollout over 4 to 8 weeks:

Common mistakes during deployment: forgetting third-party senders (marketing platforms, CRMs, ticketing systems), not configuring DKIM for SaaS tools that send on your behalf, and jumping straight to p=reject without a monitoring period.

Beyond DMARC: BIMI and MTA-STS

BIMI (Brand Indicators for Message Identification) lets organizations display their verified logo next to authenticated emails in supporting clients (Gmail, Apple Mail, Yahoo). It requires DMARC at p=quarantine or p=reject and a Verified Mark Certificate (VMC) from a certificate authority. BIMI makes spoofing visually obvious to recipients because only authenticated emails display the brand logo.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) forces SMTP connections between mail servers to use TLS encryption. Without MTA-STS, an attacker performing a man-in-the-middle attack on the SMTP connection can downgrade it to plaintext and read or modify emails in transit. MTA-STS eliminates this by publishing a policy that requires TLS with valid certificates.

; MTA-STS policy (hosted at https://mta-sts.yourcompany.com/.well-known/mta-sts.txt)
version: STSv1
mode: enforce
mx: mx1.yourcompany.com
mx: mx2.yourcompany.com
max_age: 604800

; DNS record to advertise MTA-STS
_mta-sts.yourcompany.com. IN TXT "v=STSv1; id=20260325"

Real-world spoofing attacks

How to test your domain's spoofing resistance

Testing your email authentication setup is straightforward. Here are the exact commands to audit your domain:

# Check SPF record
dig TXT yourcompany.com | grep "v=spf1"

# Check DKIM (replace 'google' with your selector)
dig TXT google._domainkey.yourcompany.com

# Check DMARC record
dig TXT _dmarc.yourcompany.com

# Check MTA-STS
dig TXT _mta-sts.yourcompany.com
curl https://mta-sts.yourcompany.com/.well-known/mta-sts.txt

# Test actual email authentication (send a test email to)
# check-auth@verifier.port25.com (free, returns full auth results)
# or use: https://www.learndmarc.com (visual DMARC tester)

A complete email security audit should verify: SPF record exists with -all, DKIM is configured for all sending services, DMARC is at p=reject with reporting enabled, no orphan include: directives in SPF pointing to decommissioned services, and all subdomains are covered by sp=reject.

Complete anti-spoofing checklist