Why is the From Email Address showing instead of From Name in SFMC?
Updated on 7 Aug 2026: We updated this guide to separate Marketing Cloud Engagement from Marketing Cloud Next and clarify what authentication can and cannot change.
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 does not apply 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 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 received the friendly name and decided how to render it.
This is not an authentication failure by itself. SPF, DKIM, and DMARC do not control whether an inbox shows the friendly name. Failed authentication, domain mismatch, or a blocklist (blacklist) reputation problem still requires a separate deliverability review.
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. Clients can use local contacts, corporate directories, cached identities, or their own interface rules when choosing the label to show. A saved contact gives the app a local name source, 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 failing: Treat this as a separate deliverability and domain-protection issue, not proof of the display-name cause.
- Contact saved: If saving the address fixes the display, the receiving client is using its address book as a name source.
Quick diagnosis
Do not diagnose this from the inbox list view alone. Open the full message source and inspect the actual From: header. Review authentication separately so a display issue does not hide a broader sending problem.
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. In Marketing Cloud Engagement, 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 creates 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 falls back to another configured value.
- 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.
- Cached identity: The app reuses a name or address learned from earlier messages.
- 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.
Marketing Cloud Engagement and Marketing Cloud Next differ
Most SFMC Sender Profile questions refer to Marketing Cloud Engagement. Marketing Cloud Next has a different dynamic From and reply workflow, so instructions for one product should not be applied to the other. Engagement uses Sender Profiles, Send Classifications, and From Address Management. Marketing Cloud Next resolves sender data through CRM or Data 360 fields configured in the campaign flow.
|
|
|
|---|---|---|
Marketing Cloud Engagement | Sender Profile and Send Classification | Verified and sendable From domain or address |
Marketing Cloud Next | Static or dynamic From and reply values | Authenticated From domain and authorized direct-reply domain |
Use the configuration path for the Salesforce product that sends the message.
In Marketing Cloud Next, a dynamic From Address can resolve a display name and email address from an associated user or custom field. The From domain must be authenticated. A direct dynamic Reply-To domain must be listed as an Authorized Email Domain, while Reply Mail Management uses its managed reply route. Configure fallback values so missing contact or owner data does not leave the campaign without a usable sender or reply address.
Check the product name first
If the screen has Sender Profiles and Send Classifications, follow the Engagement checks below. If it has dynamic sender options in a Marketing Cloud Next flow, inspect the resolved data, domain status, and fallback values instead.
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. This gives the team a technical readout instead of relying on a forwarded screenshot.
Header values to inspecttext
From: "Acme Support" <support@example.com> Return-Path: <bounce.mail.example.com> Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.mail.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
- 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 and DKIM results, then confirm the visible From domain passes DMARC.
- 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 shows a results button when the test is ready.
?/43tests passed
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 supplied the name. If the header has only mail@example.com, the friendly From Name was not applied at send time.
|
|
|
|---|---|---|
Name present | Client display | Test more inboxes |
Name missing | SFMC setup | Fix profile |
SPF fail | Envelope sender | Check sending route |
DKIM fail | Signing issue | Verify signature and key |
DMARC fail | Domain mismatch | Fix the matching domain |
Use this table after checking the raw message header.
A correct header does not force the inbox to show the name. Mailbox interfaces can use contact lists, previous interactions, directory entries, cached identities, and local app settings. Some interfaces show the friendly name in the message view but the email address in the list view.
A missing header value does point back to SFMC. Check the exact send path instead of 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 contains the expected display name and address.
Needs sender setup review
Warning
Header has no friendly name or dynamic sender values are inconsistent.
Separate authentication fault
Critical
Authentication fails even though the From display-name finding is known.
SFMC settings to verify
Start in Marketing Cloud Engagement 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 an address whose domain is verified and whose status is sendable for the account.
- Send Classification: Confirm the commercial or transactional classification points to the right Sender Profile.
- From Address Management: Check the exact address or verified domain in Setup, including its status and Business Unit availability.
- Dynamic sender data: Check every subscriber row has a clean value and that the fallback name and address are usable.
- API payloads: Confirm send definitions or triggered send calls do not override the intended sender.
Plan for the User Domain change
Salesforce ends support on October 4, 2026 for creating From Addresses through User Domain email verification when those User Domains were created on or after February 1, 2026. Existing From Addresses remain available. New addresses should use a domain verified through a Sender Authentication Package, Private Domain, or Registered Domain.
Dynamic sender names need fallbacks
If a dynamic From Name pulls from subscriber data, blank values can produce inconsistent output or invoke the configured fallback. Use a default brand sender name when the field is empty, too long, or contains characters that do not belong in a mail header.
Dynamic sender setups can look correct while the send uses an unexpected value. Salesforce community discussions about dynamic sender profiles show how differences in send context change the output.
Authentication is a separate check
A From Name display issue is not an SPF, DKIM, or DMARC issue. Passing authentication does not force an inbox to show the friendly name, and failing authentication does not remove a correctly formed display name from the raw From header. Authentication still matters for delivery, spoofing protection, and accurate diagnosis.
In SFMC, plan the visible From domain, bounce domain, and DKIM signing domain as one sending setup. Use a branded domain authenticated for SFMC, sign with DKIM using a domain that satisfies DMARC for the visible From domain, and monitor DMARC before moving toward enforcement. Suped's DMARC monitoring shows which sources send as your domain and which sources pass or fail DMARC domain matching.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
For a DNS-level review, run the sending domain through Suped's domain health checker. It checks DMARC, SPF, and DKIM signals so you can separate authentication faults from the inbox display question.
?
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 client accounts, Suped groups DMARC results, SPF and DKIM health, hosted policy records, blocklist monitoring, alerts, and MSP views. This helps the team trace an authentication failure to its sending source without treating that failure as the cause of a client-side name choice.
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. The app can then 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 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 another has no contact saved, so the inbox shows support@example.com. Corporate directories and contact sync 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 behaviors. 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 confirms 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, check contacts, directories, cached identities, and client-specific rendering. You cannot force every inbox to render the friendly From Name, but consistent sender settings make the behavior easier to test and explain.
- 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.
- Keep authentication healthy: Check DKIM and DMARC as separate delivery and domain-protection controls.
- 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 and verified From Email Address, a valid DKIM signature, passing DMARC, and a working reply address. This creates a sender identity that can be checked consistently across clients.
If the issue appears only for one mailbox provider, compare that provider's raw header against another inbox. Identical headers point to a rendering decision. Different headers point to separate 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. Check journey branches, API-triggered sends, old triggered send definitions, and data extension rows that carry different sender values.
|
|
|
|---|---|---|
Blank data | Fallback or wrong name | Add fallback |
Old trigger | Wrong sender | Update definition |
Contact cache | Mixed names | Compare clients |
Authentication fail | Separate delivery risk | Investigate authentication |
Unverified address | Send blocked | Verify domain or address |
These edge cases cause inconsistent sender display.
Changing the From Name shortly before a major send also makes comparisons harder and can confuse recipients. If you need to change the name, run a controlled test, keep the sending domain stable, and watch replies, complaints, DMARC results, and blocklist (blacklist) signals.
For an explanation of sender identity terms, the related page on email From terms helps when SFMC users mix up Header From, Envelope From, Reply-To, and Sender Profile fields.
Practical troubleshooting order
The cleanest troubleshooting order is raw header first, the actual SFMC send configuration second, and client comparison next. Review authentication in parallel as a separate delivery and domain-protection check. This prevents circular debates about whether a mailbox provider should have shown the name.
A useful test includes a Gmail account, a Microsoft mailbox, an Apple Mail view, and a 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 before comparing the visual inbox display, then review authentication results separately.
If all From headers match, 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 it because it affects delivery and domain protection even though it does not control the friendly 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.
Treating an authentication failure as the direct cause of a missing display name.
Changing From Names frequently makes later 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 behavior, not an 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 a contact, directory entry, cached identity, or interface rule supplies the visible label.
Keep the From Name and sender address stable, and verify the address in Marketing Cloud Engagement. Check DKIM and DMARC as separate controls. Suped helps teams monitor DMARC domain matching, SPF and DKIM health, and blocklist (blacklist) signals while they use raw headers and SFMC settings to diagnose the display issue.
