What Is Email Spoofing? How It Works

A finance clerk gets an email from the CEO. The display name is right, the signature is right, the tone is right, and the request is simple: approve the attached invoice before end of day. The clerk replies, the payment goes out, and only later does anyone notice the message never came from the CEO at all. The From header said it did. The mail server that sent it had nothing to do with the company. That is email spoofing, and it cost nothing but a forged header to pull off.

Email spoofing forges the sender identity of a message so it appears to originate from a trusted person or organization. It exploits a design fact of email that has been true since the protocol was written: the address a recipient sees in the From line is not verified by default. An attacker can put anything there. Spoofing turns that gap into a weapon, lending a malicious message the credibility of a name the target already trusts.

This guide covers what email spoofing is, why the SMTP protocol allows it, the techniques attackers use from outright header forgery to lookalike domains, how spoofing feeds phishing and the wider attack chain, and the controls a blue team uses to detect and stop it. It is written for defenders who have to catch this in mail headers, authentication results, and user reports.

What is email spoofing?

Email spoofing is a technique in which an attacker forges the sender address of an email so the message appears to come from a source the recipient trusts. The forged From address is the bait. It borrows the identity of a colleague, an executive, a bank, or a vendor, so the recipient lowers their guard before reading the request or clicking the link.

The defining feature is that the attack targets trust in an identity, not a software flaw. A recipient has been trained to check who a message is from before acting on it. Email spoofing defeats that check by making the sender field say whatever the attacker wants. No exploit is required to land the message. The control surface is the recipient's belief about who sent it.

That matters for defense. There is no patch for it, because nothing is broken in the traditional sense. The original email protocol simply was not built to verify the sender, and spoofing lives in that gap. The fix is authentication that machines can check and process that does not depend on a human trusting a From line.

Why email spoofing is possible

Email runs on the Simple Mail Transfer Protocol (SMTP), which was designed in an era of trusted, cooperating networks. SMTP does not require the sender to prove ownership of the address in the From header. The header is just text the sending client supplies, and a receiving server will accept it as written unless something else checks it.

It helps to separate two layers that both carry a "sender." The envelope sender, also called the MAIL FROM or return-path, is what mail servers use to route and bounce the message. The header From, the address displayed in the mail client, is what the human reads. SMTP lets an attacker set these independently, so a message can route cleanly from an attacker's server while the displayed From reads [email protected]. Nothing in the base protocol forces the two to match or to be true.

This is why email spoofing is a protocol weakness rather than a vulnerability in any one product. Every fix layered on top, SPF, DKIM, and DMARC, exists to add the sender verification that SMTP never had. Where those records are missing or weakly configured, the forged header sails through.

Types and techniques of email spoofing

Attackers forge the sender in a few distinct ways, ranging from faking the header outright to registering a domain that reads as legitimate. They differ in how durable they are and in which control catches them.

Display name spoofing. The simplest form. The attacker leaves the actual email address alone but sets the display name to a trusted person, so the inbox shows Jane Doe (CEO) while the underlying address is a random Gmail account. On a phone, where many clients hide the address entirely and show only the name, this is highly effective. It requires no infrastructure and bypasses domain authentication completely, because the attacker never claims your domain.

Header From forgery. The attacker sets the visible From header to a trusted domain outright, such as [email protected], while sending from an unrelated server. This is the classic spoof SMTP allows by default. It is exactly what SPF, DKIM, and DMARC are built to reject, so it succeeds mainly against domains that have not deployed those records or that publish a weak DMARC policy.

Lookalike (cousin) domains. Instead of forging your exact domain, the attacker registers one that resembles it and sends from there. A typosquat like paypa1.com for paypal.com, a combosquat like microsoft-support.net, or a different top-level extension. Because the mail genuinely originates from a domain the attacker owns, it can pass that domain's own SPF and DKIM checks. Authentication on your domain does not help, because the attacker is not claiming your domain. The tell is the domain string itself.

Homograph and Unicode tricks. A lookalike domain built from non-Latin characters that look identical to Latin letters, such as a Cyrillic "a" in place of a Latin "a." The result is visually indistinguishable from the real domain and is encoded behind the scenes in Punycode with an xn-- prefix. It defeats the advice to check the address, because the displayed address looks correct.

Compromised legitimate accounts. Not strictly spoofing, but the same effect with none of the tells. If an attacker takes over a real mailbox, the mail is genuinely from that address and passes every authentication check. This is the engine behind most business email compromise, and it is why authentication alone is not the whole answer.

How email spoofing fits the attack chain

Email spoofing is rarely the goal. It is the delivery and credibility stage that makes the next move work. Verizon's 2026 Data Breach Investigations Report attributes 62% of breaches to the human element and finds phishing was the initial access vector in 16% of breaches, and a forged or lookalike sender is what makes much of that phishing believable in the first place.

A common sequence runs like this. The attacker forges or mimics a trusted sender and sends a phishing message that survives the recipient's "who is this from" check. The message carries a link to a credential-harvesting page, a malicious attachment, or a plain request to act. The recipient trusts the sender and complies. From there the intrusion moves on: a harvested credential becomes account takeover, an opened attachment becomes a malware foothold, and a trusted request becomes fraud.

The highest-cost variant skips malware entirely. In business email compromise, the spoofed or compromised sender makes a fraudulent payment or invoice-change request look like ordinary business from a real executive or vendor, and the money moves on trust alone. The pattern to internalize is that the forged sender buys credibility, and everything downstream spends it.

Detection and prevention for blue teams

You cannot stop a recipient from trusting a familiar name, so the defense moves to authentication that machines verify, detection built on the headers rather than the display, and process that does not hang on a human reading a From line. Layer these controls.

Enforce email authentication: SPF, DKIM, and DMARC. These three close the forged-From gap that SMTP leaves open. SPF (Sender Policy Framework) publishes, in DNS, the mail servers allowed to send for your domain, so a receiver can reject mail from servers not on the list. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature proving the message was not altered in transit and genuinely came from your domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties them together: it tells receiving servers to quarantine or reject mail that fails SPF or DKIM AND requires the authenticated domain to align with the visible From address, which is the one users actually read. Publish a DMARC record at p=reject once reporting confirms your legitimate mail passes. SPF and DKIM on their own do not protect the visible From; DMARC alignment is what does.

Inspect the headers, not the display name. The forensic truth is in the full headers. Build detection on the Authentication-Results line (SPF, DKIM, and DMARC pass or fail), on a mismatch between the envelope sender and the header From domain, and on newly seen sender domains. Surface a clear external-sender banner and a lookalike-domain warning in the client so the recipient sees it before acting.

Catch lookalike domains and display-name fraud. Authentication on your own domain does nothing against a cousin domain the attacker owns or a display-name spoof from a free mailbox. Watch certificate transparency logs and newly registered domains for strings that resemble your brand, including Punycode xn-- registrations, and write rules that flag when a display name claims an internal executive but the address is external.

Train on the address, not the name. Teach users that the full sender address and the domain, not the display name or the logo, are the identity to check, and that a brand name in a display name proves nothing. Reinforce that any urgent request to move money, change payment details, or hand over credentials gets verified through a separate, known channel regardless of how right the sender looks.

Wire it into detection and IR. Feed authentication results, mail-gateway logs, and proxy data into your SIEM so a reported spoof correlates with the click, the credential entry, and the follow-on logins. When a spoofed message leads to a click or a transfer, the indicators it carries, the sending IP, the lookalike domain, the URLs, seed the hunt and the incident response.

The throughline across all of these: stop relying on a person to spot a forged sender, and start verifying senders with protocols and monitoring that do not blink.

Frequently Asked Questions

What is email spoofing?

Email spoofing is a technique in which an attacker forges the sender address of an email so it appears to come from a trusted person or organization. It exploits the fact that the base email protocol does not verify the From address by default, letting an attacker lend a malicious message the credibility of a name the recipient already trusts. It is most often the opening stage of phishing or fraud.

What is the difference between email spoofing and phishing?

Phishing is the broader attack: a fraudulent message that manipulates a person into handing over data, credentials, or money. Email spoofing is one of the techniques that makes phishing convincing, by forging the sender so the message looks like it comes from a trusted source. Not all spoofing is phishing, and not all phishing uses spoofing, but the two are frequently combined.

Why is email spoofing possible?

Email runs on SMTP, a protocol designed for trusted networks that does not require a sender to prove ownership of the address in the From header. The header is just text the sender supplies, and a receiving server accepts it as written unless SPF, DKIM, and DMARC are configured to verify it. Spoofing lives in that gap.

How do SPF, DKIM, and DMARC stop email spoofing?

SPF lists which servers may send mail for your domain, DKIM cryptographically signs messages to prove they were not altered and came from your domain, and DMARC ties both to the visible From address and tells receivers to quarantine or reject mail that fails. SPF and DKIM alone do not protect the From header users see; a DMARC policy at p=reject is what closes that gap.

Can SPF, DKIM, and DMARC stop every spoofed email?

No. They reject mail that forges your exact domain, but they cannot stop a lookalike (cousin) domain the attacker owns, since that mail passes the attacker's own authentication. They also cannot stop display-name spoofing from a free mailbox or mail sent from a genuinely compromised account. Those require header inspection, lookalike-domain monitoring, and out-of-band verification.

How do you detect a spoofed email?

Read the full headers rather than the display name. Check the Authentication-Results line for SPF, DKIM, and DMARC pass or fail, look for a mismatch between the envelope sender and the header From domain, and examine the sender domain for typos, extra words, or xn-- Punycode. Treat a familiar display name paired with an unfamiliar or external address as a strong warning sign.

The bottom line

Email spoofing forges the one thing a recipient is told to trust: the sender. It works because the base email protocol never verified the From address, so an attacker can claim any identity at no cost. It is the credibility stage of phishing and fraud, and asking a person to catch a forged sender by eye is a losing game.

For defenders, the move is to stop relying on the human eye. Enforce SPF, DKIM, and DMARC so messages that forge your domain are rejected before delivery, monitor for lookalike and Punycode domains that authentication cannot touch, build detection on the headers rather than the display name, and verify any money or access request out of band. Authenticate the sender with protocols, and the spoof stops being convincing.