On this page
What is a spoofed email?
A spoofed email is an ordinary, well formed message whose visible sender has simply been made up. Nothing was broken into, no password was stolen and no server was compromised. The attacker typed a different value into a field that nobody ever forced to be truthful.
The reason goes back to the design of SMTP. A mail transaction carries two separate sender addresses, and they live in different layers. The envelope sender is announced during the SMTP conversation with the MAIL FROM command defined in RFC 5321. The header From is part of the message content that follows, and it is the one your mail client shows in the inbox list.
Nothing in the protocol ties the two together, and from the sending side the forgery looks like this:
MAIL FROM:<bounces@sender.example.net> RCPT TO:<you@example.com> DATA From: "Finance Team" <accounts@example.com> Subject: Updated payment details
The message is delivered, the inbox shows Finance Team, and the recipient has no reason to look twice. Everything that exposes it sits above the message body.
Why spoofing email is so easy
Base SMTP has no concept of proving who you are. Any machine that can open a connection to a mail exchanger can offer any From address it likes, and the receiving server accepts the message as mail rather than as a claim about identity.
The second reason is that the whole visible part of a message belongs to whoever wrote it. Logos, the signature block, the legal footer, the sent from my phone line, even a genuine thread quoted underneath: all of it is content, and content is free to invent.
SPF, DKIM and DMARC came later and sit on top of SMTP rather than inside it. They work, but they are checks the receiving server runs and then records in a header. That is why catching a fake sender email means reading headers rather than reading prose.
How to check email headers for spoofing
Every mail server that handles a message stamps its own lines onto the top of the header block, and it writes them once the sender is already out of the loop. Those lines are the part of the email the attacker does not get to author.
Start by opening the raw source: Show original in Gmail, View message source in Outlook, View then Message then Raw Source in Apple Mail. Copy the whole block and paste it into the email header analyzer instead of scrolling through it by eye. It pulls out the From, To, Subject, Date, Message-ID, Return-Path and Reply-To fields, rebuilds the Received chain with the oldest hop first and an IP address, hostname and timestamp for each, reads the SPF, DKIM and DMARC verdicts from the Authentication-Results header, and lists the problems it found, such as a From domain that does not match the Return-Path domain.
Which header fields reveal a fake sender email
Six fields carry most of the signal, and they are worth reading together, because any one of them can look odd for an innocent reason.
| Header field | What it normally shows | What a forgery looks like |
|---|---|---|
| From | The sender you expect | A domain that appears nowhere else in the message |
| Return-Path | The same domain as From | A different domain, raised as a mismatch warning |
| Received, lowest | A host belonging to the sender's provider | A residential address, a bulk host or an unrelated country |
| Authentication-Results | spf, dkim and dmarc all pass | A fail, or no verdict recorded at all |
| Reply-To | Absent, or the same domain as From | A mailbox that quietly catches your answer |
| Message-ID | A domain matching the sending platform | A random or missing value |
The chain reads from the bottom up: the last Received header in the file is the first server that touched the message, and that origin is the one to compare against the From domain.
What the SPF, DKIM and DMARC verdicts mean
The analyzer reports each of the three as pass, fail or not found, exactly as the receiving server recorded it, and they do not mean the same thing.
An SPF pass says the IP address that delivered the message was listed in the DNS record of the envelope sender domain. That is a statement about the Return-Path, so an attacker whose own domain has a valid SPF record earns a pass while still forging your name in the From line.
A DKIM pass says a signature on the message verified against a public key published by the signing domain, which also proves the signed parts were not altered in transit. The mechanism is defined in RFC 6376.
A DMARC pass is the one that matters here, because DMARC adds alignment: a passing SPF or DKIM result has to belong to the same domain the reader sees in the From line.
Not found is not a pass. It means the server recorded no verdict for that method, and the tool treats it that way: the overall status only comes back clean when all three pass and no warnings were raised.
How display name tricks hide the real address
Often the forged part is not the address at all. Mail clients show the display name first, and on a phone they frequently show nothing else, so a message from a throwaway mailbox with the display name set to your finance director reads as the finance director.
An attacker can also put a whole address inside the display name, so the client renders what looks like a real address beside an address that is not. And a message can carry a truthful From with a Reply-To pointing elsewhere, so the original passes every check while your answer goes to the attacker.
Is someone spoofing my email address?
The usual first symptom of someone spoofing my email address is a flood of bounce messages for mail I never sent. Bounces go to the envelope sender, so if a campaign put your address in the Return-Path, every undeliverable copy comes home to you.
The other symptom is angry replies with no bounces attached. That pattern usually means only the header From was forged while the Return-Path pointed elsewhere, so the delivery failures went to the attacker and only the human responses reached you.
Neither symptom means your mailbox was broken into. A compromised account looks different: real messages in the Sent folder, sign in records from places you have never been, and mail rules you did not create. Check those first, because a compromised mailbox is a different incident with a different fix.
See what your domain tells receiversRead your published policy, alignment and reporting addressesHow to stop spoofing email addresses on your domain
You cannot stop anyone from typing your domain into a From line. What you can do is publish the DNS records that let every receiving server recognise the forgery and discard it, and the order matters, because each step depends on the one before it.
-
Publish an SPF record
List every service that sends mail for you, then close the record with an all mechanism so unlisted servers are refused rather than merely unmentioned.
-
Sign outgoing mail with DKIM
Each sending service publishes a public key under its own selector and signs what it sends. A DKIM signature survives forwarding, where SPF usually does not.
-
Start DMARC at monitoring only
Nothing is blocked yet. Aggregate reports tell you which sources send as your domain and which of them already pass alignment.
-
Move to quarantine, then reject
Once the reports show only your own services passing, raise the policy. Reject is the setting that actually stops a forged message at the door.
Verify each record before moving to the next one. The SPF checker parses every mechanism with its qualifier and counts DNS lookups against the limit of ten, which is the usual way a working record quietly breaks as a company adds sending services. The DKIM checker looks up the key for a selector you name, or tries common selectors on auto detect, and reports the key type and length. The DMARC checker reads the policy, the alignment modes and the reporting addresses, and warns you while the policy is still set to monitoring.
Can DMARC stop every spoofed email?
No, and knowing where the boundary sits is the difference between real protection and a comfortable illusion of it.
Lookalike domains fall outside it entirely. A policy on your domain says nothing about a domain that merely resembles yours, with a hyphen added, a letter swapped or a different ending. That domain can publish its own flawless records and pass every check, because authentication proves a message came from the domain it claims, not that the domain deserves trust.
Compromised mailboxes fall outside it too. When an attacker signs into a real account and sends from it, the mail is genuine by every technical measure: signed, aligned and authorised, because it is.
Two smaller gaps are worth closing. Publish a rejecting policy on domains that never send mail at all, including parked ones, because those are exactly what attackers look for. And expect forwarding to break SPF, since the forwarding server is not on your list, which is the case DKIM survives and the reason signing matters even when SPF is already in place.
Stop guessing whether that message is real
Paste the raw headers and read the Received chain, the Return-Path and the SPF, DKIM and DMARC verdicts in one structured view.
Frequently asked questions
Sometimes, but never reliably. Tapping the display name to reveal the full address catches the crudest attempts, and an unexpected request for payment or credentials is always worth suspicion. Anything beyond that guesswork needs the headers, because the body of a message is entirely under the sender's control.
No. SPF checks the connecting server against the envelope sender domain in the Return-Path, not against the From address you see. An attacker sending from a domain they own can pass SPF while displaying your name. Only a DMARC pass ties a successful check to the visible From domain.
Because somebody used your address as the envelope sender in a bulk campaign, so every undeliverable copy bounces back to you. It is called backscatter and it does not mean your account was accessed. Check your Sent folder and sign in history to rule out a real compromise.
Not your exact domain at receivers that honour the policy. They can register a similar looking domain, authenticate it properly and impersonate your brand that way, or set your name as the display name on a free mail account. A reject policy closes one door, not all of them.
No. A reply goes to the Reply-To address, which the attacker may have set to their own mailbox, and it confirms that your address is live. Contact the person through a channel you already trust, and forward the full headers to your security or IT team.