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

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. Sending mail with someone else's address in that line is email spoofing.

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

Setup steps

1. Publish an SPF record listing every service that sends as your domain. SPF record syntax shows the format.
2. Turn on DKIM in each of those services and set it to sign with your domain. The guide to how SPF, DKIM and DMARC fit together covers the signing domain.
3. Publish a DMARC record at p=none with a reporting address, and read the reports until every real sender passes. DMARC setup covers this step in detail.
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 sent

To deliver a message, a mail server connects to the receiving server and sends a short series of commands. It says who the message is from and who it's to, then sends the message itself, headers and all. The whole exchange for a spoofed message looks like this:

The message has two from addresses. The one after MAIL FROM is the envelope sender. Bounces go there, 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.

Anyone can do this with a mail-sending tool or a short script in any programming language. It needs no exploit, because the protocol has worked this way since 1982.

What the recipient sees

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. A reply goes to the Reply-To address if there is one, and the attacker wrote that too. Everything on the screen came from lines the attacker wrote.

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 each check returned. In every client they're behind a menu, and almost nobody opens it.

Kinds of spoofing

People use the word spoofing for different tricks, and each one has its own defense.

• 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. Your DMARC record doesn't apply, 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 without DMARC

SPF alone doesn't stop a forged From address, and that surprises many people who've set it up. 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 lists their server. SPF passes. SPF never looks at the From header, so the forgery goes unchecked.

A DKIM signature shows 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. Nothing has compared that domain with the From address the reader sees.

DMARC adds that comparison. To pass DMARC, SPF or DKIM has to pass for a domain that matches the From header, and that match is called alignment. The attacker can make SPF and DKIM pass for their own domain. They can't make either pass for yours, because they don't control your DNS.

DMARC at p=reject

With p=reject, receivers that check DMARC refuse mail that forges your exact domain. The record is a TXT record at _dmarc.yourcompany.example:

A receiver that gets the message above looks at the From domain, fetches that record, and runs the check. SPF and DKIM both passed for attacker.example, which doesn't match the From domain. Neither aligned, so DMARC fails, and because you set p=reject, the receiver refuses the message. 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 once you're at reject, almost all the forged mail that uses your exact domain is refused.

Most domains aren't at reject yet, because of the step before it. The policy applies to your own mail too, so every real sender has to pass first, and you'll only find the forgotten ones in the reports. What breaks when you set p=reject lists what to check before you move.

Lookalikes, display names and stolen accounts

A policy of reject stops the first kind of spoofing in the diagram above. The other two kinds, and stolen accounts, need different defenses.

Lookalike domains belong to someone else and have their own DMARC records, so yours doesn't apply. Defend against them by registering the obvious variants of your name, watching new registrations that resemble it, and training the people who move money to check the address rather than 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. It passes DMARC, correctly, because the mail really did come from that Gmail account. Defend against it with a mail filter rule that flags external mail whose display name matches an employee, and by teaching people 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 the mail really did come from Dana's account. The defense against this one is two-factor authentication.

A spoofing test on your own domain

To check that your policy works, spoof yourself. From any machine with a mail tool such as swaks, send a message to your own address with your domain in the From and nothing that would make it pass:

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.

Aggregate reports

Once your record has a rua= address, most large receivers that check DMARC send you a daily count of messages that used your domain, per sending server, with the result. The servers you don't recognize, failing both checks, are the spoofing attempts. After you move to reject, the same entries show what got refused. Most domain owners are surprised by the number. We read those reports for you, and our weekly digest lists every server that used your domain and whether it passed. On a paid plan, we email you the day an unfamiliar one first fails. Your first domain is free.