Email spoofing: why anyone can send as your domain

Anyone with a rented server can send an email carrying your address in the From line, and the protocol that moves email will do nothing to stop them. No password gets stolen, no account gets broken into: the attacker types your address into a text conversation and the receiving server carries the message. That act is called spoofing, and this lesson is about taking it personally, because the entire next part of the course exists as the world's answer to it.

The protocol takes your word for it

Go back to the SMTP conversation from lesson one and reread it with suspicious eyes. It contains two identity statements: the MAIL FROM:<bounce@yourdomain.com> line of the envelope, and the From: header that follows DATA. Both are lines of text the sending machine typed. The receiving server checks neither against anything. In anatomy of an email you learned that the visible From is letterhead; now add the harder half of that truth. The envelope address is letterhead too. Every From line you have ever read, on every email you have ever received, was a claim.

This was not an oversight someone should have caught in review. SMTP was written down in 1982 (RFC 821), when the machines exchanging mail belonged to universities and research labs that largely knew one another. In that world, verifying who a message came from was not a hard problem left unsolved. It was not a problem at all. The protocol assumed good faith because, on that network, good faith held. Then email became the whole world's messaging system and brought the assumption along.

More than forty years later, that 1982 decision is still the ground everything in this course stands on.

What borrowing a name looks like

Spoofing is sending mail under a forged sender identity, and the clean version is exact-domain spoofing: your real domain, in the From line, on mail you never sent. At the protocol level, the forgery and your legitimate newsletter are indistinguishable. The receiver gets a claim in both cases.

Around the clean version sit two cheaper relatives, and it's worth telling them apart because they need different defenses. A lookalike domain is one the attacker actually registers: yourcompany-billing.com, or your name with two letters swapped so the eye slides past. Mail from it is, technically, honestly sent; the deception is in the reader's glance, and nothing your domain publishes can reach a domain someone else owns. Display-name spoofing is lazier still: a trusted person's name as the display text over an unrelated address. It works because many mail clients, phones especially, show the name and hide the address. (Open your own phone's mail app and check how much of a sender's address you actually see.)

Phishing is the con built on the borrowed identity. The forged sender is the costume; the payload is a request the reader would refuse from a stranger. A password reset that isn't one. An invoice with new bank details. And the quiet workhorse of the genre: a message whose From shows a real colleague while Reply-To, the redirect header you met in the anatomy lesson, points at a mailbox the attacker controls. The reader hits reply, the conversation leaves the company, and the From line goes on looking respectable in every message of the thread.

The fix could only be bolted on

Put yourself in the receiving server's position, mid-conversation, holding a message that claims to come from yourdomain.com. It has no way of knowing whether the connecting machine is entitled to that name. No receiver does. The only party on earth who knows which servers are supposed to send for a domain is the domain's owner. So the fix, when it finally came, had one possible shape: the owner publishes proof in a place only the owner controls, and receivers fetch that proof during delivery and compare it with what's in front of them. You already know the place. It's DNS, the public address book from lesson three, the one notice board where the ability to write is itself evidence of ownership.

Notice what did not happen: SMTP itself was never changed. The proof systems are additions layered on top, optional by design, adopted domain by domain over decades. That optionality reshaped the receiving side. Once proof became possible, its absence became a signal, and modern receivers treat unauthenticated mail with growing suspicion; the largest mailbox providers now require authentication outright from bulk senders, a story a later lesson tells properly. The burden of proof flipped onto the sender, where it has stayed.

The domain that sends nothing

A From line is text, and any domain fits in it. Which means "we don't even send email from that domain" is not a defense. It's close to an invitation: a domain that publishes no policy gives receivers nothing to contradict the forgery, so the spoofed mail sails exactly as far as the receiver's general suspicion allows. Parked domains, website-only domains, the old brand you keep renewing out of caution: all of them can be borrowed, and the borrowing is silent. No bounce reaches you, no alert fires. The owner typically finds out last, from a confused customer or a partner holding a fake invoice.

This is why our free health check runs on a domain, not on an email account, and asks for no proof that you send anything. Spoofing protection is the one deliverability job I hand to people who never send a single newsletter: if you own a domain, this part of the course already applies to you, subscriber list or not.

The proof systems have names, and you'll spend the next part of the course inside them. SPF is a published list of the servers allowed to send for a domain. DKIM is a signature that rides inside the message. DMARC is the policy that ties both back to the From your reader actually sees. How each one works, and how each one quietly breaks, starts with SPF.

Terms from this lesson

• spoofing - sending email under a forged sender identity, exploiting the fact that SMTP verifies neither the envelope sender nor the visible From.
• exact-domain spoofing - putting a domain's real name in the From line of mail its owner never sent; the forgery domain-based proof can actually stop.
• lookalike domain - a domain registered to be misread as another (an extra word, swapped letters); outside the real domain's control, so its proof can't touch it.
• display-name spoofing - a trusted person's name as the From display text over an unrelated address, effective wherever clients hide the address.
• phishing - the con built on a borrowed identity: mail impersonating someone the recipient trusts in order to extract a password, a payment, or a click on something hostile.
• email authentication - the bolt-on proof systems, published in DNS by the domain owner and checked by receivers, that make a sender identity verifiable.

Check yourself

1. An attacker sends mail showing billing@yourcompany.com in the From line. What did they need to pull it off?

Your email password, or access to one of your company's accountsA server of their own and the will to type your address into the conversationEdit access to your domain's DNS recordsAn unpatched vulnerability in your mail provider

2. Why did SMTP ship without sender verification?

It was designed in 1982 for a small network of institutions that trusted each other, so forgery wasn't yet a problemVerification was included at first but removed because it made delivery too slowThe designers left identity checking to spam filters, which verify the From address is realCryptography wasn't invented yet, so verification was impossible

3. Your company owns a domain used only for a website: no mailboxes, no newsletters, nothing sent. Can it be spoofed?

No, spoofing requires the domain to have a working mail serverNo, receivers automatically reject mail from domains that have no mailboxesYes, and publishing no policy makes it an easier target, since nothing contradicts the forgeryOnly if the website itself gets hacked first

4. An accountant receives an urgent request to pay a supplier, carrying these headers. What should stand out? From: "Marta Ziedina, CFO" <marta@yourcompany.com> Reply-To: <m.ziedina-cfo@secure-mail-reply.com>

Nothing; Reply-To routinely differs from From, so this is a normal messageThe From address must be fake, because executives don't email accountants directlyReplies will go to an outside mailbox the CFO doesn't control, the standard shape of an impersonationThe message is safe, because the From shows the company's real domain