Identity is a stack of clues
How to Verify Who Really Sent an Email
Verify an email sender by separating display name, full address, domain, Reply-To, message context and authentication results, then confirm sensitive requests through an independent channel.
Sender verification fails when one clue is treated as proof. A familiar logo is not proof. A familiar display name is not proof. Even a correctly spelled From address should be combined with message context and authentication signals when the request could cost money, credentials or account access.
Verify the sender from the outside in
- 1
Expand the full sender address
Mail apps often emphasize the display name and hide the underlying address. Reveal the full address before trusting the name.
- 2
Read the domain character by character
Look for swapped letters, added words, unusual subdomains and characters designed to resemble the real brand.
- 3
Check Reply-To when the message is sensitive
A message can display one From address but direct your reply somewhere else. A surprising Reply-To does not automatically prove fraud, but it deserves explanation.
- 4
Ask whether the story fits the relationship
An unexpected invoice, reset request, document share or payment change should be verified even when the sender identity looks plausible.
- 5
Inspect authentication or original headers if needed
Providers may expose SPF, DKIM and DMARC results or the underlying Received headers. These help detect forged origin but are not a universal safety verdict.
- 6
Verify through an independent channel
For high-impact requests, open the organization's app or site yourself, use a known phone number, or contact the person through an existing conversation rather than the suspicious email.
What each verification clue can and cannot prove
| Clue | Useful for | Limitation |
|---|---|---|
| Display name | Recognizing the claimed identity | Easy to copy |
| From address | Checking the claimed mailbox and domain | Can be forged in spoofing |
| Reply-To | Spotting a different response destination | Legitimate services sometimes use different reply systems |
| SPF/DKIM/DMARC | Testing whether the message aligns with domain authentication rules | A malicious message can still authenticate for a lookalike or compromised legitimate domain |
| Message context | Testing whether the request makes sense | Attackers can research real projects, people and brands |
| Independent contact | Confirming the actual request with the real organization or person | Requires you to use a known-good channel, not information supplied by the message |
When not to reply for verification
Replying to a suspicious email asks the same communication path to verify itself. If an attacker controls the sending account, reply mailbox or conversation thread, the answer can simply reinforce the deception.
For money transfers, credential resets, payroll changes, document-signing requests and other high-impact actions, use a separate trusted path. The FTC repeatedly recommends contacting the company through a website or phone number you know is real rather than the contact details supplied in the unexpected message.
A sender is verified when multiple technical and contextual clues agree and the high-stakes request survives an independent check. No single inbox label should carry that burden by itself.
Put this threat in context
Sources and further reading
Need a separate inbox for a short-lived interaction?
Temporary email can reduce exposure of your durable address when future recovery is not important. It is one privacy layer, not a replacement for account security.
Create temporary email