Reviews
Part of Business email compromise: stop payment fraud by phone
Business email compromise evidence: message fields, mailbox signs, and their limits
Business email compromise evidence: which message fields and mailbox settings carry it, what each can honestly tell you, and how to write the finding up.
When a payment request looks wrong, somebody has to actually look at something. This page is about what there is to look at: the parts of a message and the parts of a mailbox that carry evidence, what each one can honestly tell you, and where reading them stops being useful.
Two warnings before the detail. None of this replaces the verification call, and it is not a detection method. It is a way to answer a question after suspicion already exists, and to write a sensible note for whoever handles it next.
What to take away
- The reply address is the field most worth looking at, because it decides where your answer goes.
- Authentication results say the message came from where it claims. They say nothing about whether the request is real.
- The mailbox tells you more than the messagerules, forwarding, delegates and connected applications are where a takeover leaves marks.
The addresses in a message are not one thing
A mail client shows a name and often hides the rest. There are several distinct fields underneath, and they can all differ from each other legitimately, which is precisely why reading them is a judgment rather than a test.
Message address fields compared
Field
- Display name
- Free text label
- From address
- Sender claim
- Reply address
- Where reply goes
- Return path
- Delivery failures
- Received headers
- Delivery path
What it is
- Display name
- Not identity
- From address
- The claim made
- Reply address
- Unrecognized is useful
- Return path
- Auth checked here
- Received headers
- Your systems wrote top
What it can tell you
- Display name
- From address
- Reply address
- Return path
- Received headers
The display name is free text. It is chosen by whoever sent the message and matched to a saved contact by your client, which is why a familiar name can appear above an unfamiliar address. Treat it as a label, never as identity.
The from address is what most people mean by the sender. On its own it is the claim being made.
The reply address is where your reply actually goes, separate from the from address. If they differ, that is not proof of anything: mailing lists, ticketing systems, and shared inboxes do it constantly.
On a message asking about money, a reply address you do not recognize is the single most useful thing to notice. Replying is exactly what someone is about to do.
The return path, or envelope sender, is where delivery failures go, and it is what domain authentication is usually checked against. It frequently differs from the visible from address for legitimate reasons, including any service that sends on a company's behalf.
The received headers record the path the message took, in reverse order, added by each system that handled it. The lines closest to the top are the ones your own systems wrote and are the ones you can trust; the further down you read, the more you are reading the sender's own claims about itself.
Your mail client will have a way to show all of this, usually described as viewing the source, the original, or the internet headers. Find it once, on a message you know is fine, so that you are not learning the interface during an incident.
Authentication results, and what they actually mean
Most platforms stamp a line recording whether the message passed the domain owner's published checks. Three names appear: one for whether the sending server was authorized, one for whether the message carried a valid signature, and one for whether either of those lined up with the visible from address.
A pass means the message really did come from a system the domain owner permits. That is worth having. It is also entirely compatible with the message being fraudulent, because a mailbox that has been taken over is a system the domain owner permits, and it will pass every check cleanly.
A fail is more informative in the other direction, though even then the common cause is a misconfigured legitimate sender rather than anything hostile. The routine handling of that situation belongs with the mail troubleshooting habits in security foundations troubleshooting.
So the practical reading is narrow and useful: authentication results tell you where a message came from, never what it deserves. The National Cyber Security Centre's email security and anti-spoofing guidance explains what each of the three checks is actually asserting, which is worth reading once before relying on any of them.
What to look at in the mailbox
If the question is whether an account has been taken over rather than whether one message is odd, the mailbox is the better place to look. These settings are where control of an account leaves visible traces.
Mailbox takeover checks
- Inbox rules hiding invoice replies
- External forwarding copies
- Delegates and shared access
- Connected applications with standing access
- Registered authentication methods
- Recent sign-ins on finance accounts
- Sent and deleted items
| What to check | Why it matters | What normal looks like |
|---|---|---|
| Inbox rules | Rules that move, mark read, or delete messages about invoices and payments hide the replies from the account's owner | A handful the user recognizes and can explain |
| Forwarding | External forwarding sends a continuing copy of everything without any further access | Usually none, and any that exists should be known and approved |
| Delegates and shared access | Another account granted the ability to read or send | Only assistants and shared mailboxes you set up |
| Connected applications | Standing access that survives a password change | A short list, every entry accounted for |
| Registered authentication methods | An unfamiliar device or number means the account is still reachable after a reset | Exactly the methods the user recognizes |
| Recent sign-ins | Unfamiliar locations, times and clients on finance and administrator accounts | Consistent with where that person works |
| Sent items and deleted items | Shows what went out under this account's name | Nothing the owner cannot account for |
Two habits make this list more useful. Know how far back your audit log is retained. That limit decides whether a November question can be answered about September. Set it deliberately instead of accepting a default, as the United States National Institute of Standards and Technology's guide to computer security log management argues.
And check the same list the day someone leaves, not merely when something looks wrong.
Reading a request rather than a message
The message is only the envelope. What is being asked for is the thing to examine, and it comes down to a short set of questions that do not require any technical inspection at all.
Does this change where money goes? Is it the first payment to this payee? Does it ask for speed, discretion, or an exception to the normal route? Does it arrive at a moment when the person who would normally approve is unreachable? Does the amount sit just under a threshold that would have triggered a second signature?
Any yes means the request goes to voice verification on a number you already held. That rule is the actual control, and it works identically whether the headers look immaculate or not, which is the point of it. The wider process sits in business email compromise.
Writing it down while it is in front of you
If you escalate, escalate with evidence rather than a description. Keep the original message rather than a forwarded copy, since forwarding rewrites the headers you would want. Save the full source to a file. Note the date and time you looked, what you checked, and what you found, including the things that looked normal.
A note that says the reply address differed, no unexpected rules existed, and the last sign-in was from the usual city is worth far more to the next person than a message saying it looked suspicious. It is also the difference between reconstructing a timeline and guessing at one, which is why the same discipline appears in incident response.
Common questions
Can we tell from the headers whether the sender's account was taken over?
Not from the headers alone. A message from a compromised account is genuinely from that account and will look it. What sometimes shows is a reply address elsewhere, or an unusual sending system, but the reliable answer comes from calling the organization on a number you already held and asking.
Should staff be taught to read headers?
No. Teach one habit instead: anything touching payment details or urgency gets verified by voice, and anything odd gets reported with one click. Header reading is for whoever investigates afterwards, and expecting it of everyone reintroduces exactly the judgment call the process exists to remove.
Is a lookalike domain always hostile?
No, and that trap is common. Companies own several spellings, regional variants and old trading names. Check your own list before treating a variant as an attack, and keep that list somewhere the finance team can see it.
What should we require of tooling to make any of this easier?
Legible alerts on new rules, forwarding and delegates, a readable sign-in log with stated retention, and the ability to retrieve a message with headers intact. The requirements are set out in best business email compromise software 2027.
