Why spoofing works at all

After this lesson you can

Explain precisely which part of SMTP fails to authenticate the sender, and what a receiver can check without help.

Assumes you have read The two From addresses.

Spoofing email is not an exploit. There is no vulnerability involved, no bug being triggered, and nothing being bypassed. It is the protocol working as specified.

What forging actually requires

To send a message that claims to be from ceo@acme.com, an attacker needs a server that can make outbound TCP connections on port 25. That is the entire prerequisite list. They connect to the recipient’s MX host and type:

EHLO anything-i-like.example
MAIL FROM:<whatever@i.choose>
RCPT TO:<victim@target.org>
DATA
From: "Acme CEO" <ceo@acme.com>
Subject: Urgent — wire transfer

Please action the attached immediately.
.

Every name here is chosen by the sender. The protocol has no field for proving any of them.

No password is involved because no account is involved. The attacker is not sending through Acme; they are sending to the victim, and merely claiming Acme in the text. Acme’s servers, Acme’s passwords and Acme’s security posture are not in the path at all.

Why this cannot simply be fixed

RFC 5321 descends from a protocol designed for a network of a few hundred mutually trusting hosts. Adding a mandatory sender-authentication field to SMTP now would mean every server on the internet rejecting mail from every server that had not yet been upgraded. That is why authentication was instead bolted on from the outside, using DNS, in a way that receivers can adopt independently and senders can opt into. It is indirect because it had to be.

What the receiver can actually check

At the moment of decision the receiving server has exactly one fact and three assertions:

Fact: the connecting IP address. The TCP handshake completed, so the attacker genuinely controls routing to that address.
Assertion: the EHLO name.
Assertion: the envelope sender.
Assertion: the header From.

Everything that follows in this course is an attempt to tie one of those assertions to something checkable. SPF ties the envelope sender to the IP address. DKIM ties the message content to a key the domain published. DMARC ties whichever of those passed back to the header From, which is the identity that was deceiving the reader in the first place.

Three attacks that look the same to a user

It is worth separating these now, because they need different defences and only one of them is solved by this track:

Exact-domain spoofing. The From: address is literally ceo@acme.com. This is what SPF, DKIM and DMARC exist to stop, and they stop it well.
Display-name spoofing. The display name says "Acme CEO" and the address is ceo@acme-billing-support.com, which the attacker owns and has authenticated perfectly. Every check passes. Nothing in this track helps.
A lookalike domain. The address is ceo@acrne.com — r and n, not m. The attacker publishes their own SPF, DKIM and DMARC, and the message is fully authenticated as itself.

Two of those three are the subject of the Domain and Brand Security track. That is not a reason to skip this one: exact-domain spoofing is the cheapest attack to run and the only one you can eliminate outright, so it is the right place to start. But a course that let you finish believing the problem was solved would have made you less safe, not more.

Last reviewed 2026-09-12