Yes — Salesforce can send email from a shared mailbox (like support@ or info@yourcompany.com) using an organization-wide email address. An admin creates the address in Setup, verifies it by clicking a link sent to that mailbox, and chooses which profiles or permission sets can send from it. Two prerequisites trip teams up: the email domain should be verified with Salesforce (via DKIM or an authorized sending domain), and someone must actually receive and click the address verification email — a shared mailbox nobody monitors will stall setup. Know the limits too: org-wide addresses can't be used for mass emails, mail merge, meeting requests, or scheduled reports, and an address can't be deleted while an email alert uses it. This matters for portals, case notifications, and any team that wants customer-facing email to come from a durable team address instead of a person.
It's a shared From address — typically a shared mailbox like sales@ or support@ — that authorized users and automations can send from instead of their personal address. Replies go to the org-wide address, so the shared mailbox becomes the single intake point. Admins create and manage these addresses in Setup under Organization-Wide Addresses, and control access per address: specific profiles, specific permission sets, or all profiles.
Each address also has a purpose. Most are "User Selection" addresses that appear in the sender dropdown for the people you've granted access. One special-purpose address can be designated the Default No-Reply address for system-generated email — and only one verified No-Reply address can be active at a time.
| Consideration | Individual user address | Shared mailbox (org-wide address) |
|---|---|---|
| Continuity | Breaks when the person leaves or changes roles | Survives staffing changes — the address outlives any employee |
| Reply handling | Replies land in one person's inbox | Replies land in a monitored team mailbox |
| Best for | Personal outreach — a rep's one-to-one emails | Portals, case and form notifications, system alerts, team inboxes |
| Recipient trust | Feels personal; recognizably from a human | Feels official; consistent branding for automated mail |
| Setup burden | None — every user has an address | Domain verification plus per-address verification |
The common pattern is both: reps send one-to-one mail from their own addresses, while anything automated, portal-generated, or team-owned sends from org-wide addresses. Name each org-wide address for its purpose — Salesforce's own guidance recommends purpose-specific naming, because it makes permissions and downstream behavior easier to reason about.
The verification step is where shared-mailbox setups stall. The verification email goes to the mailbox itself, and if that mailbox is a distribution group nobody can log into, a shared inbox buried under rules that file or delete automated mail, or an address that can't receive external email, the link never gets clicked and the address never activates. Before creating the address, confirm the mailbox can receive external mail and that a specific person is responsible for watching it during setup. A user's own mailbox never has this problem — which is why teams sometimes verify successfully with a personal address and then wonder why the shared one is "broken."
Also note the precedence quirk for Outlook and Gmail integrations: if a user's connected account address matches an org-wide address, the org-wide address takes precedence in the From dropdown. Usually desirable — occasionally surprising.
Inventory where customer-facing email originates: user inboxes, workflow alerts, flows, case notifications, portals. Anything automated or team-owned should move to a purpose-named, verified org-wide address with access limited to the profiles that need it. Verify domains with DKIM as a deliverability baseline, assign a named owner to each shared mailbox (for verification links and reply monitoring), and document which alerts use which address so future cleanup isn't blocked. Revisit the list quarterly — org-wide addresses accumulate the same way profiles do.
Vantage Point designs Salesforce email architecture — org-wide addresses, domain verification, deliverability, and the automation that sends — as part of Salesforce implementations. Where DKIM, sender authentication, and mail-flow policy intersect with security requirements, compliance and security engagements cover that ground, and managed services keep the configuration governed as teams and tools change.
Vantage Point is a Salesforce and HubSpot Solutions Partner and is employee-owned. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Yes. Create an organization-wide email address for the shared mailbox in Setup, verify the domain and the address, and grant access to the profiles or permission sets that should send from it. Recipients see the shared address as the sender, and replies are delivered to that mailbox.
Usually because the shared mailbox can't receive external email, mail-flow rules filed or quarantined it, or nobody is monitoring that inbox. Confirm the mailbox accepts outside mail, check junk and quarantine folders, and resend the verification from Setup — a person must click the link before the address can send.
No. Access is granted per address to specific profiles or permission sets, unless you enable "Allow All Profiles to Use this From Address." Limit broad access deliberately — an all-profiles address can override restrictions set by individual features such as Email-to-Case.
No. Salesforce excludes org-wide addresses from mail merge, mass emails, meeting requests to contacts and leads, scheduled reports, and scheduled dashboard refreshes. They work for one-to-one sends, email alerts, flows, and similar targeted sending.
It's a single org-wide address designated for system email that shouldn't accept replies — for example, automated notifications. Only one verified No-Reply address can be active at a time; verifying a new one replaces the old, and the active No-Reply address can't be deleted.
If an email alert references the address, Salesforce blocks deletion and edits until the alert is repointed. Check workflow email alerts, flow email actions, and case notifications for references, move them to the replacement address, and then delete.