How Email Spoofing Works: SMTP, From Headers and DMARC

31 May 2026 · 11 min read

Email spoofing is the act of sending a message that claims to come from someone it does not come from. The unsettling part, for most people, is how little effort it takes. There is no clever exploit, no stolen password, no compromised server. The core trick is built into the design of email itself: the protocol that moves mail between servers simply trusts whatever the sender types into the From field. A stranger can put accounts@yourbank.com in that field and press send, and unless the receiving system runs extra checks, the message arrives looking entirely genuine.

This article walks through exactly how that works at the protocol level. We will look at why SMTP, the language mail servers speak, was never designed to verify identity; the crucial distinction between the address used during delivery and the address a human actually reads; the precise steps an attacker follows to forge a message; and finally the three controls (SPF, DKIM and DMARC) that, used together, make spoofing fail. Understanding the mechanism is the first step to defending against it, because once you can see where the trust gap is, the fix becomes obvious.

SMTP was built for a smaller, friendlier internet

The Simple Mail Transfer Protocol, SMTP, dates from 1982. It was written for a network of a few hundred research machines whose operators mostly knew one another. The design goal was to move messages reliably between cooperating systems, not to prove who sent them. Identity verification was simply not a problem anyone needed to solve, so the protocol does not solve it.

To appreciate how open this is, it helps to see an actual SMTP conversation. When one mail server hands a message to another, the exchange looks roughly like this. Lines the sending side types are the commands; the receiving server replies with numeric status codes.

220 mail.example.com ESMTP ready
HELO sender.example
250 Hello sender.example
MAIL FROM:<bounce@sender.example>
250 OK
RCPT TO:<victim@example.com>
250 OK
DATA
354 Start mail input
From: "Your Bank" <accounts@yourbank.com>
To: victim@example.com
Subject: Urgent: verify your account

Click here to confirm your details.
.
250 Message accepted for delivery
QUIT

Look closely at what the sending server actually declared. It announced itself as sender.example. It set a bounce address of bounce@sender.example. And then, inside the DATA section, it wrote a From: line saying the message is from accounts@yourbank.com. Nothing in this conversation checks whether sender.example has any relationship with yourbank.com. The receiving server has no way, from SMTP alone, to know that the From: line is a lie. It accepts the message and the From: header is what the recipient's mail client will display.

That is the whole trick. The protocol asks the sender to assert an identity and then takes the assertion at face value. Spoofing is not breaking SMTP. It is using SMTP exactly as designed.

Two different "from" addresses, and why it matters

The single most important concept in email spoofing, and the one that trips up almost everyone, is that an email has two separate sender addresses. They live in different layers of the message, they serve different purposes, and they do not have to match.

The envelope-from, also called MAIL FROM, the Return-Path, or in the standards the RFC5321.From. This is the address declared during the SMTP conversation, before the message body is even sent. It is used for delivery and for bounce handling: if the message cannot be delivered, the failure notice goes here. The recipient almost never sees it.
The header-from, the From: line inside the message itself, sometimes called the "friendly from" or RFC5322.From. This is the address your mail client shows in the inbox. This is what a human reads, recognises and trusts.

In the SMTP example above, the envelope-from was bounce@sender.example and the header-from was accounts@yourbank.com. They are completely unrelated, and that is perfectly legal SMTP. There are entirely legitimate reasons the two differ: a mailing-list service, a marketing platform, or a help-desk tool will commonly send on your behalf using its own envelope address for bounce processing while putting your brand in the visible From: line. The mechanism that makes legitimate sending-on-behalf-of work is the same mechanism that makes spoofing possible.

This split is the heart of the matter. When the earliest anti-spoofing control, SPF, came along, it checked the envelope-from, because that is the address available at SMTP time. But the address a victim actually sees and trusts is the header-from. An attacker can satisfy a check on one address while forging the other. We unpack the consequences of this gap in detail in DMARC alignment explained; for now, just hold onto the idea that there are two froms and the visible one is the one that was historically unprotected.

The anatomy of a spoofed message

Let us make this concrete by following an attacker step by step. Suppose the goal is a convincing invoice-fraud email that appears to come from billing@acme-supplier.com.

Choose the target identity. The attacker decides the message should display From: "Acme Billing" <billing@acme-supplier.com>. This is just text they will type into the message headers. No access to Acme's systems is required to write it.
Find or run a mail server. They use any server that will speak SMTP to the wider internet. This might be a cheap virtual machine, a misconfigured open relay, a hijacked machine in a botnet, or a throwaway account on a bulk-email service that does not verify sender domains.
Set a workable envelope-from. They pick a bounce address on a domain they control, perhaps bounce@cheapvps.example. This keeps basic delivery mechanics working and, on a poorly defended target, helps the message pass an SPF check for cheapvps.example, a domain that has nothing to do with Acme.
Write the forged headers and body. Inside DATA, they place the spoofed From: line, a plausible subject, a real-looking invoice and new bank details for payment.
Send. The receiving server runs whatever checks it has. If the recipient's domain does no validation, or validates only the envelope, the message lands in the inbox displaying Acme's genuine address.

Notice that at no point did the attacker need a password, a vulnerability, or any privileged access. This is exact-domain spoofing: the visible address is the real domain, spelled correctly, with no lookalike trickery. It is far more dangerous than a typosquatted domain like acme-suppliers.com because there is nothing for an alert human to notice. The address is genuine. Only the authority behind it is fake.

Exact-domain spoofing is what powers business email compromise, fake-invoice fraud and credential phishing. The victim trusts the domain because the domain is real. That is precisely the attack the modern authentication stack was built to stop.

Cousins of spoofing worth distinguishing

Not every deceptive email is exact-domain spoofing, and the distinction matters because the defences differ.

Display-name spoofing changes only the friendly name, not the address: From: "Acme Billing" <random123@gmail.com>. Many mail clients hide the address and show only the name on mobile, so this works without forging any domain at all. Domain authentication cannot stop it because no domain is being forged; user training and client-side warnings are the defence.
Lookalike or cousin domains register a similar-but-different domain, such as acme-supplier.co or acmesupplier.com, and authenticate it properly. The mail is technically legitimate for that domain; the deception is purely visual. Defences here are brand monitoring and registrar takedowns, not DMARC on your own domain.
Compromised-account sending uses real, stolen credentials to send from a genuine mailbox. This is not spoofing at all in the protocol sense; the mail is authentic. It is an account-security problem.

Exact-domain spoofing, where the attacker forges your domain in the header-from without any access to it, is the one that email authentication directly and decisively prevents. The rest of this article is about that.

What actually stops spoofing

There is no single switch. Stopping exact-domain spoofing takes three layers that build on each other. Understanding what each one checks, and what it cannot check, explains why all three are needed.

SPF: which servers may send for a domain

SPF (Sender Policy Framework) lets a domain owner publish, in DNS, the list of servers permitted to send mail for it. A receiving server reads the envelope-from domain, looks up its SPF record, and checks whether the connecting IP address is on the approved list.

An SPF record is a single TXT record:

v=spf1 include:_spf.google.com include:sendgrid.net -all

That authorises Google and SendGrid to send, and tells receivers to reject everything else (-all). You can inspect any domain's record with the SPF checker, and the SPF product page explains it in depth.

SPF has two limitations that matter for spoofing. First, it checks the envelope-from, not the visible header-from, so on its own it does nothing about the address the victim actually reads: our attacker passed SPF for cheapvps.example while forging Acme in the From: line. Second, SPF is fragile in operation. It breaks on forwarding, because the forwarder is not on the original list, and it has a hard limit of ten DNS lookups; exceed it and the result becomes permerror, which we cover in fixing SPF permerror. SPF is necessary, but it secures the wrong "from" to defeat spoofing alone.

DKIM: a signature the receiver can verify

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message. The sending server signs selected headers and the body with a private key; the matching public key sits in the sender's DNS. The receiver fetches the public key, verifies the signature, and learns two things: the message genuinely came from a system holding the private key for the signing domain, and the signed content was not altered in transit.

A DKIM signature names its signing domain in the d= tag, for example d=acme-supplier.com. Because the signature travels inside the message rather than depending on the connecting IP, DKIM usually survives forwarding where SPF does not. You can check a domain's keys with the DKIM checker, and the DKIM product page goes deeper.

But DKIM alone has the same blind spot as SPF: a verified signature for d=somerandomdomain.example proves only that somebody signed the message, not that the signer has any authority over the From: address. An attacker can sign with a domain they own. The signature verifies; it just verifies the wrong domain. Something has to insist that the authenticated domain matches the visible one.

DMARC: tie the checks to the visible From

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that closes the gap. It does not perform a new authentication check of its own. Instead it adds a single, decisive rule: at least one of SPF or DKIM must not only pass its own check, but pass for a domain that matches the header-from the recipient sees. That matching requirement is called alignment, and it is the mechanism that finally defeats exact-domain spoofing. The full mechanics are in DMARC alignment explained.

Walk it back through our attacker. They forged From: billing@acme-supplier.com. Their SPF pass was for cheapvps.example, which does not align with acme-supplier.com. Their DKIM signature, if any, was for a domain they control, which also does not align. With DMARC in force, both authenticated identities fail to match the visible From, so the message fails DMARC. The attacker cannot fix this, because aligning would require SPF or DKIM authority over acme-supplier.com, which is exactly what they do not have.

A DMARC record is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=s; aspf=s

The p=reject policy tells receivers to refuse messages that fail. That instruction is what turns a passive check into an active block. You can read any domain's policy with the DMARC checker, build a record with the DMARC generator, and learn the wider picture on the DMARC product page. To understand what to put in p=, see DMARC policy: none, quarantine or reject.

Why you cannot just switch on p=reject

Here is the operational catch, and the reason spoofing protection is a project rather than a setting. The moment you publish p=reject, every message that fails alignment is refused, including your own legitimate mail that you forgot about. Most organisations send from more sources than they realise: the marketing platform, the invoicing tool, the help desk, the CRM, the HR system, the office printer that emails scans. If any of those is not correctly covered by your SPF record or signing with aligned DKIM, p=reject will block it, and real business mail will silently vanish.

This is why the safe path is staged. You begin at p=none, which changes nothing about delivery but asks receivers to send you reports about who is sending under your domain. Those aggregate (RUA) reports reveal every source, legitimate and not, so you can authenticate the real ones before tightening the policy. The difference between what reports show and what reaches an inbox is covered in DMARC reports versus the inbox, and the report types themselves in DMARC RUA and RUF reports. Only once every legitimate source aligns do you move through p=quarantine to p=reject, at which point spoofing fails and your real mail does not.

Getting from none to reject without an outage is the genuinely hard part. You can read every report and tune every record yourself, or you can use a guided service. Our monitoring watches your reports and alerts you when a new sender or a broken record appears, and the done-for-you path described on the products page takes a domain safely all the way to enforcement.

The practical takeaway

Email spoofing works because SMTP trusts the sender's word, and because the address used for delivery is not the address a human reads. Forging the visible From: line takes no special access, which is what makes exact-domain spoofing so effective and so common. The defence is layered: SPF says which servers may send, DKIM proves a message was signed by a domain, and DMARC insists that one of those authenticated domains matches the visible From and tells receivers to reject anything that does not.

If you want to know where your own domain stands right now, start with the free DMARC checker to see whether you have an enforcing policy, then work through the rest of the diagnostic tools for SPF and DKIM. If the path from p=none to p=reject looks daunting, that is exactly the work DMARC Engine is built to do for you, safely and without losing a single legitimate message.

How email spoofing actually works