A fraudulent message can use a real company’s logo, a copied signature, and professional language. Those details may make it familiar, but they do not establish who sent it or whether the request is authorized. Treat the appearance as context rather than as a security check.

Spelling mistakes or unusual phrasing can be reasons to pause, but their absence does not make a message safe. A useful review considers the actual request, the address, available technical evidence, and an independent way to confirm a consequential action.

What a team needs instead is a shared ranking of how much different signals are actually worth. Our email-header walkthrough shows where the stronger signals live. This article is the framework for using them.

The weakest evidence, ranked from the bottom

Visual design does not authenticate the sender. The logo, the layout, the fonts, the footer, the little unsubscribe link at the bottom. All copied trivially. Treat a beautiful email exactly as you would treat a plain one.

The display name is not proof of the sender’s identity. It is free text chosen by the sender. Your phone probably shows it in bold and hides the actual address entirely, which is a user interface decision, not a security assessment.

Tone and context are worth a little, and this is where people are genuinely good. Humans are decent at noticing that a colleague does not usually write like this, or that the finance director does not normally ask for anything at 6pm on a Friday. Encourage the instinct, but do not rely on it alone — an attacker inside a compromised mailbox has the whole thread history to imitate.

The middle of the ladder

The actual sender address is worth something real, if someone looks at it properly. Not glances at it — reads it, character by character, in full. Similar domain names can be easy to overlook, so compare the complete address with a trusted record.

Whether the message sits in a real thread is worth something too, with a serious caveat. Attackers who have access to a mailbox reply inside existing conversations, which is why thread continuity is a comfort signal rather than an authentication one.

Links deserve their own note. Hovering to see the real destination is a habit worth building, and mobile makes it awkward, so use your platform’s safe inspection method or ask support for help. Where the link goes matters far more than what it says.

The strongest evidence available to you

Two things sit meaningfully above everything else.

The first is the Authentication-Results line your own mail platform wrote when the message arrived. That record may show the authentication checks performed by the receiving platform. Read it in the context of the platform’s documentation or ask an administrator to interpret it. A result describes a technical check; it does not approve the business request inside the message.

The critical qualifier is authorship. Authentication results added by your trusted receiving platform carry weight within its established trust boundary. Headers written by anyone else are claims, and can be fabricated in full, including invented delivery hops that read convincingly. Preserve the original message in the receiving platform when possible. A screenshot alone may omit the context needed to establish which system added a field.

The second, and stronger still, is out-of-band confirmation. Picking up the phone and calling a number you already had — from your accounting records, a prior invoice, or your own contacts, never from the message itself — provides a separate way to check the request. Follow your organization’s approval process as well, because a call alone is not a guarantee that a payment or account change is legitimate.

Building the ladder into a habit

  • Decide as a team that the visual appearance of an email is not evidence, and say so out loud.
  • For anything asking about money, credentials, or access, go straight to out-of-band verification. Do not investigate first.
  • Make reading the full sender address, not the display name, a standard step.
  • Teach one person per team where to find the authentication results in your mail platform.
  • Publish a single reporting address, and acknowledge every report including the false alarms.
  • Adopt a standing rule that bank detail changes are confirmed by phone to a previously known number, in both directions.
  • Never criticize someone for clicking. The next person watching decides whether to report based on how the last one was treated.

Where the ladder still fails

Be clear about the ceiling. A fully authenticated message from a genuinely compromised account will sit at the top of this hierarchy and still be fraudulent — the account is real, the signature is real, the thread is real. Independent verification and established approval controls can help with that situation, alongside the organization’s account-security and incident-response measures.

Equally, a failed authentication result is not proof of an attack. Forwarding, mailing lists and configuration problems can complicate authentication results. Investigate the context rather than treating each failure as conclusive evidence of malice.

Nothing here identifies a person. Headers describe systems and the claims those systems made. The output of this process is a better decision, not a proof.

Your next step

Watch the walkthrough, then use a fabricated or appropriately sanitized example to walk through the review process together. Keep confidential material out of training exercises and do not open suspicious attachments or links. A practice discussion can help people understand how the policy applies to an ordinary request.

If you would like help putting a reporting and verification process in place, that is 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 checking whether a message was authenticated: https://support.google.com/mail/answer/180707?hl=en

RFC8601, authentication results and trust boundaries: https://www.rfc-editor.org/rfc/rfc8601.html