Display name spoofing

The name your mail app shows for a sender, like "Accounts Payable" or "Jane Smith", is free text the sender typed. Nothing checks it. SPF, DKIM and DMARC all look at the domain in the address, never at the name. So a message can display any name at all while coming from a completely unrelated address, and every authentication check can still pass. Always look at the actual address, and for anything involving money or passwords, verify through a channel you already trust.

How the From line is built

A From: header has two parts: an optional display name and the address in angle brackets (RFC 5322 §3.4):

From: "Jane Smith" <jane.smith@example.com>

The address is what replies, filters and authentication use. The display name is decoration. RFC 5322 §3.6.2 says the From field should only contain the author's own mailbox, but that is about the address, and no server enforces it for the name. The DMARC specification lists display-name attacks as a known problem it does not solve (RFC 9989 §11.4).

The common tricks

A trusted name on a random address

The simplest version, and still the most common:

From: "Example Corp IT Helpdesk" <helpdesk.notice2026@freemail.example>

The address is a free webmail account. DMARC may well pass, for freemail.example, which is entirely accurate and entirely unhelpful.

An address inside the display name

Because the name is free text, it can contain something that looks like an address:

From: "ceo@example.com" <x83kq@attacker.test>
From: "Jane Smith <jane.smith@example.com>" <x83kq@attacker.test>

Many clients show only the name, so the reader sees ceo@example.com and stops there. This also defeats people who have learned to "check the address", because what they check is not the address. Legitimate systems occasionally do this (a bug tracker sending "user@example.org via Tracker"), which is why mail providers cannot simply block it. The analyser flags any display name that contains an address different from the real one.

Names hidden in encoded text

Display names can be encoded-words such as =?UTF-8?B?...?=. That is normal for non-English names, but it is also used to hide a brand or role name from simple keyword filters, or to slip in look-alike Unicode letters. Decode it before trusting it.

Friendly name, look-alike domain

Combined with a look-alike domain, the name does the persuading and the domain survives a quick glance: "Jane Smith" <jane.smith@example-corp.example> when the real company uses example.com.

Why phones make it worse

Most mobile mail apps show only the display name in the message list and often in the open message too. The address usually appears only after you tap the sender's name. On a small screen, in a hurry, the name is all most people read. Desktop and webmail clients are generally better but not uniformly so, and layouts change between versions: if you can't see the address, look for a way to expand the sender details, typically by clicking or tapping the name.

Some clients also replace the display name with the name from your own contacts if the address matches a saved contact. That is helpful, because it is tied to the address, but it means a familiar-looking name can come from either source. If the name looks right but the message feels off, open the details.

Business email compromise and CEO fraud

The most expensive use of display-name spoofing is business email compromise (BEC). The pattern:

1. The attacker researches the target's organization: who the executives are, who handles payments, which suppliers they use.
2. A short, urgent message arrives "from" the CEO or a known supplier, often with no links or attachments to trip filters: "Are you at your desk? I need a quick favor, keep this between us."
3. Once the target replies, the request follows: an urgent wire transfer, a change of a supplier's bank details, or gift cards for a "client event".

Often the From address is a free webmail account with the boss's name as display name, and a Reply-To pointing to yet another address. In the more advanced version the attacker has taken over a real mailbox at a supplier, so every header check passes and only the request itself is unusual. That is why "verify payment changes by phone, using a number you already have" is the control that actually works.

How to check a sender

1. Reveal the address. Expand the sender details and read the domain after @ character by character.
2. Compare with what you expect. Does your CEO really write from a webmail account? Does the supplier's domain match the one on previous invoices?
3. Check Reply-To. Hit reply and look at where it is addressed before typing anything, or look for Reply-To: in the headers.
4. Read the authentication results from your provider. A dmarc=pass for the expected domain is good evidence the address is real; see DMARC explained.
5. Verify out of band for any request involving money, credentials or secrecy.

Or paste the full headers into the analyser. It shows the display name and address separately, flags names that contain a different address, Reply-To addresses that differ from From, and look-alike domains, and explains what each authentication result does and doesn't prove. For the full process, see spotting phishing from headers.