KoltrixHow email spoofing works and which records stop it
SMTP lets anyone claim any From address. Follow a spoofed message through a receiver and see exactly where SPF, DKIM and DMARC stop it, and where not.
On this page(9 sections)
SMTP, the protocol that moves email between servers, was designed in an era when everyone on the network knew each other. It lets the sender claim any From address it likes.
Every anti-spoofing technology in use today is a layer bolted on afterward, and each one stops a different part of the attack.
How a spoofed message is built
Imagine an attacker who wants to send a fake invoice that appears to come from [email protected]. They do not need access to your systems. They need a server that can make outbound SMTP connections, and they type something like this:
EHLO attacker-host.example.net
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "Example Billing" <[email protected]>
To: [email protected]
Subject: Invoice 4471 overdue
Please pay the attached invoice today. Our bank details have changed.
.
QUITThere are two separate places where your domain appears:
- The envelope sender in
MAIL FROM. This is used for bounces and is what SPF checks. Recipients rarely see it. - The header From inside the message. This is what the recipient's mail client displays and what people actually trust.
Plain SMTP verifies neither. The rest of this article follows the message to the receiving server and shows which check stops what.
Check 1: SPF looks at the envelope
The receiver takes the domain from MAIL FROM, example.com, and looks up its SPF record. It compares the connecting IP, the attacker's server, against the authorized sources.
example.com. TXT "v=spf1 include:_spf.mailhost.example ~all"The attacker's IP is not listed, so SPF fails (or softfails, with ~all).
What SPF stops: spoofing of your domain in the envelope sender, if the receiver acts on SPF results.
What it does not stop: the attacker can simply use a different envelope sender, one they control, such as [email protected], which passes SPF for their own domain. The header From can still say [email protected]. SPF never looks at the header From.
Check 2: DKIM looks for a valid signature
The receiver looks for a DKIM-Signature header. A spoofed message either has none, or has one signed by the attacker's own domain (d=attacker.example.net), which may verify perfectly.
What DKIM stops: an attacker cannot produce a valid signature with d=example.com without your private key.
What it does not stop: like SPF, DKIM on its own proves only that some domain signed the message. A valid signature from the attacker's domain says nothing about the From header.
Check 3: DMARC ties it to the From header
DMARC is the piece that closes the gap. The receiver takes the domain from the header From, example.com, and looks up _dmarc.example.com:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"DMARC passes only if SPF or DKIM passes and the domain that passed aligns with the From domain. The attacker's SPF pass is for attacker.example.net; not aligned. Their DKIM signature, if any, is for attacker.example.net; not aligned. DMARC fails.
The receiver then applies your policy. With p=reject, a receiver that honors DMARC refuses the message during the SMTP transaction. With p=quarantine, it goes to spam. With p=none, it is delivered or filtered on other signals, and you get a report.
What DMARC stops: exact-domain spoofing of the header From, at receivers that enforce DMARC, once your policy is at enforcement.
Where the protection ends
DMARC is powerful but specific. These attacks pass straight through it:
| Attack | Example | Why DMARC does not help |
|---|---|---|
| Display name spoofing | "Example Billing" <[email protected]> |
The From domain is the attacker's, and it authenticates |
| Lookalike domains | [email protected], [email protected] |
A different domain with its own valid authentication |
| Compromised account | Real [email protected] mailbox taken over |
The mail genuinely comes from your systems |
| Compromised vendor | A supplier's real mailbox sends fraudulent invoices | Authenticated as the supplier |
| Receiver ignores DMARC | Small or misconfigured mail server | Policy is a request, not an enforcement mechanism |
That is why email security programs combine authentication with account security, lookalike-domain monitoring, user awareness and payment verification processes.
Following the receiver's verdict
You can see exactly how a receiver judged a message in its Authentication-Results header. For a spoofed message using the attacker's own envelope sender, it might look like:
Authentication-Results: mx.victim.example;
spf=pass smtp.mailfrom=attacker.example.net;
dkim=none;
dmarc=fail (p=reject) header.from=example.comSPF passed for the wrong domain, there was no DKIM, and DMARC failed for example.com. If p=reject were honored, this message would never have reached a mailbox to be inspected.
How to tell whether someone is spoofing you
You will rarely see spoofed mail yourself, because it is sent to other people. The best visibility comes from DMARC aggregate reports. Once your record has an rua address, participating receivers send daily summaries of every message that used your domain in the From header, grouped by source IP and authentication result.
Spoofing usually shows up as rows where both SPF and DKIM fail alignment and the source IPs belong to networks you have never used: consumer broadband ranges, unfamiliar hosting providers, or servers in regions where you have no infrastructure. A sudden burst of such rows often coincides with a phishing campaign against your customers or partners.
Other signals are more anecdotal but worth taking seriously: customers forwarding suspicious messages to your support team, bounce messages arriving for mail you never sent (backscatter), and partners asking whether a payment request was genuine. Each is a prompt to check reports and confirm your policy is at enforcement.
What to put in place, in order
- SPF listing every legitimate sending source, as a single record under ten DNS lookups.
- DKIM signing with your own domain on every system that sends as you, including vendors.
- DMARC at
p=nonewith aggregate reporting, to discover legitimate senders. - DMARC at
p=quarantine, thenp=rejectonce every legitimate source passes. - The same for every domain you own, including parked ones, which should publish
v=spf1 -all, a null MX andp=reject. - Defenses beyond authentication: multi-factor authentication on mailboxes, lookalike domain monitoring, and out-of-band verification for payment changes.
Key takeaways
- SMTP lets anyone claim any envelope sender and any header From.
- SPF checks the envelope sender, DKIM checks for a valid signature, and neither looks at the visible From on its own.
- DMARC requires an aligned pass for the From domain and tells receivers what to do when it fails.
- At
p=reject, exact-domain spoofing is stopped at receivers that enforce DMARC. - Display names, lookalike domains and compromised accounts need other defenses.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
