Display-name spoofing and why DMARC misses it

16 June 2026 · 11 min read

Why your locked-down DMARC policy still lets fakes through

You did everything right. You took your domain from p=none to p=reject, every legitimate sender passes SPF and DKIM with alignment, and your DMARC aggregate reports are clean. Then a colleague forwards you an email that appears to come from your chief executive, asking finance to pay an urgent invoice. The sender shows as "Sarah Okafor, CEO" in their inbox. Panic sets in: did the protection fail?

It did not. This is display-name spoofing, also called friendly-from spoofing, and it is one of the most common reasons people wrongly conclude that DMARC is broken or pointless. The uncomfortable truth is that DMARC was never designed to stop this attack, and understanding exactly why is the difference between a security programme that closes the gap and one that leaves a wide, easily exploited hole behind a green padlock.

This article explains what display-name spoofing is, the precise mechanical reason DMARC does not catch it, where it shows up in real attacks, and the layered controls that actually mitigate it. If you have not yet locked down your own domain, start with a DMARC checker to see your current policy, but read on, because reaching p=reject is only part of the story.

What "from" really means in an email

To see why display-name spoofing works, you have to understand that an email contains not one "from" but several, and they protect different things.

There is the envelope sender, also called the Return-Path or MAIL FROM. This is part of the SMTP conversation between mail servers and is where bounces go. SPF authenticates the domain in this envelope sender.

There is the header From, the From: line inside the message itself. This is what email clients display to humans, and it is the field DMARC cares about. It looks like this:

From: "Sarah Okafor, CEO" <sarah.okafor@yourcompany.com>

That single line has two distinct components:

• The display name: Sarah Okafor, CEO, the friendly label in quotes.
• The addr-spec, or actual email address: sarah.okafor@yourcompany.com, the part inside the angle brackets.

DMARC, defined in RFC 7489, evaluates alignment against the domain in the addr-spec only, the bit after the @. In the example above, that is yourcompany.com. The display name is, as far as the authentication machinery is concerned, an arbitrary string of decorative text. It is not authenticated, not validated, and not checked against anything.

This is the whole crux of the problem. When an attacker spoofs a display name, they are not touching the part of the message DMARC inspects. They leave it untouched precisely so they can pass.

How a display-name spoof is actually built

A display-name spoof typically uses an address the attacker fully controls, paired with a deceptive name. Here is a realistic example of the headers in such a message:

From: "Sarah Okafor, CEO" <accounts2026@gmail.com>
Reply-To: ceo.sarah.okafor@protonmail.com
Subject: Quick favour

Walk through what DMARC sees here. The header From domain is gmail.com. The message is genuinely sent through Gmail's infrastructure, by an attacker who registered accounts2026@gmail.com minutes earlier. So:

• SPF passes, because Gmail's servers are authorised to send for gmail.com.
• DKIM passes, because Gmail signs the message with a valid gmail.com signature.
• DMARC passes, because the authenticated domain (gmail.com) aligns with the header From domain (gmail.com).

Every check is green. The message is, by every technical measure, a legitimate email from a real Gmail account. The only deception is the human-readable display name, which has nothing to do with yourcompany.com at the protocol level. Your p=reject policy on yourcompany.com is never even consulted, because the message does not claim to be from yourcompany.com in the field DMARC checks.

The Reply-To is the second half of the trap. The recipient hits reply, and the conversation quietly redirects to an address the attacker monitors, often on a different provider entirely. Many mail clients hide the Reply-To and the real From address behind the display name, so the victim never sees the mismatch.

Why mobile and modern clients make it worse

On a desktop client with a wide window, a careful user might see the full address: Sarah Okafor, CEO <accounts2026@gmail.com>. The gmail.com is a red flag if they are paying attention.

But most email is now read on phones, and almost every mobile mail app shows only the display name by default. The user sees "Sarah Okafor, CEO" and nothing else unless they tap to expand the header, which almost nobody does. Worse, some clients match the incoming display name against the recipient's contacts or prior correspondence and helpfully attach the saved photo and verified-looking styling to it, lending the fake an air of legitimacy the attacker did not even have to forge.

This is a deliberate user-experience decision by mail clients. Display names exist to be friendly and readable. Friendliness and security are in direct tension here, and the client almost always chooses friendliness.

A close cousin: lookalike and cousin domains

Display-name spoofing is often discussed alongside two related tricks, and it is worth separating them because the defences differ.

Exact-domain spoofing is the attack DMARC genuinely does stop. Here the attacker forges From: sarah.okafor@yourcompany.com directly. With p=reject and proper alignment, this is rejected at the recipient's mail server. If your domain is not yet at enforcement, this attack is wide open, and it is the single most important reason to get there. You can check your enforcement status with the DMARC checker and generate a correct record with the DMARC record generator. For the deeper context on enforcement, see /products/dmarc.

Cousin-domain or lookalike spoofing uses a domain that resembles yours but is genuinely registered by the attacker: yourcompany-billing.com, yourcornpany.com (with rn replacing m), or yourcompany.co instead of .com. The attacker can set up perfectly valid SPF, DKIM and DMARC on this lookalike domain, and it will pass all authentication, because it is the attacker's domain and they are entitled to authenticate it. DMARC on your real domain is irrelevant.

Display-name spoofing is the laziest and most common of the three because it requires no domain registration at all. Any free webmail account plus a convincing display string is enough. There is nothing to take down, nothing to report to a registrar, and the sending domain (gmail.com, outlook.com) is one you cannot blocklist without losing huge volumes of legitimate mail.

All three are forms of impersonation. Only the first is in DMARC's job description.

What DMARC does and does not protect

It helps to state the boundary plainly.

DMARC protects the exact domain in the header From address from being used without authorisation. When you publish p=reject, you are telling the world's mail servers: "If a message claims to be from @yourcompany.com but does not authenticate as such, throw it away." That is enormously valuable. It stops direct-domain phishing, it stops a great deal of spam sent in your name, and it protects your domain's reputation.

DMARC does not:

• Validate or check the display name.
• Stop messages from other domains that merely mention your brand in text.
• Stop lookalike domains.
• Inspect message content, links, or attachments.
• Verify that the human named in the From line is really the sender.

If you internalise one sentence from this article, make it this: DMARC authenticates a domain, not a person and not a name. Display-name spoofing impersonates a person while using a domain the attacker legitimately controls, so it sails straight through. This is not a bug or a misconfiguration. It is the documented scope of the protocol. RFC 7489 is explicit that DMARC operates on the RFC5322.From domain.

Where this shows up in real attacks

Display-name spoofing is the workhorse of business email compromise (BEC) and CEO fraud, which the FBI's Internet Crime Complaint Center has repeatedly ranked among the costliest categories of cybercrime by total losses, far exceeding ransomware in aggregate dollar terms. The reason it dominates is precisely its simplicity and its immunity to DMARC.

Common patterns include:

• The executive payment request. "Sarah Okafor, CEO" emails accounts payable asking for an urgent wire transfer or gift-card purchase, with a plausible reason to bypass normal process.
• The supplier invoice swap. A spoofed display name of a known vendor's accounts contact sends "updated banking details" for an upcoming legitimate payment.
• The HR or payroll redirect. An employee's display name is spoofed to ask HR to change the destination of their salary to a new account.
• The IT credential lure. "IT Helpdesk" or "Microsoft 365" as a display name, sending a password-reset link to a phishing page.

In every case the attacker relies on the recipient reading the name, trusting it, and acting under time pressure before checking the actual address. The email infrastructure performed flawlessly. The human was the target.

How to actually mitigate display-name spoofing

Because the gap is outside DMARC's scope, you close it with layers. No single control catches everything, and anyone selling you "one feature that stops impersonation" is overselling. Here is the realistic stack, roughly in order of impact.

1. Get your own domain to p=reject first

This sounds counterintuitive given that DMARC does not stop display-name spoofing, but it is the foundation. If your domain is still at p=none, attackers do not even need the display-name trick: they can forge your exact address. Closing the exact-domain hole forces attackers onto the harder, noisier ground of lookalikes and free webmail, where other controls have a chance. Confirm SPF with the SPF checker and DKIM with the DKIM checker, then drive the policy to enforcement. This is exactly the migration the done-for-you service handles without risking an email outage.

2. Anti-impersonation rules at your mail gateway

Most serious mail security platforms, and Microsoft 365 and Google Workspace in their higher tiers, let you write rules that inspect the display name itself. The high-value rule is:

If the display name contains the name of any of our named executives (or our company name) and the From address is not one of our verified domains, then quarantine or warn.

This directly targets the "Sarah Okafor, CEO from a gmail.com address" pattern. Maintain a short list of your most-impersonated people (executives, finance leads, HR) and feed it into this rule. It is one of the few controls that looks at the display name at all, since the authentication layer never does.

3. External-sender warning banners

Configure your mail system to prepend a visible banner to any message originating outside your organisation: something like "CAUTION: This email came from outside the company." When a message claiming to be from your CEO carries an external banner, the contradiction is obvious even to a distracted reader on a phone. This is cheap, broadly effective, and one of the highest return-on-effort controls available.

4. Anti-spoofing and intelligent impersonation detection

Modern gateways add machine-assisted detection that flags newly registered sending domains, first-time senders claiming to be known contacts, and display names that closely match internal staff. These catch the cousin-domain and display-name cases that static rules miss. Tune them with care to avoid burying users in false positives, which trains people to ignore warnings.

5. Process controls that do not rely on email at all

Technical controls reduce volume, but BEC ultimately exploits a business process. The controls that have actually stopped large frauds are organisational:

• Out-of-band verification for payments. Any change to banking details or any unusual payment is confirmed by a phone call to a known number, never a number supplied in the email.
• Dual authorisation for transfers above a threshold.
• A "no urgency" culture where staff are explicitly told that real executives will never penalise them for pausing to verify a request.

These are not glamorous, but they are the backstop that holds when every technical layer is bypassed.

6. User awareness, framed honestly

Train people to tap or hover to reveal the real address, not just the display name, and to treat any unexpected request for money or credentials as suspect regardless of who it appears to be from. Crucially, teach them that "it passed our spam filter" and "the name looks right" are not evidence of authenticity. The goal is a reflex to verify, not a memorised list of red flags that attackers will simply route around.

Monitoring: seeing the patterns before they cost you

Display-name spoofing leaves footprints. Your DMARC aggregate reports will not show it (the messages do not use your domain), but they will show you something adjacent and valuable: every source genuinely using your domain. Once you know your legitimate senders cold, anything outside that set is a candidate for investigation, and you can reason clearly about what is and is not your traffic.

Use the DMARC report analyzer to turn the dense XML of aggregate reports into a readable picture of who sends as your domain. Pair that with continuous monitoring so that a sudden change in your authentication results, or a new and unexpected sending source, raises an alert rather than sitting unnoticed in an inbox nobody reads. Knowing your own legitimate footprint is what lets a security team say with confidence "that is not us" when an impersonation attempt surfaces.

For brand-level signals that help recipients recognise genuine mail, a verified logo through BIMI (check yours with the BIMI checker) and strict transport security through MTA-STS (check it with the MTA-STS checker) raise the overall bar. They do not stop display-name spoofing directly, but a recipient accustomed to seeing your verified logo on real mail has one more cue that a logo-less impersonation is off.

A worked mitigation example

Suppose you run email for a 200-person firm and you want to shut down CEO fraud as far as practically possible. A concrete plan:

1. Verify your domain reaches p=reject with aligned SPF and DKIM, using the DMARC checker and the SPF checker. This removes exact-domain forgery from the table.
2. Register the most obvious lookalike domains of your own brand defensively, so attackers cannot cheaply grab yourcompany-payments.com.
3. Add a gateway rule: quarantine any inbound message whose display name contains your CEO's, CFO's or company name when the From domain is not yours.
4. Turn on external-sender banners for all inbound mail.
5. Write a one-page payments policy requiring phone verification of any banking-detail change, and brief finance specifically.
6. Set up monitoring with change alerts so any drift in your authentication posture is caught the day it happens.

No single step in that list is exotic, and none of it depends on DMARC catching the display-name trick, because it cannot. The protection comes from stacking controls so that the one path through every layer is narrow enough to manage with human process.

The practical takeaway

DMARC is essential, and getting to p=reject is one of the highest-value security investments a domain owner can make. But it protects the domain in the From address, not the friendly name a human reads. Display-name spoofing exploits exactly that gap: a real account, a real authenticated domain, and a fake name. It will pass DMARC every time, by design, and concluding that DMARC has failed misreads what DMARC was ever meant to do.

Close the gap with layers: enforcement on your own domain first, then gateway rules that actually inspect display names, external banners, impersonation detection, and the out-of-band process controls that catch what technology misses. Then watch your traffic so you know your own footprint and can spot what is not you.

Start by confirming where your domain stands today with the free DMARC checker and the wider tools suite. If you would rather have the whole authentication stack taken from p=none to p=reject safely, with monitoring and change alerts handled for you, that is exactly what the done-for-you platform is built to do. To understand the full landscape of requirements, see /requirements, and keep the glossary handy for any term above that was new.