Why is the From Email Address showing instead of From Name in SFMC?
Updated on 15 Oct 2026: We clarified SFMC sender-name fixes, Marketing Cloud Next test behavior, and the User Domain verification requirements now in effect.
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.
Why recipients see the email address
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 expected display name and address, the inbox received the friendly name.
- 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. For an authenticated subdomain, use a static From address and personalize the display name. Marketing Cloud Next does not transform a root-domain address into a subdomain address at send time; use a complete address on an authenticated domain for dynamic sending. See Salesforce's dynamic sender troubleshooting.
Marketing Cloud Next tests use fallback addresses
If the screen has Sender Profiles and Send Classifications, follow the Engagement checks below. For Marketing Cloud Next, Salesforce states that test emails and Flow debug use fallback addresses. Verify resolved dynamic From and Reply-To addresses with a controlled live send to a mailbox you own. If the live send still uses the fallback, check the source data, authenticated From domain, and authorized Reply-To domain.
How to check the real header
The fastest way to separate an SFMC configuration issue from an inbox display issue is to send a controlled live email through the same send definition or journey 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 on Mac, use View > Message > All Headers, or save the email as Raw Message Source to inspect the original message. 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@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: DMARC passes when at least one passing SPF or DKIM result has a domain that matches the visible From domain under the applicable DMARC rules. Both mechanisms do not need to pass.
- 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, the inbox received the name. If the header has only mail@example.com, the friendly From Name is absent from the delivered message.
|
|
|
|---|---|---|
Name present | Client display | Test more inboxes |
Name missing | Sender setup or header rewriting | Check SFMC and the delivery route |
SPF fail | Envelope sender | Check sending route |
DKIM fail | Signing issue | Verify signature and key |
DMARC fail | No passing SPF or DKIM result with the required domain match | Check authentication results and domain matching |
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 display name usually calls for an SFMC review, but a forwarding service or gateway can also rewrite the From header. Compare a direct delivery with the affected route before assigning the cause. 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. Also check any "Override sender profile" selection on the actual send interaction.
- 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.
User Domain verification changed on October 4
Salesforce ended support on October 4, 2026 for creating From Addresses through verification emails for affected User Domains created on or after February 1, 2026 that are not verified for the account. Existing From Addresses require no action. New addresses must use a Verified Domain established through a Sender Authentication Package, Private Domain, or Registered Domain. See Salesforce's User Domain retirement notice.
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.
For dynamic sender names, put the lookup and fallback logic in the Sender Profile field or in a content block that the field calls. Salesforce documents this content block approach. Do not rely on an AMPscript variable set only in the email body: the Sender Profile is processed before the body, as the dynamic sender profile example illustrates.
How to change the sender name in SFMC
In Marketing Cloud Engagement, edit the From Name under Sender Information. The profile Name under Properties is an internal label. Reply-To Name and Reply-To Address control reply information, not the original message's From Name.
- Open Marketing Cloud Engagement Setup. Enter "profiles" in Quick Find, select Sender Profiles, and open the profile used by the affected send in the correct Business Unit.
- Under Sender Information, choose "Use the specified information" for a fixed sender. Enter the display name in From Name and a verified address in From Email.
- Save the profile. Confirm its Send Classification and any sender-profile override on the actual email interaction.
- Send a controlled live message through the affected send path to an address without a saved contact. Check the delivered From header before comparing inbox labels.
Salesforce's Sender Profile instructions also cover personalization strings when the display name must vary by subscriber.
Authentication is a separate check
A From Name display issue alone does not establish an SPF, DKIM, or DMARC failure. 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 or Business Units, Suped groups DMARC reports by sending source. Use those reports to investigate unexpected senders or recurring authentication failures while testing display names in actual inboxes.
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 of how an email app displays the From Name or From Email Address.
Outlook and Exchange environments also use directory resolution. Microsoft's addresses replace names article concerns mail sent from on-premises Exchange to Exchange Online in a misconfigured hybrid deployment. Its connector and routing fix applies to that scenario, rather than ordinary external SFMC campaigns. For an SFMC message, inspect the delivered From header and any intervening gateway before changing Exchange settings.
Fix sender settings and test inbox display
If the raw header is missing the From Name, check SFMC and the delivery route 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 the From display name and address with those in a directly delivered copy at another provider. Matching From values with different visible labels point to client rendering. Different From values call for a review of send definitions, dynamic data, or gateway rewriting. Compare the From fields, since Received headers and Message-ID values normally differ between deliveries.
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 every delivered From header contains the expected name and address but inbox labels differ, document the behavior as client rendering. If a From value is missing or differs, trace that delivery through its SFMC send definition, data source, and any gateway. Investigate authentication failures separately because they affect delivery and domain protection.
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 view
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 view
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
