Email spoofing is the forgery of the visible sender address on an email, so the message appears to come from someone it did not. It works because plain SMTP treats the From header the recipient sees as free text the sender fills in, with no built-in check that the sender is authorized to use it. The only reliable defense is publishing SPF, DKIM, and a DMARC policy set to p=reject, which lets receiving mail servers reject messages that forge your domain.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The two sender identities in every email
To understand spoofing you have to see that every message carries two separate "from" addresses, and most people never realize they are distinct.
- The envelope sender is set by the SMTP
MAIL FROMcommand during the delivery handshake. After delivery it becomes theReturn-Pathheader, and bounces are sent there. It is normally hidden from the recipient. See what is the Return-Path for the full breakdown. - The header From is carried inside the message body after the
DATAcommand, alongsideReply-To,Subject, andTo. This is the friendly name and address your mail client displays in the inbox.
SMTP was standardized in 1982 (RFC 821) for a small, trusted network. Nothing in the base protocol requires these two addresses to match, and nothing requires either to belong to the party actually connecting. A sending server can state MAIL FROM:<bounce@attacker.example> for the envelope and then write From: "Your Bank" <security@yourbank.com> in the header. The recipient's client shows security@yourbank.com, and the forgery is complete. No software was tricked; the protocol did exactly what it was built to do.
How the From header is forged in practice
Spoofing does not require sophisticated tooling. An attacker connects to a mail server that will accept the message (their own server, a compromised host, or a misconfigured open relay) and speaks raw SMTP:
MAIL FROM:<anything@attacker.example>
RCPT TO:<victim@company.com>
DATA
From: "IT Helpdesk" <helpdesk@company.com>
Subject: Action required: password reset
The From: line is just text inside the DATA block. The server that first accepts the message does not verify it against the connecting party. Because most email clients display only the header From and hide the envelope entirely, the victim sees a message that looks internal. This is why you cannot judge authenticity from the visible sender alone, and why learning how to read email headers matters: the Authentication-Results header records whether the claimed identity actually passed verification.
Three flavors are worth separating, because they are not stopped by the same control:
| Technique | What is forged | Stopped by DMARC reject? |
|---|---|---|
| Exact-domain spoofing | Your real domain, e.g. ceo@yourcompany.com | Yes |
| Lookalike (cousin) domain | A similar domain, e.g. ceo@yourcompany.co | No |
| Display-name spoofing | Only the friendly name; the real address differs | No |
DMARC at p=reject shuts down the first row, which is the most dangerous because it uses your genuine domain. The other two rely on human misreading rather than protocol abuse, including homograph tricks that swap in visually identical Unicode characters, and they need user training, brand monitoring, and inbound filtering to catch.
Real attacks that run on spoofing
Business email compromise (BEC). An attacker forges or closely imitates an executive or supplier address and asks an employee to wire funds or change bank details. BEC is one of the costliest categories of cybercrime: the FBI Internet Crime Complaint Center recorded 21,442 BEC complaints in 2024 with close to $2.8 billion in reported losses, and nearly $8.5 billion across 2022 through 2024. Generative AI has made the messages fluent and hard to spot on tone alone. A defensive playbook lives in the business email compromise checklist.
Brand impersonation and phishing. Attackers spoof banks, shipping carriers, and SaaS providers to send fake invoices, password resets, and delivery notices that push victims toward credential-harvesting pages. When the domain is exactly the real one, even careful users have no visual cue that anything is wrong. That is precisely the gap p=reject closes.
Internal fraud and malware delivery. A message that appears to come from it-support@yourcompany.com carrying a required update attachment gets far higher engagement than an external one. Spoofing the internal domain is the whole point of the attack.
Is email spoofing illegal?
Spoofing sits in a legal gray area, but in the United States the CAN-SPAM Act of 2003 directly prohibits materially false or misleading header information. Your From, To, Reply-To, and routing data, including the originating domain and address, must accurately identify who initiated the message. Falsifying them is a violation, and civil penalties can reach up to $53,088 per individual email under the FTC's 2025 inflation adjustment. The act also carries criminal provisions for aggravated conduct such as relaying through other people's computers to hide a message's origin, registering accounts or domains with false information, and harvesting addresses.
The practical problem is enforcement. Attackers operate across borders, behind compromised infrastructure, and anonymously. The law deters legitimate marketers; it does little to stop criminals. Technical controls are what actually block the mail.
How SPF, DKIM, and DMARC stop spoofing
The three standards were built to attach verifiable identity to messages that SMTP otherwise leaves open. A full walkthrough is in SPF, DKIM, and DMARC explained; here is why each one matters against spoofing specifically.
SPF publishes, in a DNS TXT record, which IP addresses may send mail for your domain, and the receiver checks the connecting IP against that list. Critically, SPF validates the envelope MAIL FROM domain, not the visible header From. An attacker can pass SPF using their own domain in the envelope while forging your domain in the header, so SPF alone cannot stop the spoof the user sees. SPF also has a hard limit of 10 DNS lookups; exceed it and validation returns PermError, which authenticating receivers treat as a failure.
DKIM attaches a cryptographic signature to the message with a private key, and receivers verify it against a public key published at a DNS selector such as selector._domainkey.yourdomain.com. A 2048-bit key is the current recommended strength. DKIM proves the message was not altered in transit and that a specific domain signed it, but on its own it does not require that signing domain to match the visible From.
DMARC is the piece that ties authentication to the address the user actually reads. It requires alignment: the header From domain must match the SPF-authenticated domain, the DKIM-signing domain, or both. Only when an aligned mechanism passes does DMARC pass. You then set a policy that tells receivers what to do with failures:
| Policy | Effect on spoofed mail | Use for |
|---|---|---|
p=none | Monitored only, still delivered | Initial data collection |
p=quarantine | Sent to spam or held | Transitional enforcement |
p=reject | Rejected at the SMTP layer | Full protection |
Exact-domain spoofing survives at p=none and p=quarantine because the message is still delivered somewhere. Only p=reject instructs the receiver to refuse it outright, typically bouncing with a 550 5.7.1 rejection that references DMARC policy. The staged path from monitoring to enforcement is laid out in DMARC policy: none, quarantine, reject, and the complete configuration, including the exact records to publish and the order to publish them, is in how to stop email spoofing of your domain.
Frequently asked questions
Does SPF alone stop email spoofing?
No. SPF only checks the envelope MAIL FROM domain, which the recipient never sees. An attacker can pass SPF with their own domain in the envelope while forging your domain in the visible From header, so you need DMARC alignment and a p=reject policy to protect the address users actually read.
Can email spoofing be blocked completely?
DMARC at p=reject reliably stops exact-domain spoofing, where the attacker uses your real domain. It does not stop lookalike domains, display-name tricks, or a genuinely compromised account, because none of those forge your authenticated domain. Layer user training and brand monitoring on top of authentication.
How can I tell if an email I received was spoofed?
Open the full headers and read the Authentication-Results line. It records whether SPF, DKIM, and DMARC passed for the sending domain; a spoofed message from a protected domain shows dmarc=fail. Do not trust the friendly display name, which is trivial to forge.
Is sending a spoofed email against the law?
In the United States, the CAN-SPAM Act prohibits false or misleading header information, with civil penalties up to $53,088 per email and criminal penalties for aggravated conduct. Enforcement across borders is difficult, so technical controls remain the practical defense.
Spoofing of your own domain is preventable, and the fastest way to know where you stand is to check what you publish today. Run a free SPF, DKIM, and DMARC scan with SPFWise to see whether your domain is currently open to forgery and exactly which record to fix first.