Why does an email's sender name display as the email address for some recipients?
Updated on 25 Oct 2026: We added sender-name settings for Gmail and Outlook and clarified contact overrides, header encoding, and authentication checks.
An email's sender name displays as the email address for some recipients because the receiving mailbox app decides what to show using the message headers, local contact data, and its own interface rules. The sender usually provides both a display name and an email address, but the recipient's client can ignore the display name and show the address instead. A missing or malformed display name can also cause an address-only display.
If several mailbox apps show BrandName but one shows sender@email.brandname.com, check the received From header before changing the sending setup. It is often a recipient-side rendering decision, a local address book override, a cached sender profile, or a security choice by that specific mailbox provider.
- Fast check: Ask for a screenshot, the full message headers, the receiving email client name, and the client version before changing DNS or sender settings.
- Likely cause: One client is choosing the address field over the friendly From name, often because of contacts, caching, authentication display rules, directory data, or anti-impersonation behavior.
- Best response: Verify the header first, then test authentication and inbox rendering across clients instead of assuming the campaign platform changed something.
What the sender name actually is
The sender name people see in the inbox normally comes from the display name in the message's From header. That header can contain a friendly name plus an address. For example, the friendly name is BrandName and the address is sender@email.brandname.com.
Example From headertext
From: "BrandName" <sender@email.brandname.com> Reply-To: support@brandname.com
The display name is optional metadata. The address in angle brackets is the mailbox identity the message carries, and some clients treat that address as the safer fallback when the display name is missing, unfamiliar, or locally overridden.
The From header declares the author's mailbox and can include a display name, but it does not dictate the final inbox label. Some clients prioritize the address because it is less ambiguous. Others use the saved contact name, previous conversation history, directory information, or a sender profile tied to that mailbox.
Display name control is shared
The sending platform controls the header value it sends. The receiving mailbox app controls what appears in the inbox. That split explains why one recipient can see the email address while other recipients see the brand name from the same campaign.
The same email can look different in Gmail, Yahoo, Outlook, Apple Mail, a corporate inbox, and a webmail client. The email itself can be identical, but each client has its own rendering rules. Some show extra information for unknown senders, use saved contact labels, or make different choices on mobile and desktop.
Do not confuse the sender picker you see while composing with the recipient's inbox display. Some apps show the email address in account selection screens even when the outgoing message still includes the correct friendly From name.
Why only some recipients see the address
When only a subset of recipients sees the sender address instead of the friendly From name, check rendering and recipient context first. A missing display name usually affects recipients consistently, but clients can handle the same malformed header differently. A one-client issue points to local handling only after you confirm that the received From header is valid.
|
|
|
|---|---|---|
Client display rule | One app shows address | Screenshot and app version |
Contact override | Saved label wins | Recipient contacts |
Trust or safety cue | Warning or extra identity | Headers, authentication, and sender fields |
Cached sender | Old identity appears | Prior messages |
Directory profile | Tenant name wins | Corporate directory |
Header formatting | Name ignored | Raw source |
Common causes when the sender name changes by recipient.
The recipient's address book is a common cause. If the recipient saved sender@email.brandname.com with the address as the contact name, the mailbox app can show that saved label. Previous correspondence can also leave an old sender name in the client's history. Ask the recipient to correct the saved contact name and check for duplicate contacts using the same address, then test a new message. The sender cannot edit the recipient's contacts.
Gmail documents a specific first-contact case: it can show the email address next to the sender's name when the recipient has not emailed that sender before. After the recipient replies or adds the sender to contacts, Gmail can stop showing the extra address. That behavior places the address beside the name rather than proving that the From header lost its display name. See Google's sender details documentation.
Corporate directories add another layer. A Microsoft 365, Exchange, Google Workspace, or internal directory profile can supply a display label that differs from the message header. Directory changes can also take time to propagate, so one employee can see the updated sender name while another still sees the address or an older label.
Security display logic is another cause. Some clients expose the actual address or add secondary identity details for new senders and messages whose sending domain differs from the visible From domain. Warning banners or authentication failures can appear at the same time, but the raw headers are needed to distinguish a client safety display from a malformed From header.
How the From header, contact data, authentication, and email client rules affect the displayed sender name.
How authentication affects sender display
SPF, DKIM, and DMARC do not set the inbox label or prove that a friendly name belongs to the sender. SPF authenticates the envelope MAIL FROM identity, DKIM authenticates a signing domain, and DMARC validates use of the visible From domain when at least one authenticated domain matches it under the published mode. Filtering, spam placement, warning labels, or extra identity details can change after an authentication failure, but the failure does not prove why a client showed the address.
If the display changes for one recipient, inspect the raw From header first. Check authentication when the headers record a failure, the client shows "via," warning labels appear, or inbox placement also changed. An "on behalf of" label can be normal delegated sending, so inspect the Sender field before treating it as an authentication problem.
Likely client-side issue
- Scope: Only one recipient, one mailbox provider, or one app version shows the address.
- Header: The raw source still contains the expected display name.
- Action: Collect screenshots, headers, device type, and client version.
Likely sending-side issue
- Scope: Many recipients across several providers see the same bad display.
- Header: The display name is missing, malformed, or different in the raw source.
- Action: Fix the sender profile, header encoding, or alias routing. Investigate authentication separately if it fails.
RFC 9989 is the current DMARC specification and obsoletes RFC 7489. DMARC passes when either the SPF-authenticated MAIL FROM domain or a passing DKIM d= domain matches the visible From domain under the record's mode. Relaxed mode accepts the same Organizational Domain, while strict mode requires an identical domain. A pass does not guarantee the friendly name, and a fail does not prove why the client showed the address.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a broad check, use Suped's domain health checker to check published authentication records when warnings or authentication failures accompany the display issue.
How to diagnose the exact cause
The fastest way to diagnose this is to separate the message the recipient received from the way their app rendered it. Screenshots tell you what the user saw. Full headers show the received sender fields and the receiver's authentication results. Compare the received source with the sender's copy if a mailing list or mail gateway could have rewritten the From header during delivery.
- Screenshot: Ask for the inbox view and the opened message view because some clients show different sender labels in each place.
- Headers: Ask for the original .eml file or full message source. An inline forward can omit the original headers; an attached original preserves them.
- Client details: Record the mailbox provider, app name, app version, operating system, and whether it happened on web, desktop, or mobile.
- Contact state: Ask whether the recipient has the sender saved as a contact, has previous replies, or uses a shared corporate directory.
- Repeat test: Send the same message to a fresh mailbox at the same provider, then open the affected mailbox in webmail and another app to compare the display.
Header fields worth checkingtext
From: "BrandName" <sender@email.brandname.com> Sender: mailer@email.brandname.com Reply-To: support@brandname.com Return-Path: <bounces@email.brandname.com> Authentication-Results: receiver.example; spf=pass smtp.mailfrom=email.brandname.com; dkim=pass header.d=email.brandname.com; dmarc=pass header.from=email.brandname.com
If the raw From header says "BrandName" but the recipient sees sender@email.brandname.com, the display name was present when the message arrived. That points away from the sending system and toward the receiving client or local account state.
The Reply-To, Sender, and Return-Path fields usually do not replace the inbox sender name. They can still appear in details panels, reply flows, or on-behalf-of labels, so record them instead of treating every visible address as the same field.
If the received From header lacks the expected display name or has invalid quoting, compare it with the sending system's copy. A triggered campaign can use a different sender profile, and an integration can put the address into the name field. A mailing list or gateway can also rewrite the header. Encoded text in raw source is not automatically an error; decode it before deciding that the name is wrong.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A practical next step is to send the same triggered email to Suped's email tester and inspect the message source, authentication results, and visible sender fields in one place.
Check aliases, delegated sending, and hybrid mail
An alias, shared mailbox, or delegated Send As identity can use a different sender-name setting from the primary mailbox. Editing the primary account name does not fix a route that emits an alias address without a display name or adds a separate Sender field that the client shows as "on behalf of."
Test the exact path that produced the complaint. A manual message composed in the primary mailbox can have a correct From header while a message sent through an alias, delegation, scheduled rule, or automated reply uses another identity.
- Alias or Send As entry: Set the name on the exact address used to send, then inspect a new message's raw From header.
- Delegated mailbox: Compare mail sent after opening the mailbox directly with mail sent on its behalf from another account.
- Automated path: Test out-of-office replies, filtered responses, scheduled mail, and triggered messages separately.
- Hybrid routing: If only on-premises Exchange mail sent to Microsoft 365 loses the name, check whether the hybrid route is treating the message as anonymous.
If the alias path sends From: <sender@email.brandname.com> with no display name, fix that identity or route. If the expected display name appears in the raw header, return to recipient contacts and client behavior.
Provider and app behavior to expect
Mailbox providers do not all expose identity in the same way. A visible label can come from the From header, a saved contact, cached thread state, or a corporate directory. The address can appear beside the name or replace it, so compare the raw message with the exact view the recipient used.
|
|
|
|---|---|---|
Gmail | From header and contact history | First-time and known sender |
Yahoo | Header and interface view | Inbox row and opened message |
Outlook | Header, contact, or directory | External and tenant recipients |
Apple Mail | Header, contacts, and Smart Addresses | Contact state and Viewing settings |
Smaller webmail | Header parsing and fallback | Raw source and visible label |
Useful comparisons by mailbox environment.
In Apple Mail on Mac, check Mail > Settings > Viewing > Use Smart Addresses when the address appears beside the name. Apple's Smart Addresses guidance explains how this view uses contact and directory information. This setting changes the displayed address details; it does not add a missing name to the received From header.
If the issue is specifically in Gmail, there are separate Gmail-specific sender-name quirks worth checking. The related guide on Gmail friendly names covers those cases in more detail.
Gmail message header showing a friendly sender name, sender email address, and details dropdown.
What to fix when it is your setup
If the headers show that your sending system really sent the address as the display name, fix the sender profile first. In marketing and transactional tools, the friendly name and the sender address are usually separate fields. A bad merge variable, copied sender profile, or integration mapping can fill both fields with the address.
Do not change authentication records blindly
Changing SPF, DKIM, or DMARC because one recipient sees an email address can create a real deliverability problem. Confirm whether the display name is missing from the raw message before editing DNS.
Then check the exact sender identity used by the triggered campaign. Triggered journeys often run through a different profile, business unit, subdomain, IP pool, or template path than regular campaigns. That difference explains why the complaint can appear sudden even when nobody intentionally changed the main campaign sender.
- Sender profile: Confirm the friendly name field contains BrandName and the address field contains the mailbox address.
- Template logic: Check that a personalization token is not writing an address into the display name.
- Header encoding: Let the sending library handle display-name quoting and character encoding, especially for commas and non-ASCII characters.
- Subdomain match: Make sure the visible From domain matches the domain you expect to authenticate.
- Reputation signals: Investigate blocklist (blacklist) status when delivery errors or spam placement also affect this sender.
For names containing accents or other non-ASCII characters, let the sending library generate valid headers. RFC 2047 encoded-word text in raw source is normal when it decodes correctly. For commercial or bulk mail to Gmail, keep the name stable and accurate. Do not put subject content, the recipient's name, reply-like text, or decorative characters in the display name, as explained in Gmail's sender guidelines. Incorrect quoting or encoding can prevent a client from displaying the name correctly; a long name can simply be truncated.
If the message also has spam-folder placement, warning banners, or inconsistent authentication, widen the investigation. Sender-name display is then only one symptom. Suped's DMARC monitoring can track authentication domain matches, identify unrecognized sending sources, and show which sources need investigation.
Where to change the sender display name
If the received From header is missing the name or contains the wrong name, edit the setting used by the exact sending account. A profile name or an account label is not always the outgoing sender name.
- For Gmail on a computer, open Settings > See all settings > Accounts and Import (or Accounts) > Send mail as > Edit info. Change the name for the sending address and save it. Google's instructions distinguish this name from the Google Account profile name; the Gmail mobile app cannot change it.
- For an editable non-Exchange account in classic Outlook for Windows, open File > Account Settings > Account Settings, select the account, choose Change, and edit Your name. Follow Microsoft's classic Outlook instructions for that account type.
- For Microsoft 365 or Exchange accounts managed by an organization, ask the administrator to update the mailbox display name. A local Outlook profile edit does not override the organization-managed name.
- For a sending integration or campaign, edit the From name on the exact sender profile or alias used by that message. Check the resulting header rather than relying on the account profile screen.
After saving a change, send a new message with a new subject through the same route and inspect its received From header. A sender-side name change does not rewrite headers in messages already delivered. If only one recipient still sees the old label, check their contacts and directory data before changing the sender again.
Check related authentication issues with Suped
Suped is our DMARC reporting and email authentication platform. For a sender-name complaint, use Suped to check whether the same sending source also has authentication failures. Recipient screenshots and received headers are still needed to explain the displayed label.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Confirm the received From header, then use Suped's DMARC reports to compare sending sources and SPF or DKIM domain matches across reporting providers when authentication symptoms also appear. These reports show authentication patterns, not the recipient's saved contact name or inbox label.
- Compare sending sources that pass or fail DMARC with your authorized sender inventory before deciding which source needs a configuration change.
- Use blocklist (blacklist) monitoring for monitored IPs or domains when sender-name complaints accompany delivery errors or spam placement.
A practical response to the recipient
When a customer reports this, avoid telling them it is impossible or blaming their mailbox. A better response is specific: say you are checking the exact message headers and the receiving app behavior, then ask for the evidence needed to reproduce it.
Customer reply templatetext
Thanks for flagging this. We are checking why your mailbox displayed our email address instead of our sender name. Could you send us a screenshot of the inbox row and the opened message, plus the email app and device you used? If your email app has a "show original" or "view source" option, the full headers will also help us confirm whether the sender name was included when the message arrived.
That wording keeps the investigation factual. It also avoids promising that the sender can control every recipient's inbox display. Once you have the headers, you can say whether the friendly name was present in the message or whether the sending profile needs correction.
How much evidence is enough?
Use the level of evidence to decide whether to change sender settings or keep investigating.
Low confidence
Do not change DNS
One screenshot and no headers
Medium confidence
Check contacts and app
Valid From header; one client differs
High confidence
Compare sender and received source
Missing or malformed name in received From header
Views from the trenches
Best practices
Collect screenshots, full headers, app name, and version before making sender changes.
Compare the same email in a fresh mailbox to separate rendering from sender setup.
Investigate authentication when warnings or delivery problems accompany the sender-name complaint.
Common pitfalls
Changing DMARC records too early can create a real issue from a display-only complaint.
An inline forward can omit original headers; request full source or the attached original file.
Ignoring contact overrides misses one of the most common causes of odd sender labels.
Expert tips
Treat one-recipient reports as evidence requests, not proof of a global campaign fault.
Keep triggered campaign sender profiles separate and documented for faster comparison.
Use a stable brand name and confirm every alias writes the expected From header before sending.
Marketer view
Marketer from Email Geeks says sender-name complaints need screenshots, full headers, and the email client version before anyone can isolate the cause.
2019-09-09 - Email Geeks
Marketer view
Marketer from Email Geeks says a single provider showing the address usually points to mailbox-client behavior rather than a sending-system change.
2019-09-09 - Email Geeks
