Guides

Email spoofing: how a forged From works, and what stops it

Last updated 2026-09-11

The From address on an email is a line of text. Whoever sends the message types it, and nothing in the mail protocol checks that it's true. That's email spoofing. The rest of this page is what makes it possible, why the person reading can't tell, and which part of it a DMARC record stops.

Does DMARC stop spoofing? It stops mail that uses your exact domain. It doesn't stop a lookalike domain or a forged display name.

Stop exact-domain spoofing in four steps

1. Publish an SPF record listing every service that sends as your domain. SPF record syntax.
2. Turn on DKIM in each of those services, signing with your domain. How SPF, DKIM and DMARC fit together.
3. Publish a DMARC record at p=none with a reporting address, and read the reports until every real sender passes. DMARC setup.
4. Move the policy to p=reject. From then on, receivers that check DMARC refuse anything with your domain in the From that didn't pass.

How a spoofed email is made

A mail server delivering a message has a short conversation with the receiving server. It says who the message is from, who it's to, and then sends the message itself, headers and all. This is the entire exchange. The forged part is in the last block:

Notice there are two from addresses. The one after MAIL FROM is the envelope: it's where bounces go, and the reader never sees it. The one on the From: line inside the message is the header, and it's what every mail client shows. They don't have to match. The attacker put their own domain in the envelope, so bounces come back to them, and your CEO's address in the header, because that's what the finance team sees.

Doing this takes one command with any mail-sending tool, or a dozen lines of any programming language. There's no exploit. The protocol has worked this way since 1982.

Why the recipient can't tell

The mail client shows the display name first, then the address, and on a phone often only the name. Both came from the forged From: line. Reply goes to the address in Reply-To if there is one, which the attacker also wrote. Nothing on the screen came from anywhere the attacker didn't control.

The only lines the attacker didn't write are the ones the receiving server adds: the Received: headers, and the Authentication-Results line. Those say which server actually connected and what the checks found. They're hidden behind a menu in every client, and almost nobody looks.

The three kinds of spoofing

Spoofing gets used as one word for three different tricks, and they have different defenses.

• Exact-domain spoofing. The From address is dana@yourcompany.example, your real domain, spelled right. This is the one DMARC stops.
• Lookalike domain. The From address is dana@yourcompany-example.com, or yourc0mpany.example, or your name at a domain that's one letter off. The attacker registered it and can set up SPF, DKIM and DMARC for it, all passing. DMARC on your domain has no say, because it isn't your domain.
• Display-name spoofing. The From is "Dana Reyes, CEO" <dana.reyes.ceo@gmail.com>. The address is a real, authenticated free mailbox. Only the name is a lie, and the phone shows only the name.

SPF and DKIM on their own don't stop it

SPF doesn't catch this, and people who've set it up are usually surprised. SPF checks the envelope sender, the MAIL FROM domain, against a list of allowed servers. In the message above the envelope domain is attacker.example, and the attacker's own SPF record says their server is allowed. SPF passes. The forged header was never looked at, because SPF doesn't look at headers.

DKIM is a signature, and a signature proves that whoever holds the key signed the message. The attacker can sign with their own key, for their own domain, and DKIM passes for attacker.example. Again, nothing has compared that to the From the reader sees.

What's missing is the comparison. DMARC adds it. Its rule is that SPF or DKIM has to pass for a domain that matches the From header, which is called alignment. The attacker can make SPF and DKIM pass for their domain all day. They can't make either pass for yours, because they don't control your DNS.

DMARC at p=reject stops exact-domain spoofing

Your DMARC record is one line at _dmarc.yourcompany.example:

A receiver that gets the message above looks at the From domain, fetches that record, and runs the check. SPF passed, but for the wrong domain. DKIM passed, but for the wrong domain. Neither aligned, so DMARC fails, and p=reject says to refuse it. The finance team never sees the message. The attacker gets a bounce, 550 5.7.1 rejected per DMARC policy, at the envelope address they chose.

Gmail, Microsoft, Yahoo and Apple all check DMARC and honor p=reject. Most corporate mail filters do too. The receivers that don't are small, self-hosted, or old, and they're a shrinking share of anybody's mail. So a policy of reject removes exact-domain spoofing at nearly every inbox that matters.

Most domains aren't at reject yet because of the step before it. Reject applies to your own mail too, so every real sender has to pass first, and the forgotten ones only show up in the reports. What breaks when you set p=reject is the list of things to check before you do.

What DMARC does not cover

Reject handles the first row of the diagram. The other two rows are still open, and vendor pages tend to leave that out.

Lookalike domains are someone else's domain, with someone else's DMARC, and yours has no jurisdiction. The defenses are ordinary: register the obvious variants of your name, watch new registrations that resemble it, and train the people who move money to check the address, not the name. Some mail filters flag a domain that's one edit away from yours, which is the closest thing to a technical defense.

Display-name spoofing is authenticated mail from a free mailbox with a lie in the name field. DMARC passes it, correctly, because the mail really did come from that Gmail account. The defense is a rule in your mail filter that flags external mail whose display name matches an employee, and people who know that a name proves nothing.

Compromised accounts are a different problem. If the attacker has Dana's password, the mail comes from Dana's real mailbox, through your real server, signed with your real key. Every check passes because every check is telling the truth. Two-factor authentication is the answer to that one.

DMARC's job is narrower than the word spoofing, and it does that job completely. Once you're at reject, the message that says it's from your domain and isn't doesn't arrive.

Test it against your own domain

The way to know your policy works is to spoof yourself. From any machine with a mail tool, send a message to your own address with your domain in the From and nothing that would make it pass. With swaks:

Under p=reject the command ends with a 550 and the message never lands. Under p=none it arrives, and the headers show dmarc=fail with the policy noted. Try it before and after the change.

See the attempts in your reports

Once your record has a rua= address, every receiver that checks DMARC sends you a daily count of messages that used your domain, per sending server, with the result. The rows with IPs you don't recognize and a fail on both checks are the spoofing attempts, and after you move to reject, the same rows show what got refused. Most domains are surprised by the number. Our weekly digest reads those reports and lists every server that used your domain and whether it passed, and on a paid plan we email you the day an unfamiliar one first fails. Your first domain is free.

DomainCanary is a DMARC monitoring service that protects your domain from email spoofing without blocking your own mail.