The short version: an org-wide email address lets mail leave Salesforce with a From address like support@yourcompany.com instead of the sending user’s own address. It has to be verified by someone who can read that mailbox, it only applies where the sender is chosen explicitly, and it does nothing for deliverability on its own. DKIM does that.
Setting one up
Setup, then Organisation-Wide Addresses. New, give it a display name and the address, then decide who may use it: all profiles, or a named list. Use the list. An address called billing@ available to every user will eventually send something odd.
There is also a special entry, the default no-reply address, used for system mail where a reply makes no sense. Setting it stops password resets and similar notifications arriving from an address that lands in somebody’s personal inbox.
Verification
Saving the address triggers a verification email to it, and the address stays in a pending state until the link is clicked. The link does expire, so an address on a shared mailbox nobody watches usually needs a second request.
Two practical points. The mailbox must genuinely exist and accept external mail, which rules out a distribution list locked to internal senders. And if your mail platform quarantines Salesforce mail, the verification message is the first thing it quarantines.
An unverified address cannot be used at all. It does not appear in the From picker, and automation pointed at it fails rather than falling back politely.
Which sender is actually used
The From address depends entirely on what sent the mail.
- Email alerts let you choose: the current user, the default workflow user, or an org-wide address. The default is the current user, which means an alert fires from whoever happened to save the record.
- The Lightning email composer shows a From picker listing the user’s own address plus every org-wide address their profile can use.
- Flow’s Send Email action has sender type and sender address inputs. Leave them blank and it sends from the running user.
- Apex uses
setOrgWideEmailAddressId(). If you set that and a sender display name, the org-wide address’s display name wins. - Email-to-Case replies go out from the routing address configured for that channel, not from an org-wide address. People lose hours in the wrong setup screen over this.
Deliverability and the sandbox trap
Setup, Deliverability, has an access level: no access, system email only, or all email. A freshly refreshed sandbox comes back restricted, so email from it silently does not send. Every org has lost a day to this at least once.
For real deliverability, the address being yours is not enough. Salesforce sends on your behalf, so receiving servers judge it on SPF and DKIM alignment. Generate a key under DKIM Keys, publish the CNAME or TXT records your DNS team needs, and activate it. Without DKIM signing on your own domain, a strict DMARC policy at the recipient will reject mail claiming to be from you.
Do not send bulk marketing mail through this path. Salesforce applies a daily single-email limit per org, and a campaign competing with transactional mail for that budget is how case notifications stop arriving on a Tuesday afternoon.
Bounces
Bounce management is a separate setting under Deliverability. With it on, Salesforce captures bounces for mail sent to leads, contacts and person accounts, stamps the bounce fields on the record, and flags that address across the app.
Two options sit alongside it. Returning bounced mail to the sender puts the bounce notice in the sending user’s inbox, which is useful for salespeople and noise for automation. The alert setting is the one that earns its keep, because it puts the bad address in front of the next person who tries to use it.
Bounces for mail sent from an org-wide address go back to that mailbox, not to the user who triggered the send. Somebody has to own that mailbox. An unread support@ inbox full of bounce notices is a data quality report nobody is reading.
Frequently asked
Can I delete an org-wide address that is in use? You can, and the email alerts pointing at it will stop behaving as configured. Search your alerts, flows and Apex for the address first.
Do replies come back to Salesforce? Only if the mailbox routes them there, through Email-to-Case or Email to Salesforce. An org-wide address is a From address, not an inbound channel.
Does the sending user’s name still appear anywhere? Not in the From header when an org-wide address is used. If the recipient should know who wrote it, put the name in the body with a merge field.
Can each business unit have its own? Yes, restricted by profile. Keep the count small enough that someone can still name the owner of each mailbox.
