What if the email address was spoofed?¶
title: What if the email address was spoofed? subtitle: A message can display a familiar address or name without having been sent through the genuine account. slug: what-if-the-email-address-was-spoofed series: email-evidence section: sender-and-account-attribution card_type: question_card pathway_order: 11 section_order: 5 status: draft public_safe: true video_ready: true word_count: 539 estimated_read_time_seconds: 223 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - spoofing - display name - SPF - DKIM - DMARC sources: - title: 'RFC 5322: Internet Message Format' url: https://www.rfc-editor.org/info/rfc5322/ - title: 'RFC 6376: DomainKeys Identified Mail (DKIM) Signatures' url: https://www.rfc-editor.org/info/rfc6376/ - title: 'RFC 7208: Sender Policy Framework (SPF)' url: https://www.rfc-editor.org/info/rfc7208/ - title: 'RFC 8601: Message Header Field for Indicating Message Authentication Status' url: https://www.rfc-editor.org/info/rfc8601/ - title: 'RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)' url: https://www.rfc-editor.org/info/rfc9989/
What if the email address was spoofed?¶
A message can display a familiar address or name without having been sent through the genuine account.
Script¶
Email spoofing means that the identity shown to the recipient doesn’t reliably identify the account or system that actually sent the message.
There are several forms.
The simplest is display-name spoofing.
The email client shows a familiar name such as “Managing Director” or “HMRC”, while the underlying address belongs to a completely different domain.
Another version uses a lookalike address.
The domain may contain an extra letter, a substituted character, a misleading subdomain or a different ending that is easy to miss.
A sender may also place the exact genuine-looking address in the From field even though the message was submitted through unrelated infrastructure.
The visible From field is message content. It can be asserted by the sender.
That is why you need the complete original header.
Start by expanding the displayed identity and recording the full address.
Compare the domain carefully.
Then review the trusted Received chain to establish which mail system handed the message into the recipient’s environment.
Compare From with Reply-To and Return-Path. A Reply-To pointing somewhere unexpected may show where the sender wanted the conversation to continue. A platform-controlled Return-Path may reveal the sending service.
Review SPF, DKIM and DMARC results, but keep each result within its limits.
SPF checks whether the connecting server was authorised for the envelope-sender domain.
DKIM checks a domain-controlled signature over selected message content.
DMARC checks whether authenticated identifiers align with the domain presented in From.
A DMARC pass can support that the message followed an authorised, aligned domain route.
It still doesn’t prove which individual sent it.
A failure may support spoofing or misconfiguration, but it isn’t automatically proof of a malicious message. Forwarding, mailing lists and poor domain configuration can affect authentication.
Trust authentication results only when they were added by the receiving system or another trusted part of the delivery chain. A sender can insert fake-looking header fields before the message reaches that boundary.
Also distinguish spoofing from account compromise.
With spoofing, the attacker may only be pretending to use the address.
With compromise, the real account or authorised service may have sent the message under an intruder’s control.
The technical and investigative routes are different.
Where the message appears to come from an organisation, ask whether the organisation recognises it.
Was the message generated by a real employee, marketing platform, ticketing system or supplier?
Does the organisation’s provider have a matching sent event?
Was the domain configured to authorise the sending service?
Did other recipients receive the same campaign?
The common mistake is to decide that the address is genuine because it looks exact on screen.
The other is to call every mismatch spoofing.
Legitimate services often use different delivery, bounce and reply addresses. The question is whether the arrangement is authorised and consistent with the organisation’s systems.
A careful conclusion might be:
“The message displayed the organisation’s address in From, but the trusted delivery and authentication records don’t support an authorised sending route.”
That explains the evidence.
“The suspect spoofed the address” adds a person and intention that may require more investigation.
Spoofing is about the identity presented by the message.
Preserve the original, find the trusted delivery boundary, test the domain authentication and then look for the service or account that actually generated it.
Key takeaway
Spoofing changes the identity shown to the recipient. Test the delivery route and domain authentication rather than trusting the display.
Related questions¶
- Does the From address identify the sender?
- What is the difference between From, Reply-To and Return-Path?
- What if the sender’s account was compromised?
- How do I preserve an email properly?
Source notes¶
- RFC 5322: Internet Message Format
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7208: Sender Policy Framework (SPF)
- RFC 8601: Message Header Field for Indicating Message Authentication Status
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)