Suspicious email? Here is how to follow the trail

AI summary

ALCO USA Inc provides guidance on the proper workflow for identifying, preserving, and escalating suspicious emails. The process emphasizes avoiding interaction with the message, retrieving the original email source rather than forwarding, and providing detailed context to the internal security or support team. Headers serve as valuable context for investigations, but they do not guarantee the legitimacy of a sender or request, necessitating out-of-band verification for sensitive actions.

Do not interact with suspicious links, attachments, or requests; verify sensitive tasks like payments or credential changes via a trusted, established communication channel.
Preserve the original email by using the built-in 'original source' or download features of your email client rather than forwarding the message, which may strip necessary headers.
When escalating to a security team, provide the original source file, the time of arrival, any actions already taken, and whether others received the message.
Authentication results, such as SPF, DKIM, and DMARC, are useful for context but do not definitively prove a message is trustworthy or malicious.

Updated Sep 9, 2026 · 11:18 am MDT

Adam Leveille CEO & Principal Consultant

3 October 2025 6 min read

Email headers can help a support or security team assess a suspicious message. To use them, the team needs the original information and a clear account of what happened. Knowing how to preserve and report the message is a useful preparation step.

Our email-header walkthrough uses a fabricated message to show what the delivery information means. This article covers the surrounding workflow: how to retrieve the original, what to look at first, how to escalate it so somebody can actually act, and what the whole exercise can and cannot establish.

Step one: stop, before you touch anything

The first decision is not technical. Do not click links, do not open attachments, and do not reply — use a separate trusted channel if you need to verify the request.

If the message asks for anything consequential — a payment, a change of bank details, credentials, an urgent purchase — verify through a channel you already had. Call the number in your accounting system or on a prior invoice, never a number contained in the suspicious message. Follow the organization’s payment-verification and approval process even if the message appears technically authentic.

Report promptly through your established process. You do not need to complete a technical investigation before asking for help.

Step two: retrieve the original, intact

An ordinary forward usually quotes the message inside a new one and may omit the original technical headers. The original message can still be present in your mailbox, but the forwarded copy may not contain what the investigator needs.

Instead, retrieve or preserve the original.

In Gmail, the "Show original" option on an individual message displays the full source and lets you download it. Google documents this, along with what the resulting page shows about authentication. That downloaded file is the thing worth sending on.

For other mail applications, use the current instructions for the exact version you run or ask your support team for the approved reporting method. An organization may provide a report-message button that collects the necessary information without a manual export.

If your mobile app does not expose the original, report what you can immediately and ask whether a desktop or web interface is needed for collection. Do not delay reporting a possible compromise while trying to find a menu option.

The goal is to preserve the original metadata through an approved channel. Send an original attachment or downloaded message only to the designated team when requested; avoid distributing suspicious content more widely.

Step three: read the part that carries weight

With the original open, a useful starting point is the Authentication-Results header written by your own receiving system. That is the record of what your mail platform concluded when the message arrived — whether SPF passed for the envelope sender, whether a DKIM signature validated, and whether DMARC alignment with the visible From domain succeeded.

Gmail also surfaces some of this per message in its interface, and documents how to check whether a message was authenticated by the sending domain. That is a reasonable first look for anyone who does not want to read raw headers.

Check the visible From domain for lookalike spellings and review authentication alignment. A different Return-Path can be legitimate when a sending service is used. Before interpreting the Received chain, identify the entries added by your trusted receiving platform; the apparent chronology runs from older entries below to newer ones above.

Senders can include fabricated header fields, including fields that resemble authentication results. Entries outside the trusted receiving boundary need corroboration. If you cannot identify that boundary, leave interpretation to the mail administrator. A screenshot can show symptoms, but it is not a substitute for the original record.

Step four: escalate usefully

When you hand this to whoever handles security in your organization, include

The original message as an attachment or downloaded source file, not a screenshot and not a normal forward.
The mailbox that received it and the time it arrived.
Whether anyone clicked, replied, opened an attachment, or entered credentials — honestly, and immediately if the answer is yes.
Whether other people received something similar.
What the message was asking for, and whether any action was taken on it.
Whether the sender is someone you genuinely correspond with, and whether this message sits inside an existing thread.

Report any interaction promptly, even if you are unsure whether it caused harm. A password reset alone may not resolve every consequence. The responding team needs to assess the relevant account, sessions, devices and any information disclosed before deciding what action is appropriate.

Make reporting easy and blameless

Publish a clear reporting route and explain what staff should do if that route is unavailable. Acknowledge reports and give people a way to share mistakes without blame. The purpose is to obtain accurate information and respond appropriately, including when a message ultimately turns out to be legitimate.

Record related reports in a controlled place. Similar messages may indicate a wider pattern worth investigating, but timing or a shared theme alone does not prove a coordinated campaign.

What this will not establish

Headers describe message handling and authentication. They do not, on their own, reliably identify the person responsible or prove that a business request is legitimate.

Authentication passing does not mean a message is trustworthy: a compromised legitimate account may pass authentication, and so does a lookalike domain an attacker configured correctly. Authentication failing does not prove deliberate forgery either, because forwarding, message changes and configuration issues can affect the results.

Treat the trail as context that improves a decision, and keep the out-of-band verification habit regardless of what it says.

Practice the handoff with a harmless example

Choose a routine message that staff are authorized to use and demonstrate the reporting method without introducing a real suspicious attachment. Check that the designated recipient can access the information and knows who owns the next step. Record the method in terms of the mail application people actually use.

Keep the instructions short enough to follow under pressure: where to report, what happened, whether anyone interacted and how to preserve the original if requested. More detailed header analysis can sit in a separate technical guide. The first report should help the team respond, not require the sender to become an investigator.

Your next step

Watch the walkthrough, then work out today how to retrieve an original message in whatever mail client your team uses, and write those steps into your internal documentation next to the reporting address.

If you would like help establishing that process, ALCO USA Inc does this kind of practical work 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 viewing a message's original source: https://support.google.com/mail/answer/29436?hl=en
Google on checking whether a message was authenticated: https://support.google.com/mail/answer/180707?hl=en
Google on preventing spoofing with SPF, DKIM and DMARC: https://support.google.com/mail/answer/81126?hl=en-GB
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