A familiar sender name does not tell the whole story

AI summary

Email display names and visual formatting can be easily fabricated, so they should not be used to confirm the legitimacy of an email. Technical headers provide more reliable metadata, including the Received chain and authentication results (SPF, DKIM, DMARC). However, even passing authentication results do not guarantee a message is safe, as attackers can compromise legitimate accounts or use properly configured lookalike domains. Therefore, technical analysis serves as context for a decision rather than definitive proof of a sender's identity.

Display names, signatures, and logos are easily mimicked and are not reliable indicators of a message's legitimacy.
Authentication results like SPF, DKIM, and DMARC are useful for checking alignment, but do not inherently prove a message is safe or honest.
Users should always verify sensitive requests, such as payment changes, using established, pre-existing contact information rather than relying on the email content.
When investigating suspicious emails, users should preserve original headers, avoid interacting with attachments or links, and follow organizational reporting procedures.
Forwarding emails or taking screenshots often omits critical metadata; security teams generally require the original message file for accurate analysis.

Updated Sep 9, 2026 · 11:18 am MDT

Adam Leveille CEO & Principal Consultant

16 October 2025 6 min read

The display name on an email is not a security feature. It is a label the sending system chose, and it can say anything at all. So can the signature block, the logo, and the formatting. Those visual details can be copied from a real message, so they are not enough to establish that a request is legitimate.

What is harder to fabricate completely is the delivery record — the technical headers your mail system attached as the message travelled to you. Our new training video walks through them using a fictional sample message with no real sender or recipient. This article is the written companion, for the moments when you have a suspicious email open and want to know what you are looking at.

What headers actually are

Every email carries a block of metadata above the part you read. Your mail client hides almost all of it, because most of it is machinery. It records where the message claims to come from, which servers handled it on the way, and what checks the receiving system performed on arrival.

Three useful starting points are the addresses, the Received chain and the authentication results. A full investigation may require other evidence from the receiving platform.

A fabricated example

Here is an invented header extract. The domains are reserved examples and no real person or organization is involved.

From: Accounts Payable <billing@vendor.example>
Return-Path: <bounce-4471@mailer.unrelated-host.example>
Received: from mx.yourcompany.example by inbound.yourcompany.example; Tue, 8 Sep 2026 09:14:02 -0600
Received: from mailer.unrelated-host.example by mx.yourcompany.example; Tue, 8 Sep 2026 09:14:01 -0600
Authentication-Results: mx.yourcompany.example; spf=pass smtp.mailfrom=mailer.unrelated-host.example; dkim=none; dmarc=fail header.from=vendor.example

Read as prose, that says: the message presents itself as coming from a vendor's accounts department, but the envelope it was actually sent with belongs to an unrelated host. SPF passed — for that unrelated host, which is the point people miss — there was no DKIM signature, and DMARC evaluation against the visible From domain failed.

The addresses are two different things

The From line is what you see. The Return-Path reflects the envelope sender, which is the address the sending server used at the protocol level and where bounces go.

This distinction helps explain email authentication results. SPF checks whether the sending server is authorized for the envelope domain. It does not, on its own, say anything about the domain in the From line you are actually reading. A message can pass SPF cleanly while displaying a completely different organization's name, which is why "SPF passed" in isolation is a much weaker statement than it sounds.

DMARC is the mechanism that ties this back together. It requires alignment with the visible From domain, and it is satisfied by either an aligned SPF result or an aligned DKIM signature — not necessarily both. In the fabricated example above, SPF passed for the envelope domain but nothing aligned with the From domain, so DMARC failed. That is a meaningful signal.

Find the trusted part of the Received chain

Receiving mail servers add Received lines, with the newest above earlier entries. The apparent route runs from bottom to top, but establish which entries your receiving platform added before relying on that route.

A sender can include fabricated header entries. Start with the entries added by your trusted receiving infrastructure and ask your mail administrator to identify that boundary if it is unclear. Earlier entries may offer leads, but need corroboration. Apply the same caution to Authentication-Results: a field merely carrying that name is not necessarily a result your own platform produced.

This is why a screenshot of headers from an unknown source proves very little, and why a security team may request the original message as an attachment or through a reporting tool. An ordinary forwarded copy may omit the original metadata needed for analysis.

What the headers cannot tell you

Be honest about the limits, because overconfidence here causes its own incidents.

Authentication passing does not mean a message is safe or honest. A genuine, well-configured, fully authenticated account that has been compromised may pass authentication while sending an invoice-redirection request. So will a lookalike domain the attacker registered and configured properly themselves.

Authentication failing does not prove deliberate forgery either. Forwarding can affect SPF evaluation, and configuration errors or changes to messages can also affect authentication. A DMARC failure is a reason to look harder, not a verdict.

Headers alone do not reliably establish the person responsible for a message. Treat the whole exercise as gathering context for a decision, not as producing proof.

A practical routine for a suspicious message

Do not click, reply, or open attachments while you are investigating.
Verify the request through a channel you already trust — a phone number you had before the email arrived, never one contained in it.
View the original message source and find the Authentication-Results line your own system wrote.
Check the visible From domain for lookalike spellings, then review authentication alignment. A different Return-Path domain can be legitimate, such as with an authorized sending service.
Identify the trusted receiving entries before using the Received chain to assess the route.
Preserve the message and full headers using the reporting method your security team requests.
Follow your organization’s reporting process when a message remains suspicious. Do not circulate it widely or upload confidential headers to an unapproved service.

Keep the business decision separate from the technical check

Suppose the invented message asks you to change a supplier’s payment details. The authentication failure is useful context, but the immediate decision is whether to act on that request. Follow your established verification and approval process using contact information already on file. Even a passing result should not replace that independent check.

When reporting the message, include what it asked you to do and whether anyone clicked, replied or opened an attachment. That helps the responding team assess the situation. Keep the original available, and avoid editing its contents while collecting evidence.

Your next step

Watch the walkthrough, then practice on a routine message you are authorized to inspect. Comparing familiar examples can help you recognize the fields without the pressure of a live incident.

If you would like your team to have a consistent way of handling suspicious mail — where to send it, who looks, what happens next — that is the kind of practical work the ALCO team does alongside managed hosting, development and IT support.

Sources and further reading

ALCO training on email headers: https://alcohq.com/training/email-headers
Video walkthrough: https://youtu.be/kH91-vZq6C8
Google on preventing spoofing with SPF, DKIM and DMARC: https://support.google.com/mail/answer/81126?hl=en-GB
Google on viewing a message's original source: https://support.google.com/mail/answer/29436?hl=en
RFC 8601 on trusted authentication results: https://www.rfc-editor.org/rfc/rfc8601.html

More from ALCO

6 September 2026

Before you open a support ticket, start here

A quick status check can add useful context to a support request. Here is what to look for and how to describe a problem

ALCO has joined the Caldwell Chamber of Commerce

ALCO USA Inc is pleased to join the Caldwell Chamber of Commerce. We look forward to getting to know fellow members and

Designing monitoring that earns its alerts

Most monitoring degrades into noise within a year. A full account of how we decide what wakes a person, what raises a ti

Apply this to your business

Talk with ALCO about your systems and the next practical step for your organization.

Contact ALCO