Email spoofing: what it is and how to stop it

Email spoofing is forging the sender address in an email. The recipient sees a familiar address in the From field — a bank, a colleague, a known service — while the actual sender is an attacker. It is one of the oldest techniques in phishing and spam, and it still works.

Why spoofing is possible at all

SMTP, designed in 1982, includes no sender authentication. The MAIL FROM command accepts any address. A sending server can set whatever it likes in that field, and the receiving server will process it without question unless additional checks are in place.

It is much like a paper letter: you can write any return address on the envelope and the post office will deliver it. SMTP works the same way, which is why SPF, DKIM, and DMARC had to be built as separate layers on top.

Two sender addresses

Every email carries two sender addresses. The first is the Envelope From (MAIL FROM), used at the SMTP transport layer and never shown to the recipient. The second is the Header From (the From: field in the message headers), which the recipient sees in their mail client.

Spoofing almost always targets the Header From, because that is what the person reads. The Envelope From can contain an entirely different address. Without DMARC alignment, nothing checks whether the two match.

Types of spoofing

• Display name spoofing. Only the visible sender name is forged — for example, "Bank of America" appearing above a random@attackerdomain.com address. Many mobile clients show only the display name, hiding the actual address entirely.
• Domain spoofing. The domain in the Header From is forged to make the message appear to come from the legitimate domain. This works only when the victim domain has no DMARC reject policy in place.
• Lookalike domain. The attacker registers a domain that resembles the real one: sber-bank.ru, paypa1.com. Technically this is not spoofing since the attacker owns that domain, but recipients cannot tell the difference.

Protection: SPF

SPF (Sender Policy Framework) publishes a DNS record listing the IP addresses authorized to send mail for a domain. The receiving server checks whether the sending IP appears in that list.

The limitation: SPF checks the Envelope From, not the Header From. An attacker can pass SPF using their own domain in the Envelope From while placing your domain in the Header From. The check passes, but the recipient sees your address.

Protection: DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message headers. The receiving server verifies it against a public key published in the sender's DNS. A missing or invalid signature marks the message as unauthenticated.

DKIM proves the message was not altered in transit and was signed by whoever holds the private key. On its own, though, it says nothing about what a receiving server should do with unsigned mail.

Protection: DMARC

DMARC ties SPF and DKIM together and adds an enforcement policy. It requires that the domain in the Header From aligns with the domain that passed SPF or DKIM. Without alignment, a pass on either check provides no protection. DMARC then tells the receiving server what to do on failure:

• p=none — collect reports, take no action.
• p=quarantine — route to spam.
• p=reject — drop the message entirely.

Only p=reject actually blocks domain spoofing. As of 2025, fewer than 30% of domains publish a DMARC record with p=reject.

What spoofing does to your domain

When attackers spoof your domain, spam complaints land against your sender reputation. Recipients flag the forged messages, and mailbox providers lower trust scores for your domain, which means your legitimate campaigns start failing inbox placement.

Beyond the reputation damage, phishing sent under your name erodes trust with customers and partners. Recovering domain reputation typically takes weeks; recovering partner trust can take longer.