Types of Spoofing Attacks: Email, DNS, and IP Spoofing Explained for Security Teams

Spoofing attacks exploit the same architectural gaps they always have. SMTP carries no intrinsic sender identity. DNS responses rely on a 16-bit transaction ID. IP headers contain a source address field that nothing in the protocol validates. The authentication protocols your organization spent months deploying have documented failure modes, and the RFCs themselves say so.

A spoofed email passes SPF, DKIM, and DMARC. The display name matches the CEO, the domain checks out, and the only reason it doesn't result in a wire transfer is because someone on the finance team picks up the phone. That pattern plays out because each protocol addresses one piece of sender identity while leaving the rest exposed.

TL;DR:

• Email authentication protocols have attack surfaces documented in their own RFCs. SPF authenticates the envelope sender, not the visible From header. DKIM signatures can be replayed. DMARC excludes display name attacks from its scope.
• DNS cache poisoning remains an active threat despite years of mitigations. Research and recent resolver vulnerabilities demonstrate that attackers can still undermine source port randomization.
• BCP38 ingress filtering would prevent most IP-spoofed DDoS, but misaligned economic incentives keep deployment incomplete. The network bearing the cost of filtering receives no direct benefit. The result is a tragedy-of-the-commons dynamic that has persisted for over two decades.
• The enforcement gap matters more than the adoption gap. Domains with DMARC monitoring-only policy still receive no spoofing protection.

Email Spoofing: The Authentication Stack Has Documented Limits

SMTP defines separate sender identity fields without built-in sender verification. Both RFC 5321 and RFC 5322 define "From" addresses that can be set to arbitrary values with no intrinsic tie to the originating IP address. That gap enables spoofed mail.

The MAIL FROM envelope sender (RFC 5321) operates at the SMTP session layer and is not displayed to users by default. The From header (RFC 5322) is what the recipient sees in their mail client. SPF, DKIM, and DMARC each address a piece of this problem.

1. SPF: Authenticating the Wrong Field

SPF (RFC 7208) validates whether the sending IP is authorized for the envelope sender domain. It does not evaluate the From header the user reads.

RFC 7208, §11.2 says so: "SPF-Authorized Email May Contain Other False Identities." An attacker who controls attacker.com with a valid SPF record can set MAIL FROM: bounce@attacker.com (SPF passes) while spoofing From: ceo@your-company.com in the message header. Without DMARC enforcement on your-company.com, that message may be delivered.

Multi-tenant hosting environments create a structural variant. Multiple customers share the same IP ranges, and one tenant may send mail that passes SPF for another tenant on the same infrastructure. SPF record syntax alone cannot resolve this.

2. DKIM: Cryptographic Signatures with Known Bypass Paths

DKIM (RFC 6376) adds a cryptographic signature to email headers and body content. When it works, DKIM provides strong assurance that signed content was not modified in transit. The RFC's own security considerations section documents several attack surfaces:

• Body length limits (`l=` tag, §8.2): Signing only the first N bytes allows content appending without invalidating the signature.
• Replay attacks (§8.6): An attacker can reuse a valid DKIM signature from any sending source.
• Header handling: Ambiguities arise when the mail client display diverges from the fields authentication mechanisms validate.

3. DMARC: Enforcement Is Rare, and Scope Is Limited

DMARC (RFC 7489) enforces alignment between authenticated identifiers and the RFC 5322 From header. At p=reject, the MTA rejects failed messages.

Most residual spoofing risk sits in the enforcement gap. Domains at p=none receive reporting but no enforcement, leaving them unprotected despite having a published DMARC record.

RFC 7489, §12.4 identifies display name attacks as outside DMARC's scope. An attacker who sets From: "CEO Name" <attacker@legitimate-domain.com> passes all authentication checks. No email authentication protocol evaluates the display name string. When phishing investigation depends solely on SPF/DKIM/DMARC results, these attacks pass undetected.

4. BEC Has Evolved Beyond Header Spoofing

BEC exposure has accumulated across hundreds of thousands of incidents over the past decade, with reported losses in the tens of billions. SPF, DKIM, and DMARC provide little to no protection against this attack class when executive impersonation happens outside protocol-level sender identity, through lookalike domains, compromised accounts, or voice-based social engineering that never touches a spoofed header. The attack chain and its structural gaps extend well beyond what email authentication was designed to address.

DNS Spoofing: Years of Mitigations, Still Not Solved

DNS cache poisoning exploits a fundamental property of the protocol: DNS responses are authenticated by a 16-bit transaction ID and, post-2008, a randomized UDP source port. The combined attack space is roughly 32 bits. Research and real-world vulnerabilities show attackers can collapse this space.

Attack Vector Evolution

Kaminsky-style attacks established the baseline: flood a recursive resolver with forged responses for all ~65,000 possible TXIDs. Source port randomization raised the attack space to 32 bits as a countermeasure. SAD DNS (2020) collapsed the effective entropy back to the 16-bit TXID by exploiting ICMP rate-limiting behavior to infer the UDP port. TUDOOR (IEEE S&P 2024) went further, exploiting logic-based vulnerabilities in DNS pre-processing across multiple resolver implementations. The most targeted variant exploited a logic vulnerability in Microsoft DNS's response processing to identify the source port and complete the attack in under one second. When resolver software relies on weak randomness for port selection, the port space can collapse without any side channel at all.

DNSSEC: Strong in Theory, Limited in Practice

DNSSEC provides cryptographic authentication of DNS responses through a chain of trust from the root zone. Even a single non-DNSSEC-aware server in the resolution chain can compromise the integrity of the entire DNS resolution process.

Deployment remains limited. The chain-of-trust model requires every resolver and authoritative server in the path to support DNSSEC, and gaps at any point break validation.

Real-World DNS Hijacking Campaigns

The Sea Turtle campaign, active since at least 2017 and still reported on in 2024, compromised DNS providers and registrars to modify DNS records across at least 40 organizations in 13 countries, targeting national security organizations, ministries of foreign affairs, and energy companies. The technique redirected DNS queries to actor-controlled servers presenting spoofed login portals. Most network-layer security tools (IDS/IPS, firewalls) do not inspect DNS record changes at the authoritative level, which leaves these redirections invisible until someone checks resolution data independently.

Passive DNS monitoring offers a detection path. A SANS presentation described a January 2024 case in which automated passive DNS analysis flagged anomalous resolution of a Hungarian domain to new German IPs in a previously unseen ASN.

IP Spoofing: A Structural Vulnerability Sustained by Misaligned Incentives

CAIDA characterizes IP spoofing as the most fundamental vulnerability of the TCP/IP architecture and notes that "the TCP/IP Internet architecture includes no explicit notion of authenticity."

UDP enables the primary attack pattern. With no three-way handshake, an attacker sets the victim's IP as the source address, sends a small query to a reflector service, and the reflector delivers its amplified response to the victim.

Amplification Factors

Reflector protocols vary in how much they amplify a spoofed request. The ratio between the attacker's query size and the reflector's response size determines the volume an attacker can generate per byte sent.

‍

Why BCP38 Remains Incomplete

BCP38 (RFC 2827) specifies a simple control: deploy a filter at the border of each edge network permitting only packets with legitimate source addresses. NIST SP 800-189 recommends source address validation techniques such as access control lists (ACLs) and unicast Reverse Path Forwarding (uRPF). Deployment remains incomplete for two structural reasons:

Misaligned incentives. A network topology research program puts the problem directly: a network that deploys source address validation primarily helps other networks, not itself. The network bearing the operational cost receives no direct protection.

Strict uRPF vs. asymmetric routing. Strict unicast Reverse Path Forwarding checks the source IP against the FIB for the interface. The ingress filtering RFC recommends feasible-path or strict RPF depending on routing topology, and the tradeoff between filtering precision and operational disruption depends on the specific environment.

Decision Criteria for Prioritizing Anti-Spoofing Controls

Prevention controls reduce volume without eliminating risk. The investigation burden falls on the security operations team when prevention fails.

‍

The residual in each category ultimately becomes an investigation problem. Prevention reduces volume, but determining what happened, what was affected, and whether the threat was contained requires investigation and response.  Prioritize the spoofing class where your team has both the highest exposure and the widest enforcement gap.

1. If your domain has DMARC at p=none or no DMARC record, move to enforcement first

Moving from p=none to p=reject with explicit sp=reject for subdomains closes a widely exploited email spoofing vector. Monitoring-only DMARC gives you visibility, not protection.

2. If your DNS infrastructure runs BIND or Unbound, patch and audit PRNG configuration immediately

Source port randomization effectiveness depends on the quality of the underlying randomness. If the PRNG is predictable, the port space collapses and the 32-bit protection reverts to 16 bits. Patching and configuration audits are a prerequisite for DNS security.

3. If prevention is your only defense, build investigation capability around the residual risk

Every anti-spoofing control leaves a documented residual. SPF, DKIM, DMARC, DNSSEC, and BCP38 reduce attack surface, but they do not eliminate it. Display-name impersonation, compromised accounts, DNS provider compromise, and infrastructure-level abuse all remain possible after prevention controls are in place.

The operational challenge begins when prevention fails. Security teams still need to determine what happened, what systems were affected, and whether the threat was contained. The organizations that handle spoofing incidents well are not the ones with perfect prevention. They are the ones with the ability to investigate and respond when prevention controls inevitably miss something.

4. If your BEC risk involves executive impersonation, invest in out-of-band identity verification

Email authentication does not protect against display name attacks (RFC 7489, §12.4). Process controls for high-value transactions are a separate investment from protocol configuration.

Spoofing Prevention Closes Gaps, but the Residual Still Lands on Your Team

SPF, DKIM, DMARC, DNSSEC, and BCP38 each close a specific gap, and each leaves a documented residual. The RFCs themselves say so. Treating any one of these as a solved problem creates the kind of confidence that spoofing campaigns exploit. The controls reduce volume. Your security operations team absorbs what gets through, and that burden lands regardless of how mature your prevention stack is. Start with the spoofing class where your exposure is highest and your enforcement gap is widest. Build detection and investigation capability around the residual that prevention will not catch. Whether that investigation capacity lives in-house or with a managed service, the deciding factor is how much of the investigation and response is completed before the work is handed back to the security team.

Frequently Asked Questions About Spoofing Attacks

Can an Email Pass SPF, DKIM, and DMARC and Still Be Spoofed?

Yes. DMARC alignment checks whether an authenticated SPF or DKIM domain aligns with the visible From header domain, using either exact matching in strict mode or organizational-domain matching in relaxed mode. If the attacker controls a domain with valid SPF and DKIM, their messages will pass all three checks while spoofing the display name to show any identity they choose. RFC 7489 acknowledges this as outside DMARC's scope in §12.4.

How Does DNS Cache Poisoning Succeed Against Resolvers with Source Port Randomization?

Side-channel attacks recover the randomized source port without brute force. SAD DNS (2020) and TUDOOR (2024) each collapsed the 32-bit combined space back toward the 16-bit TXID through different techniques, and weak resolver PRNGs can eliminate the port entropy without any side channel at all. Each countermeasure is a layer that requires ongoing maintenance.

Why Does BCP38 Not Solve IP-Spoofed DDoS if the Standard Has Existed Since 2000?

The incentive structure is backwards. A network deploying BCP38 ingress filtering protects other networks and can also protect itself by preventing spoofed traffic from originating within its own network. But the network bearing the cost of filtering receives the least direct benefit, a tragedy-of-the-commons dynamic that has kept adoption incomplete for over two decades. Topological complexity adds friction: strict uRPF fails on asymmetric routing, and feasible-path uRPF provides incomplete filtering.

How Do DKIM Replay Attacks Work, and What Limits Their Impact?

DKIM verifies message content, not the sending source, so an attacker who obtains a single signed message can redistribute it at scale from any infrastructure (RFC 6376 §8.6). The l= body length tag (§8.2) compounds the risk by letting attackers append content after the signed portion without invalidating the signature. Omitting the l= tag and monitoring for unusual sending volumes of previously signed messages reduce the blast radius but do not fully prevent replay.

What Detection Methods Exist for DNS Hijacking Campaigns Like Sea Turtle?

Detection requires passive DNS monitoring and active auditing of authoritative records. A 2024 case study demonstrated automated passive DNS analysis flagging anomalous resolution of a domain to unfamiliar IPs in a previously unseen ASN. Organizations should monitor for unexpected nameserver delegation changes, unfamiliar IP resolutions, and certificate transparency logs showing certificates issued by unexpected CAs.