Skip to content
Got A Tool

Practical guide

Inspect a suspicious email without treating one signal as proof

A sender name, a passed authentication record, or a familiar-looking attachment can all be incomplete evidence. Preserve the original message, inspect only what you need, and use your organisation's reporting path when the risk is real.

Updated October 24, 2026 · Prepared and reviewed by Got A Tool

Pause before you click, reply, or open an attachment

If the message requests money, credentials, sensitive data, or an urgent action, do not use its links or reply address to verify it. Use a known official contact route or your organisation's support and security process instead.

1. Keep a source copy and choose the question you need answered

A saved EML file and copied headers can contain message content, recipients, route information, and attachments. Keep the original unchanged. Decide whether you need to review the recorded route, inspect a supported attachment, or simply report the message; they are separate actions.

You need to read the recorded header

Inspect the Received route and authentication results already present in the message without uploading the header to another service.

Open Email Header Viewer

You need a supported attachment copy

Review the saved EML file and attachment names before extracting a ZIP locally. Do not open an attachment just to identify it.

Open EML Attachment Extractor

2. Read authentication results as recorded evidence, not a verdict

SPF, DKIM, and DMARC entries describe checks recorded for a message. A pass can be useful context, but does not tell you whether the request is appropriate, whether a legitimate account was compromised, or whether an attachment is harmless. A fail can also need interpretation by the sending domain or your mail administrator.

  • Compare the sender address, requested action, and context with a known independent source.
  • Treat an unexpected urgency, payment request, or credential prompt as a reason to verify outside the message.
  • Do not publish headers casually; they can contain addresses, internal routing details, and message identifiers.

3. Handle attachments as untrusted files

A filename and icon do not establish what a file is safe to run or open. Extracting a supported attachment is not a safety scan. If you are not authorised to analyse it, use your organisation's approved security process instead of forwarding it, uploading it to a random service, or opening it on a normal work device.

The local tools can help inspect supported saved content, but they do not verify identity, scan attachments for malware, or decide whether a message is legitimate.

Report or verify through a route you already trust

Use your mail provider's report controls, security team, or a phone number and website you obtained independently. Keep the original message until your approved process no longer needs it.

Common questions

Does SPF, DKIM, or DMARC passing mean an email is safe?

No. It is useful recorded evidence about sender authentication, but it does not establish that the request, link, account, or attachment is safe or appropriate.

Can an email header tool identify who really sent a message?

It can show the route and results recorded in the header. It does not independently verify every server, resolve a sender's intent, or replace a security investigation.

Should I upload a suspicious EML file to an online service?

A saved email may contain private message content, addresses, and attachments. Use tools whose handling you understand, and follow your organisation's approved security process for real incidents.