The Name Says HMRC, the Domain Says Something Else

The display name is the part of an email that humans actually read. Everything else — the headers, the return path, the authentication results — is for machines. Fraudsters know this, which is why a message can sail through SPF, DKIM and DMARC with a perfect score and still be a scam.

Authentication proves a domain, not a person

DMARC alignment tells you one thing: the domain in the From header is authorised to send. It does not tell you the sender is HMRC. It does not tell you the sender is your finance director. It tells you that whoever sent the message controls, or has permission to use, that domain.

So a message from [email protected] with the display name 'HMRC Payment Support' is technically spotless. The domain passes its own SPF check because the fraudster configured the DNS themselves. DKIM signs. DMARC aligns. Every box ticked — and the whole thing is still a phishing attempt aimed at someone who has just moved house and is waiting on a tax rebate.

The display name is not an identity claim that any protocol verifies. It is free text. Anyone can set theirs to 'Microsoft 365 Admin' in about four seconds.

Why it still works on people who know better

A few reasons, and most of them are about design rather than naivety.

Mobile clients show a name and maybe forty characters of subject line. The address, if it appears at all, is in small grey type underneath — and in a push notification it does not appear at all. Outlook on a phone will show you 'IT Service Desk' and nothing else until you tap in. If you are reading on the 07:42 between Leeds and London, that is the entire message.

Add in the fact that UK organisations genuinely do send from shared mailboxes, outsourced platforms and third-party marketing tools, and the question 'why is this from an odd domain?' has about a dozen innocent answers. People have been trained to stop asking it.

And the timing is engineered. A display-name scam lands when the sender knows you are expecting something: a Companies House confirmation, a payroll change before the 19th of the month, a Microsoft 365 licence warning that reads like every genuine one you have ever ignored.

The tells worth teaching

Four things, in rough order of usefulness:

• The address behind the name. Is the domain the one you would expect? hmrc.gov.uk is real; hmrc-refund.co.uk is not. Check it every single time for anything involving money or credentials.
• Reply-To divergence. If replying would go somewhere different from the visible sender, that is a strong signal. Legitimate senders do it for support routing; fraudsters do it so your reply lands in a mailbox they control.
• Freemail for a corporate sender. 'Barclays Security Team' sending from a free webmail address is not a thing. Apply the rule to organisations rather than individuals — a real person at a supplier might well use freemail.
• Urgency plus a link. Anything demanding action within 24 hours via a link deserves two minutes of scepticism.

Reading headers without being a mail admin

You do not need a mail gateway to check. Every mainstream client will show you the raw source:

• Gmail: the three-dot menu, then 'Show original'. Look at the Authentication-Results block and the Return-Path.
• Outlook on the web: 'View' then 'View message source'. Desktop Outlook hides the equivalent under message options.
• Apple Mail: 'View', then 'Message', then 'All Headers'.

What you are looking for is boring: does the From domain match the Return-Path domain, does the authentication block say pass, and does the sending IP look like something a legitimate provider would use. A mismatch is not automatically fraud — mailing lists and CRMs create mismatches all day long — but a mismatch plus a display name claiming to be your bank is worth acting on.

Filtering rules that actually help

Since the display name is unverified, your filtering has to lean on things that are.

1. Tag external mail. A banner or subject prefix saying 'External' is crude, but it breaks the spell in under a second and costs nothing.
2. Block on the combination, not the name alone. Rule: if the display name contains 'HMRC', 'Microsoft', 'PayPal' or your own company name AND the From domain is not on an allowlist, quarantine it. Legitimate senders get allowlisted once and never think about it again.
3. Enforce DMARC at p=reject on your own domain. This is about people spoofing you, not about catching people spoofing others. Both matter. If someone can send as your domain to your own customers, that is your problem to fix.
4. Watch newly registered domains. A lot of these campaigns run on domains registered days earlier. Flagging or blocking anything under thirty days old catches plenty of noise.
5. Do not rely on names in your blocklist. Fraudsters rotate them weekly. Block on the address pattern, the reply-to, or the link domain — things that cost them money to change.

The gap is a human one

The uncomfortable conclusion is that this attack does not exploit a technical weakness. It exploits the fact that we read names and skim addresses, and that our mail clients are designed to make that easy. Fixing it is a mix of boring hygiene — authentication on your own domains, external tagging, sensible allowlists — and one habit change on the reading end: before you click, look at what comes after the @.

Passing SPF, DKIM and DMARC means a message is who it says it is at the domain level. It says nothing about whether the name on the front is telling the truth. Those are two different questions, and only one of them is answered by your mail server.