What Is Email Spoofing? How It Works and How to Stop It

Introduction

A customer forwards you an invoice "from your accounts team". You never sent it. The From line shows your real domain, your logo is in the signature, and the bank details belong to someone else.

That is email spoofing: forging the sender of a message so it looks like it came from someone it did not. It is the delivery mechanism behind most phishing, invoice fraud and CEO fraud.

This guide explains how spoofing works, how to recognise a spoofed email, and what actually stops attackers from using your domain.

What Is Email Spoofing?

Email spoofing is sending a message with a forged sender identity. The forged part is usually the From address, the one people see in their mail client.

It works because the core email protocol, SMTP, was designed without sender verification. A sending server can put any address in the From header, and nothing in SMTP itself checks it.

A spoofed message can claim to come from:

• Your own domain, sent to your customers or your staff
• A bank, a supplier or a delivery company your recipient trusts
• A colleague, usually someone senior who can ask for a payment

Spoofing is not the same as hacking an account. In a spoofing attack, the attacker never logs into the real mailbox. They only make the message look like it did.

How Spoofing Works: Two "From" Addresses

Every email has two sender addresses, and attackers exploit the gap between them.

Address	Where it lives	Who sees it
Envelope sender (MAIL FROM, Return-Path)	SMTP conversation	Servers only; bounces go here
Header From	Message headers	The recipient, in their mail client

A typical spoofed message looks like this in the raw headers:

Return-Path: <bounce-7731@mailer.example.net>
From: "Example Accounts" <accounts@example.com>
Reply-To: payments@example-billing.net
Subject: Updated bank details for invoice 4471

The recipient sees accounts@example.com. The bounce address belongs to the attacker's server, and the Reply-To sends any answer to a third domain they control.

The Main Types of Spoofing

Exact-domain spoofing. The From address uses your real domain: ceo@example.com. This is the type that SPF, DKIM and DMARC are designed to stop.

Display name spoofing. The address is a free mailbox or a random domain, but the display name says what the attacker wants: "Example CEO" <ceo.example@gmail.com>. Many mobile clients show only the name, so it works well.

Lookalike domains. The attacker registers a domain that looks like yours: examp1e.com, example-invoices.com or exarnple.com. The domain is real and can pass authentication, because the attacker owns it.

Reply-To hijacking. The From address may even be legitimate or unrelated; the trick is a Reply-To that routes the conversation to the attacker.

How to Spot a Spoofed Email

Content clues help: urgency, changed bank details, a request to keep something confidential. But the reliable evidence is in the headers.

Open the raw message ("Show original" in Gmail, "View message source" in Outlook) and look for the Authentication-Results header:

Authentication-Results: mx.example.org;
  spf=fail (sender IP is 198.51.100.23) smtp.mailfrom=example.com;
  dkim=none;
  dmarc=fail action=none header.from=example.com

This message says it is from example.com, but:

• SPF failed: the sending IP is not authorised by example.com
• DKIM is missing: there is no signature from example.com
• DMARC failed, and action=none because the domain only publishes p=none, so the receiver delivered it anyway

Other signals worth checking:

• The Return-Path domain has nothing to do with the From domain
• The Reply-To points to a different domain
• The first Received header shows a server or country you do not use

You can paste the full headers into the Email Header Analyzer to see the SPF, DKIM and DMARC results and the delivery path without reading them line by line.

How to Stop People Spoofing Your Domain

You cannot stop someone from typing your address into a From field. You can make sure receiving servers recognise the message as forged and refuse to deliver it. That takes three DNS records working together.

1. SPF: Authorise Your Sending Servers

SPF lists the servers allowed to send mail for your domain:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

On its own, SPF is weak protection against spoofing: it checks the envelope sender (Return-Path), not the From address people see. An attacker can pass SPF with their own domain in the Return-Path and still show yours in From.

The syntax and every mechanism are covered in SPF Record Syntax Explained.

2. DKIM: Sign Your Messages

DKIM adds a cryptographic signature to each message, verified with a public key in your DNS. An attacker without your private key cannot produce a valid signature for d=example.com.

See What Is a DKIM Record? for the record format and how to check it.

3. DMARC: Tie Everything to the From Address

DMARC is the piece that closes the gap. It requires that SPF or DKIM pass and align with the domain in the visible From address, and it tells receivers what to do when they do not:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

With p=reject, a message that claims to be from example.com but fails both aligned SPF and aligned DKIM is refused. That is what stops exact-domain spoofing.

Do not jump straight to p=reject. Start with p=none, use the aggregate reports to find every legitimate sender, fix them, and then move up. The step-by-step plan from p=none to p=reject explains what to check before each step, and DMARC Record Examples has ready-to-adapt records.

4. Protect Domains That Never Send Email

Attackers like parked and unused domains, because nobody watches them. If a domain never sends email, publish records that say so:

example.net.          TXT  "v=spf1 -all"
_dmarc.example.net.   TXT  "v=DMARC1; p=reject;"
example.net.          MX   0 .

The last line is a null MX (RFC 7505): it says the domain does not accept mail either.

For subdomains that do not exist in DNS, RFC 9989 adds the np tag. np=reject in your main DMARC record covers names like billing.example.com that an attacker might invent.

5. Read Your DMARC Reports

Aggregate reports show every IP address that sent mail using your domain, and whether it passed. That is how you find spoofing campaigns against your domain, and also how you find legitimate senders you forgot about before you enforce.

How to read DMARC reports walks through the XML.

What DMARC Does Not Stop

DMARC is the right tool for exact-domain spoofing, but it is not a complete anti-phishing system. It does not cover:

• Lookalike domains. examp1e.com has its own DNS and can pass its own DMARC. Register the obvious variations of your domain and watch for new ones.
• Display name spoofing. The address is not yours, so your DMARC record is not consulted. Recipient-side filters and "external sender" banners help here.
• Compromised accounts. Mail sent from a real mailbox passes authentication. Multi-factor authentication and login monitoring are the defence.

Train the people who handle payments to confirm any change of bank details by phone, using a number they already have, not one in the email.

"Someone Is Spoofing My Email": What to Do

If you are receiving bounces for messages you never sent, or customers report emails from your domain you did not write:

1. Rule out a compromised account. Check sign-in logs and enable MFA. If the mail appears in a real Sent folder, it is not spoofing.
2. Check your current records. Run the Domain Score or the DMARC Checker to see what you publish today.
3. Publish DMARC if you have none, at p=none with a rua address, so you start collecting data.
4. Identify your legitimate senders in the reports and make sure each one passes SPF or DKIM with alignment.
5. Move to p=quarantine, then p=reject. From that point, receivers that honour DMARC refuse the forged mail.

The bounces may take a few days to stop: spammers keep sending until they notice the mail no longer arrives.

Checklist

• SPF lists every service that sends as your domain
• Every service signs with DKIM using your domain (d=example.com)
• DMARC is published with a rua address and you read the reports
• DMARC policy is at p=quarantine or p=reject, with np=reject
• Non-sending domains publish v=spf1 -all and p=reject
• Staff verify payment changes outside email

Next Steps

1. See what your domain publishes today: Domain Score →
2. Create a DMARC record: DMARC Generator →
3. Inspect a suspicious email: Email Header Analyzer →
4. Find out who sends as your domain: Start free → — DMARC Examiner turns aggregate reports into a list of sending sources, so you can tell your own services from spoofing before you enforce.

---

Related Articles:

• What Is DMARC? A Simple Guide
• SPF, DKIM, and DMARC: The Complete Guide
• DMARC Policy Explained: None vs Quarantine vs Reject