Does the From address identify the sender?¶
The From address identifies the author identity presented in the message. It may be accurate, spoofed, used by a shared or automated system, or belong to a genuine account that somebody else has accessed. It is useful evidence of what the recipient was shown, but it does not by itself identify the account, device or person behind the message.
Start with the message the recipient saw¶
In the supplier-payment investigation, the email appears to come from a familiar supplier contact:
accounts@ridgeway-componants.exampleridgeway.payments@postbox.exampleridgeway-components.exampleThe display name is familiar, but the underlying address contains componants rather than components. A reply would go to a separate free-mail address. These differences do not name the offender, but they expose useful lines of enquiry that the display name was doing its best to keep quiet.
The message presented this name and address as its author identity. That helps explain what the recipient saw, why the message appeared familiar and which claimed organisation or domain should be checked.
The field does not by itself prove which mailbox, service, device or person created or submitted the message. Those links require evidence from the delivery route, authentication results, provider records and wider investigation.
The name and address are separate parts¶
Many email applications display a friendly name more prominently than the address underneath it. The name may be a real person, a role such as “Accounts”, a business name or anything the sending system has been told to display.
Martin Cole - Ridgeway ComponentsPresentation intended for the reader. It is normally easy to copy and may hide the address until expanded.
accounts@ridgeway-componants.exampleThe address placed in the message's From field. It still needs to be tested against the route and provider evidence.
A convincing display name can therefore sit beside an unrelated or subtly altered address. Preserve both. A report that records only “Martin Cole” loses the very difference that may explain how the message worked.
From, Reply-To and Return-Path answer different questions¶
These fields may match, but they do not have to. Each performs a different job:
Different values are not automatically suspicious. A business may use a ticketing system, mailing platform or specialist service while presenting its normal brand address. The difference matters because it helps identify the actual arrangement that needs checking.
See the fields side by side
Several legitimate and hostile arrangements can produce the same display¶
A business may authorise Microsoft 365, Google Workspace, a CRM, mailing platform or ticketing system to send using its domain.
Several staff may use one address, or one user may Send As or Send on Behalf of another mailbox.
The message may come through the real account and pass normal checks even though the account holder did not send it.
A sender may copy the display name, forge the visible address or use a similar-looking domain under their control.
This is why “the address is genuine” and “the named person wrote it” are separate propositions. Even a message sent through the genuine organisation may have been generated automatically, sent by a delegate or caused by an intruder using a compromised account.
Authentication tests the domain arrangement - not the human author¶
SPF, DKIM and DMARC can help test whether the message followed an authorised or aligned route for a domain. They should be read alongside the exact domains each test assessed.
A pass may support that the message used infrastructure authorised for the From domain. It does not establish which user account triggered the message or who composed the words. A sender using a lookalike domain they control can also configure that domain perfectly well.
In EML-046, the message passes the authentication checks for ridgeway-componants.example. That strengthens the conclusion that the message used an authorised route for the lookalike domain. It does not turn componants into the genuine supplier's components domain.
- test whether a domain authorised the sending route;
- check whether signed content remained intact;
- identify crude direct spoofing; and
- identify domains and infrastructure for further enquiry.
- which account user caused the message;
- which device was used;
- who wrote or approved the content; or
- whether the message was honest or safe.
Build the line of enquiry beyond From¶
- Preserve the original
Retain the native message and complete header because a screenshot may show the display name while hiding the underlying fields and route.
- Record exactly what was presented
Capture the display name and complete From address because they are separate observations and may explain the recipient's decision.
- Compare the identities
Check From, Reply-To, Return-Path and the genuine organisation's known domain because differences can reveal the sending arrangement.
- Read the trusted route
Use the Received chain and authentication results added by systems you trust because sender-supplied fields can be invented.
- Identify the sending service
Use message identifiers, times and infrastructure to frame provider enquiries because the provider may link the message to a tenant, account or submission event.
- Test the person link
Use account, session, device, communications and contextual evidence because the From field cannot select the person responsible.
Use precise language in the investigation¶
“The message displayed this address in the From field” records an observation.
“The message was submitted through this provider account” needs provider or platform evidence.
“This person wrote and sent the message” needs evidence linking the relevant account, session or device to that person and testing realistic alternatives.
That language does not weaken the case. It shows exactly which part has been established and points directly to the next line of enquiry.
The point to remember¶
Continue from here
See it used in an investigation
Go deeper