Why is the From Email Address showing instead of From Name in SFMC?
Michael Ko
Co-founder & CEO, Suped
Published 13 Jul 2025
Updated 28 May 2026
13 min read
Summarize with
The From email address shows instead of the From Name in SFMC when the receiving email app chooses to display the address, when the message header does not contain the friendly display name correctly, or when an SFMC Sender Profile, Send Classification, or dynamic sender setup is not applying the expected value. If saving the address in the recipient address book makes the From Name appear, that strongly points to recipient-side display behavior rather than a broken SFMC configuration.
The first thing I check is the raw message header. SFMC can show the correct From Name in the Sender Profile, but the only version that matters to Gmail, Outlook, Apple Mail, Yahoo, and corporate gateways is the actual From: header delivered with the message. If that header includes both a display name and an email address, the inbox provider has received the friendly name and has decided how to render it.
This is usually not a deliverability failure by itself. It becomes a deliverability and trust problem when the display issue sits alongside failed SPF, failed DKIM, DMARC domain mismatch, a recently changed sender identity, or a blocklist (blacklist) reputation problem. That is where a full sender identity check matters more than staring at the SFMC Sender Profile screen.
The direct answer
If your SFMC Sender Profile has the correct From Name but recipients see the email address until they save the contact, the most likely cause is the recipient email app. Some clients prefer the address for unknown senders, contacts with conflicting entries, suspicious-looking identities, or messages that fail trust checks. A saved contact gives the email app a local name to display, so the symptom changes without any SFMC change.
Header present: If the raw From: header contains the display name and address, SFMC supplied the sender identity.
Header missing: If the raw header only contains the address, fix the Sender Profile, Send Classification, or dynamic sender data in SFMC.
Authentication weak: If SPF, DKIM, or DMARC fails, mailbox providers have less reason to trust the friendly name.
Contact saved: If saving the address fixes the display, the receiving client is using its address book or trust model.
Quick diagnosis
Do not diagnose this from the inbox list view alone. Open the full message source and inspect the actual From: header, authentication results, and the sending domain match.
Correct friendly From headertext
From: "Acme Support" <support@example.com>
Reply-To: support@example.com
Subject: Your account update
What SFMC controls
SFMC controls the sender values it places into the message, but it does not control how every inbox renders those values. The Sender Profile sets the From Name and From Email Address. The Send Classification decides which Sender Profile and Delivery Profile apply to the send. A dynamic Sender Profile can replace values at send time with subscriber or data extension fields.
That means there are two separate questions. Did SFMC put the right sender values into the message? Did the receiving email app decide to show the friendly From Name? The fix depends on which answer fails.
SFMC-side causes
Wrong profile: The send uses a different Sender Profile than the one you checked.
Wrong classification: The Send Classification points to an unexpected sender setup.
Dynamic value blank: A personalization field resolves empty or contains only the email address.
Bad formatting: Special characters or quote issues produce a malformed header.
Recipient-side causes
Unknown sender: The client shows the address until the recipient saves the contact.
Conflicting contact: A local or directory contact overrides the email header display name.
Trust signal: The inbox interface exposes the address when it wants more sender clarity.
Client rules: Gmail, Outlook, Apple Mail, and mobile apps render names differently.
Salesforce Marketing Cloud sender profile fields for From Name and From Email Address.
How to check the real header
The fastest way to separate an SFMC configuration issue from an inbox display issue is to send a live test email to a mailbox you control, then view the original message. In Gmail, use Show original. In Outlook, view message details or message source depending on the client. In Apple Mail, use View Source. The wording changes by client, but the goal is the same: inspect the raw header.
You can also send the same email into Suped's email tester to see the rendered message, authentication results, and common sender identity issues in one place. That is useful when the inbox view looks strange but the team needs a cleaner technical readout than a forwarded screenshot.
Find From: Confirm the display name appears before the address in the raw header.
Check encoding: Look for malformed quotes, commas, or non-ASCII names encoded incorrectly.
Check authentication: Review SPF, DKIM, and DMARC results, especially the matching domain.
Compare clients: Test Gmail, Outlook, Apple Mail, and mobile inboxes before assuming SFMC is wrong.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
What the results mean
Once you have the raw header, the decision path is straightforward. If the header has "Brand Name" <mail@example.com> and the inbox still shows only the address, SFMC did its job. If the header has only mail@example.com, the friendly From Name was not applied at send time.
Finding
Likely cause
Next step
Name present
Client display
Test more inboxes
Name missing
SFMC setup
Fix profile
SPF fail
Mail From
Check DNS
DKIM fail
Signing issue
Verify key
DMARC fail
Alignment
Fix domains
Use this table after checking the raw message header.
A correct header does not force the inbox to show the name. Mailbox providers use contact lists, previous interactions, directory entries, local app settings, authentication results, and anti-abuse heuristics. Some interfaces show the friendly name in the message body view but the email address in the list view. Some show the address when the name is too similar to a protected brand or when the sender has little reputation.
A missing header value does point back to SFMC. In that case, I check the exact send path rather than only the default Sender Profile. Journey Builder, Triggered Sends, User-Initiated Sends, and API sends can use different classifications and sender values. A data extension field used for a dynamic sender name can also be empty for part of the audience.
Confidence levels after checking headers
Use these thresholds to decide whether the issue sits in SFMC or the receiving inbox.
High confidence SFMC is correct
Strong
Header has name, SPF passes, DKIM passes, and DMARC passes.
Needs sender setup review
Warning
Header has no friendly name or dynamic sender values are inconsistent.
Fix authentication first
Critical
DMARC fails or DKIM does not match the visible From domain.
SFMC settings to verify
Start in SFMC by checking the Sender Profile used by the actual send, not the profile you expected the send to use. Then check the Send Classification attached to the journey, automation, or email send definition. If the account uses Business Units, make sure you are checking the profile in the correct unit and not a similarly named profile elsewhere.
Sender Profile: Confirm the From Name is a literal brand name or a valid personalization string.
From Email Address: Use a verified sending domain that matches your SFMC sender authentication package.
Send Classification: Confirm the commercial or transactional classification points to the right Sender Profile.
Dynamic sender data: Check every subscriber row has a clean value for the sender name field.
API payloads: Confirm send definitions or triggered send calls are not overriding the intended sender.
Dynamic sender names need fallbacks
If a dynamic From Name pulls from subscriber data, blank values can produce inconsistent display behavior. Use a default brand sender name when the field is empty, too long, or contains characters that do not belong in a mail header.
There is a known pattern with dynamic sender setups where the configuration looks correct but the send uses an unexpected value. Salesforce community discussions about dynamic sender profiles are useful because they show how small differences in send context change the output.
Authentication still matters
A From Name display issue is not the same thing as an SPF, DKIM, or DMARC issue, but authentication changes how much an inbox trusts the visible identity. If the message claims to be from your brand but DKIM is missing or DMARC fails, some clients become more conservative about the sender label they show.
In SFMC, the visible From domain, the bounce domain, and the DKIM signing domain should be planned together. The common pattern is a branded sending domain authenticated for SFMC, a DKIM signature that matches the visible From domain, and DMARC monitoring turned on before moving toward enforcement. Suped's DMARC monitoring helps here because it shows which sources are sending as your domain and which ones pass or fail DMARC domain matching.
For a quick DNS-level review, run the sending domain through Suped's domain health checker. It checks DMARC, SPF, and DKIM signals so you can spot the authentication issue before blaming the inbox display layer.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For teams managing multiple brands, Business Units, or agencies, Suped is the practical place to keep this under control because it brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, alerts, and MSP views into one workflow. The useful part is not another dashboard. It is having issue detection and specific fix steps next to the source that caused the failure.
Why saved contacts change the display
When a recipient saves your sender address, the email app often treats that contact record as the display source. That means the app can show the contact name even if it previously showed only the address. This does not prove the original SFMC configuration changed. It proves the receiving app has another name source available.
This is why two recipients can see different sender labels for the same SFMC campaign. One has the sender saved as "Acme", another has it saved as "Support", and a third has no contact saved, so the inbox shows support@example.com. Corporate directories and CRM contact syncs can create the same effect inside a company.
Flowchart showing how an email app decides whether to show a sender name or address.
There are also client-specific quirks. Gmail can display different sender names based on contacts and prior conversation history. Outlook and Exchange environments can show directory names or SMTP addresses depending on how the sender resolves. Microsoft documents cases where addresses replace names in Exchange contexts, which is a reminder that the rendering layer is separate from the sender platform.
Fixes that usually work
If the raw header is missing the From Name, fix SFMC first. If the raw header is correct, focus on sender consistency and authentication. You cannot force every inbox to render the friendly From Name, but you can remove the common reasons an inbox chooses the email address instead.
Use one stable name: Keep the From Name consistent for a given sender address and message stream.
Use a branded domain: Send from a domain your recipients can associate with your organization.
Pass DKIM and DMARC: Make sure the visible From domain has matching authentication.
Avoid misleading names: Do not use a name that resembles a person, brand, or department you do not own.
Test real inboxes: Check Gmail, Outlook, Apple Mail, Yahoo, and at least one mobile app.
A good SFMC sender pattern
Use a recognizable From Name, a stable From Email Address, matching DKIM, passing DMARC, and a clean reply address. That gives inboxes a consistent identity to learn over time.
If the issue appears only for one mailbox provider, compare that provider's raw header against another inbox. If the headers are identical, it is a rendering decision. If the headers differ, look for different send routes, triggered send definitions, or audience-level personalization that changes the sender value.
Common edge cases
Some SFMC From Name problems only show up for part of the audience. That usually means the send path or data is not uniform. I look for journey branches, API-triggered sends, old triggered send definitions, and data extension rows that carry different sender values.
Edge case
Symptom
Fix
Blank data
Address only
Add fallback
Old trigger
Wrong sender
Update definition
Contact cache
Mixed names
Compare clients
Auth fail
Low trust
Fix DMARC
New domain
Address exposed
Warm identity
These edge cases cause inconsistent sender display.
Another common edge case is changing the From Name shortly before a major send. That can be legitimate, but sudden identity changes make inboxes and recipients pay closer attention. If you need to change the name, use a short test period, keep the sending domain stable, and watch replies, complaints, DMARC results, and blocklist (blacklist) signals.
For a deeper explanation of how sender identity terms differ, the related page on email From terms is useful when SFMC users are mixing up Header From, Envelope From, Reply-To, and Sender Profile fields.
Practical troubleshooting order
The cleanest troubleshooting order is header first, SFMC second, authentication third, client comparison fourth. That prevents circular debates about whether a mailbox provider should have shown the name.
Where to spend troubleshooting time
A practical split for diagnosing sender name display issues in SFMC.
Headers
SFMC setup
Authentication
Client testing
A good test includes at least one Gmail account, one Microsoft mailbox, one Apple Mail view, and one seed address not saved in any contact list. Send the same SFMC email to all of them. Save the raw headers. Compare the From header and authentication results before comparing the visual inbox display.
If all headers match and authentication passes, document the behavior as client rendering. If one path differs, trace that path back to its SFMC send definition or data source. If authentication fails, fix that first because it affects more than the From Name.
Views from the trenches
Best practices
Check the raw From header before changing SFMC sender profiles or send classifications.
Test with contacts saved and unsaved to separate address book display from send setup.
Keep sender names stable while monitoring DMARC, replies, complaints, and rendering.
Use fallback values for dynamic From Names so blank data never reaches the header.
Common pitfalls
Assuming the inbox list view proves SFMC sent the wrong sender name is unreliable.
Checking only the default Sender Profile misses journey and triggered send overrides.
Ignoring SPF, DKIM, and DMARC failures can hide a broader sender trust problem.
Changing From Names frequently makes rendering differences harder to interpret.
Expert tips
Compare identical raw headers across inboxes before treating display differences as bugs.
Preserve a known-good test send so future SFMC changes can be checked against it.
Review Business Unit context when similar Sender Profiles exist in multiple places.
Treat address-book fixes as evidence of client-side display, not SFMC repair.
Marketer from Email Geeks says send classifications should be checked because the send can use a different sender setup than the one visible in the expected Sender Profile.
2022-08-30 - Email Geeks
Marketer from Email Geeks says the raw headers should be inspected because the issue can be client display behavior, send classification setup, or authentication.
2022-08-30 - Email Geeks
The practical fix
The fix starts with proof. Check the raw From: header. If the friendly name is missing, repair the SFMC Sender Profile, Send Classification, dynamic sender fields, or API send definition. If the friendly name is present, the recipient client is choosing to show the address, often because the sender is unknown, a contact record overrides the display, or the inbox wants to expose the address for trust reasons.
The long-term answer is consistency: stable From Name, stable sender address, matching DKIM, passing DMARC, and clean monitoring. Suped helps by showing DMARC domain match status, SPF and DKIM health, blocklist monitoring, and concrete issue steps, which matters when SFMC teams need to prove whether a display issue is a configuration problem or an inbox decision.
