What is email spoofing?

Email spoofing is the practice of forging the sender information on an email so the message appears to come from someone other than its actual origin. The attacker does not need to break into the impersonated person's account or infrastructure. They only need to set the fields a mail client displays to the recipient, most often the "From" name and address, to whatever identity they want to borrow.

This works because the core protocol that moves email, SMTP, was designed in the early 1980s for a small, trusted network of research institutions. It has no built-in way to verify that the sender named in a message is the party that actually sent it. Anyone who can talk to a mail server can claim to be anyone else. That gap is what spoofing exploits, and it is why spoofed email remains one of the most common opening moves in phishing, business email compromise, and malware delivery.

This guide explains how email spoofing works, the techniques attackers use, and how SPF, DKIM, and DMARC close the gap that makes spoofing possible.

How email spoofing works

Every email has two sets of sender information, and this distinction is central to understanding spoofing.

• The envelope sender (MAIL FROM). This is the address used during the actual SMTP transaction between mail servers. It is what bounce messages and delivery failures go to. Recipients never see it directly.
• The header sender (From). This is the address and display name shown in the recipient's inbox. It is set inside the message content itself, not negotiated between servers.

Because the header From field is just a line of text inside the message, a sender can put almost anything there. Standard mail-sending libraries, scripting languages, and even basic command-line tools let anyone set this field to an arbitrary address. A receiving mail server that performs no additional checks will accept the message and display whatever From value the sender supplied, exactly as if it were genuine.

A typical spoofing attempt follows a simple sequence:

1. Pick an identity to borrow. The attacker chooses a person or organization the target is likely to trust: a company the target does business with, an executive at the target's own company, a bank, or a well-known brand.
2. Craft the message. The attacker sets the From header (and often the Reply-To header) to match the trusted identity, writes content designed to prompt a click, a reply, or a payment, and sends it through any mail server willing to relay it.
3. Deliver it. Unless the receiving server checks whether the sending server was actually authorized to send on behalf of that domain, the message arrives looking exactly like it came from the trusted source.

Common spoofing techniques

Spoofing shows up in a few recognizable forms, and attackers often combine them.

• Exact domain spoofing. The From header uses a real, exact domain the target trusts, such as an email that claims to be from billing@yourcompany.com when it did not originate from any server your company controls.
• Display name spoofing. The visible name matches a trusted contact, such as "Jane Smith, CEO," while the underlying email address is unrelated and easy to miss on a phone screen or a quick glance at an inbox list.
• Lookalike and cousin domains. A closely related but technically different tactic, where the attacker registers a domain that resembles the real one, such as substituting a zero for the letter O or adding an extra word. This is domain impersonation rather than spoofing in the strict sense, since the attacker owns the lookalike domain, but it is frequently paired with spoofing tactics and aimed at the same outcome.
• Compromised account abuse. Also distinct from spoofing. Here the attacker has actually gained access to a real mailbox and sends from the genuine address. It is worth naming alongside spoofing because the outcome for the recipient looks similar, even though the underlying mechanism and the defenses that stop it are different.

What attackers use spoofed email for

Spoofing is rarely the end goal. It is the delivery mechanism for something else.

• Business email compromise (BEC). An email that appears to come from a company executive or a known vendor instructs a finance employee to change payment details or rush a wire transfer. The FBI's Internet Crime Complaint Center has consistently ranked BEC among the costliest categories of reported cybercrime.
• Credential phishing. A spoofed message impersonating an IT department, a bank, or a SaaS provider directs the recipient to a fake login page that harvests their password.
• Malware delivery. Spoofed messages carrying malicious attachments or links are more likely to be opened when they appear to come from a coworker or a trusted partner.
• Brand and reputation damage. Even when no account is ever breached, a company whose domain is spoofed to send spam or scam messages can suffer real damage: recipients associate the abuse with the brand, and legitimate mail from that domain can end up flagged as spam.

How SPF, DKIM, and DMARC prevent spoofing

Three DNS-based email authentication standards address the gap in SMTP that makes spoofing possible. Each one solves a different part of the problem, and they are designed to be used together.

SPF: Sender Policy Framework

SPF lets a domain owner publish a list of mail servers and IP addresses that are authorized to send email on behalf of that domain. This list is stored as a DNS TXT record.

When a receiving mail server gets a message, it checks the domain used in the envelope sender (MAIL FROM) and looks up that domain's SPF record. If the message came from a server on the authorized list, SPF passes. If it came from anywhere else, SPF fails.

SPF has two significant limitations. It only checks the envelope sender, not the visible From header a recipient actually sees, so it does nothing on its own to stop display name or exact-domain spoofing in the header. It also breaks when a message is forwarded, because the forwarding server becomes the new source IP and is typically not on the original sender's SPF list.

DKIM: DomainKeys Identified Mail

DKIM takes a different approach. The sending domain generates a cryptographic key pair, publishes the public key in DNS, and uses the private key to sign each outgoing message. The signature covers specific header fields and the message body, and it is added to the message as a header of its own.

When a message arrives, the receiving server retrieves the public key from the sender's DNS record and uses it to verify the signature. If the signature is valid, two things are confirmed: the message was signed by a party holding the domain's private key, and the signed content was not altered in transit.

DKIM's limitation mirrors SPF's in reverse. A valid DKIM signature proves the message was signed by whatever domain appears in the signature, but that signing domain does not have to match the domain shown in the visible From header unless something else enforces that connection.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

DMARC is the layer that ties the other two together and gives them teeth. It does two specific things that neither SPF nor DKIM does alone.

First, it introduces alignment. DMARC checks whether the domain that passed SPF, or the domain that passed DKIM, actually matches the domain in the visible From header the recipient sees. A message can pass SPF and DKIM individually and still fail DMARC if neither of those passing checks is aligned with the header From domain, which is exactly the gap that header spoofing relies on.

Second, it gives the domain owner a way to tell receiving servers what to do with mail that fails alignment, through a policy published in a DNS record:

• p=none. Take no action, but report on failures. Used for monitoring during setup.
• p=quarantine. Deliver failing messages to spam or junk folders.
• p=reject. Block failing messages from being delivered at all.

DMARC also supports aggregate and forensic reporting, so domain owners receive regular reports showing who is sending mail using their domain, whether it is passing authentication, and where enforcement is catching abuse. This reporting is often how organizations first discover that their domain is being spoofed at scale.

How the three work together

Each protocol closes a gap the others leave open. SPF authorizes sending servers but ignores the visible From header. DKIM authenticates message content and its signing domain but does not require that domain to match what the recipient sees. DMARC requires that at least one of SPF or DKIM pass and align with the visible From domain, and it gives domain owners enforcement and visibility over the result.

A domain with only SPF configured can still be spoofed in the From header. A domain with only DKIM configured has the same exposure. A domain with a DMARC policy of p=reject, backed by properly configured and aligned SPF and DKIM, is very difficult to spoof convincingly, because a forged message will fail alignment and be blocked before it reaches an inbox.

What developers and domain owners can do

Publish and maintain accurate SPF records

List every service that sends mail on your domain's behalf: your own servers, transactional email providers, marketing platforms, and any support or CRM tools. An incomplete SPF record causes legitimate mail to fail, which teams often "fix" by weakening enforcement rather than correcting the record.

Sign outgoing mail with DKIM everywhere

Every sending path needs its own DKIM configuration, since a signature from one provider does not cover mail sent through another. Use a key length of at least 2048 bits, and rotate keys periodically so a compromised key has a limited window of use.

Roll out DMARC gradually, starting with monitoring

Publish a DMARC record at p=none first and route the aggregate reports somewhere your team actually reviews. This surfaces every legitimate sending source, including ones that may have been missed in the SPF record, before enforcement can break real mail. Once reports show clean alignment, move to p=quarantine, and eventually to p=reject.

Cover subdomains explicitly

Attackers frequently target unused or unmonitored subdomains that inherit no protection unless a DMARC policy explicitly applies to them. A sp=reject tag in the DMARC record extends enforcement to subdomains that do not send mail at all.

Treat this as an ongoing requirement, not a one-time setup

Since February 2024, Google and Yahoo have required bulk senders, generally those sending upward of 5,000 messages a day to their users, to authenticate mail with SPF and DKIM and to have a DMARC record with alignment in place. Mailbox providers increasingly treat missing or misconfigured authentication as a strong spam signal on its own, independent of message content.

Don't rely on the From header for identity in your own product

If you build a product that displays sender identity to users, whether that's an inbox, a support tool, or a notification feed, don't treat the visible From name as ground truth. Surface authentication status where you can, and be cautious about auto-trusting a message based on display name alone.

The bigger picture

Email spoofing persists because it targets a structural gap in a protocol that was never built with authentication in mind, not a flaw in any particular mail provider or client. SPF, DKIM, and DMARC do not patch SMTP directly. Instead, they add a verification layer on top of it, using DNS as a place to publish trust and cryptography as a way to prove it.

None of the three is sufficient alone, which is why mailbox providers are increasingly requiring all three together and why enforcement, not just presence, is what actually stops forged mail from reaching an inbox. For any organization sending email under its own domain, configuring SPF, DKIM, and DMARC correctly, and moving deliberately toward a p=reject policy, is one of the highest-leverage security changes available, because it closes off a channel that attackers have relied on for decades.