How Email Spoofing Works

The core email protocol, SMTP, was designed in the early 1980s for a small, trusted network of researchers. It has no built-in authentication of the sender.

That original trust assumption is why email spoofing is so easy today. Anyone who can talk SMTP to a mail server can claim to be anyone they like, unless additional protections (SPF, DKIM, DMARC) are layered on top.

A crucial concept: an email actually has two sets of addresses, and they need not match.

• Envelope (MAIL FROM) — used by mail servers to route and bounce the message; the user never sees it
• Header From — the 'From:' line displayed in the email client

Spoofing exploits the gap: the visible Header From can say anything, regardless of who really sent the message.

Because SMTP does not verify identity, an attacker can simply set the From header to a trusted address. A raw SMTP conversation looks like this:

Spoofed email is the backbone of major attack categories:

• Phishing — tricking users into entering credentials
• Business Email Compromise (BEC) — impersonating an executive to authorize fraudulent payments
• Malware delivery — attachments that look like they came from a colleague

A message that appears to come from your CEO or your bank is far more likely to be trusted and acted upon.

Exact-domain spoofing forges the From header to use your real domain, for example ceo@yourcompany.com.

This is the most dangerous form because the address is genuinely correct, there is no typo to notice. Without email authentication, a receiving server has no way to know the message did not originate from your real infrastructure.

SPF, DKIM, and DMARC exist primarily to stop exact-domain spoofing.

When authentication blocks exact-domain spoofing, attackers fall back to lookalike domains they actually own and control:

Even with all protections in place, attackers abuse the display name, the friendly text shown before the address.

Many email clients, especially on mobile, show only the display name and hide the actual address. So an email from:

"Acme CEO" <random123@gmail.com>

may appear simply as Acme CEO. The address is legitimate for Gmail, so authentication passes, yet the user is deceived. This is a human problem authentication cannot solve.

To investigate a suspicious message, examine the full headers. They record the path the message traveled and the authentication results.

The Received headers form a chain, read bottom to top, showing each server the message passed through.

Red flags include:

• An originating server that does not belong to the claimed sender
• A mismatch between the Return-Path and the From domain
• Suspicious or unexpected IP geolocations

Combined with the Authentication-Results line, the header chain often exposes a forgery quickly.

Three complementary standards work together to make email trustworthy. Each addresses a different gap:

• SPF — authorizes which servers may send mail for your domain (the envelope sender)
• DKIM — cryptographically signs messages so tampering and forgery are detectable
• DMARC — ties SPF and DKIM to the visible From header and tells receivers what to do on failure

You will study each in the next three lessons.

SPF, DKIM, and DMARC stop exact-domain spoofing of domains you control. They do not stop:

• Lookalike domains the attacker owns and authenticates correctly
• Display-name deception
• Compromised legitimate accounts sending real, authenticated mail

Email authentication is essential, but it must be paired with user awareness training and inbound filtering. Defense in depth applies here too.

Test your understanding of email spoofing.

You learned why email is easy to forge:

• SMTP has no built-in sender authentication
• The envelope sender and the visible Header From need not match
• Spoofing powers phishing, BEC, and malware delivery via exact-domain, lookalike, and display-name tricks
• Email headers and the Authentication-Results line help investigate forgeries
• SPF, DKIM, and DMARC together defend against exact-domain spoofing but are not a complete solution

Next, you will learn how SPF authorizes legitimate sending servers.