Organization-Wide Address
An Organization-Wide Address (often called an Org-Wide Email Address) is a shared, verified email address that Salesforce users can pick as the From address on outbound email instead of their own personal address.
Definition
An Organization-Wide Address (often called an Org-Wide Email Address) is a shared, verified email address that Salesforce users can pick as the From address on outbound email instead of their own personal address. Typical examples are support@yourcompany.com, billing@yourcompany.com, or noreply@yourcompany.com. Each address has a friendly Display Name, a Purpose, and a list of profiles allowed to use it. Salesforce confirms ownership through a verification email before the address can send anything.
The point is consistency. When several reps email customers, you usually want those messages to look like they come from one branded mailbox, not from a dozen individual logins. A support agent replying to a Case can send as support@, while a finance user sends invoices as billing@. Nobody has to share the password to the real mailbox, and recipients see a sender they recognize. Org-Wide Addresses are set up once in Email administration and then reused across the email composer, Apex, email alerts, and Flow.
How Org-Wide Addresses route outbound mail
User Selection versus Special Purpose
Every Org-Wide Address has a Purpose, and the choice changes where the address shows up. A User Selection address appears in the From dropdown when a user composes an email, so people can deliberately send as support@ or sales@ instead of their own login. A Special Purpose address does the opposite. It does not appear in any user-facing dropdown and is reserved for system mail and the default no-reply behavior. You can also pick the combined option, which lets an address serve both roles at once. The split matters because not every shared mailbox should be selectable by hand. A noreply@ address, for instance, exists so automated messages stop coming from individual users, but you rarely want a rep choosing it for a personal reply. Setting the Purpose correctly keeps the From dropdown short and relevant for end users while still letting administrators route background email through a branded address. When you design your sender strategy, decide the Purpose for each address first, then worry about which profiles get access.
The verification handshake
Adding an address does not make it usable right away. Salesforce sends a verification email to the exact address you entered, and someone has to open that message and click the confirmation link. Until that happens, the address stays unverified and will not appear as a From option or send through Apex. This handshake is a guardrail. It stops anyone from configuring an address they do not actually control, which would otherwise be an easy way to spoof a partner or a customer domain. The practical consequence is that the mailbox needs to exist and be monitored before you add it in Setup. If you create support@yourcompany.com in Salesforce but nobody has set up that inbox on your mail server, the verification link never arrives and the address sits idle. A common pattern is to stand up the real mailbox or a catch-all rule first, add the Org-Wide Address second, then confirm from the inbox. If the verification email goes missing, you can resend it from the address detail page.
Profile-level access control
Each User Selection address carries a setting that decides who can send as it. You can allow all profiles, which puts the address in everyone's From dropdown, or you can restrict it to a chosen set of profiles. Restriction is the safer default for sensitive mailboxes. You probably want billing@ available only to the finance team and support@ available only to service agents, so a salesperson cannot accidentally send a quote as the billing department. Allowing all profiles is fine for a generic company address like hello@ that any employee might reasonably use. This control lives entirely inside Salesforce and has nothing to do with mailbox permissions on your mail server. A user who is allowed to select an Org-Wide Address never sees the real account credentials. They simply get the address as a From choice. When you audit your org, line up each address against the teams that should own it, because access tends to drift as profiles are cloned and reorganized over the years.
Where the address can be used
Org-Wide Addresses show up in more than the email composer. In Apex, a Messaging.SingleEmailMessage accepts the address through setOrgWideEmailAddressId, which takes the record Id of the OrgWideEmailAddress object. Developers usually query that Id by Address rather than hard-coding it, so the same code works across sandboxes and production. Email alerts, the action that classic workflow rules and record-triggered Flows fire, let you choose an Org-Wide Address as the From value directly in the alert definition. That is often the cleanest place to centralize a sender, because an alert without an Org-Wide Address defaults to whichever user triggered it. Flow Send Email actions can reference an address too. The shared thread across all of these is that the From address becomes a deliberate configuration choice rather than an accident of whoever happened to click the button. One caution worth remembering: some features such as mass email and certain list email paths do not honor Org-Wide Addresses, so test the specific send path you care about instead of assuming every channel respects it.
Reply-To and the no-reply pattern
The From address is what a recipient sees, but it is not always where you want replies to land. Many mailflows pair a sending identity with a separate reply destination. A classic case is automated billing mail that goes out as noreply@ so customers know not to respond to a machine, while a Reply-To header points anyone who does reply toward a monitored inbox like billing-support@. Salesforce supports a default no-reply address through the Special Purpose option, and you can only have one verified no-reply address active at a time. After you create a no-reply Org-Wide Address you cannot delete it, so choose the address text carefully before you confirm it. This pattern keeps system-generated email from piling up unread in an unwatched mailbox. It also sets clearer expectations for customers, who quickly learn that a no-reply sender is informational and that real conversations happen through a different channel you have actually staffed.
Deliverability, SPF, and DKIM
An Org-Wide Address only solves the From label. Whether the message actually reaches an inbox depends on email authentication for the sending domain. Because the mail leaves Salesforce servers but claims to come from yourcompany.com, receiving systems run checks to decide if that claim is legitimate. SPF records list which servers may send for your domain, and DKIM signs the message with a key tied to your domain so it cannot be quietly altered in transit. Salesforce can generate a DKIM key for you to publish in DNS. On top of that, a DMARC policy tells receivers what to do when authentication fails, and a strict policy will reject or quarantine mail that is not properly aligned. If you skip this setup, your branded support@ messages may land in spam or bounce outright, which is worse than sending from a plain user address. Treat DNS configuration as part of rolling out Org-Wide Addresses, not an afterthought, and verify alignment with a few test sends before you announce the new sender internally.
Ongoing maintenance
Verified Org-Wide Addresses do not expire on a timer, but they can quietly break. If the underlying mailbox is decommissioned, if the domain changes hands, or if DNS records are edited during an unrelated migration, an address that worked for years can start bouncing. Build a light review into your admin routine. Confirm each address still maps to a live, monitored inbox, and check that its allowed profiles still match the teams that should own it. Watching bounce activity per sender helps too, since a sudden rise usually points at a mailbox or DNS problem rather than bad recipient lists. Keep the total list lean. Every address you stop using is one more thing to audit and one more potential spoofing target, so retire the ones that no longer serve a purpose. When you add new addresses, document who requested them and why, because a year later nobody remembers what whatsnew@ was for, and an undocumented sender is the first thing a security review will flag.
Set up an Organization-Wide Email Address
Create an Org-Wide Address in Setup so chosen users (or system processes) can send branded outbound email. You need the Manage Email Administration permission and access to the target mailbox to confirm the verification link.
- Open Organization-Wide Addresses
In Setup, use Quick Find to open Organization-Wide Addresses under Email administration, then click Add.
- Enter the display name and address
Type a friendly Display Name (what recipients see) and the exact Email Address you want to send from, such as support@yourcompany.com.
- Choose the Purpose
Pick User Selection so the address appears in the From dropdown, Special Purpose for no-reply or system mail, or the combined option to do both.
- Scope the profiles
For a User Selection address, allow all profiles or restrict it to the specific profiles that should be able to send as this address.
- Verify from the inbox
Save, then open the verification email Salesforce sends to the address and click the confirmation link to activate it.
The friendly sender name recipients see next to the address (for example, Acme Support).
The actual address mail will appear to come from; it must be a real, monitored mailbox to receive the verification link.
Whether the address is selectable by users, reserved for special or no-reply use, or both.
For User Selection, either all profiles or a chosen subset that may send as this address.
- The address stays unusable until someone clicks the verification link sent to the inbox, so set up the mailbox before adding it in Setup.
- You can have only one verified default no-reply address, and once created a no-reply address cannot be deleted.
- Some features such as mass email and certain list email paths ignore Org-Wide Addresses, so test the exact send path you intend to use.
- Without SPF and DKIM configured for the sending domain, branded sends may be marked as spam or rejected by recipient servers.
Prefer this walkthrough as its own page? How to Organization-Wide Address in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Organization-Wide Address.
- OrgWideEmailAddress Object ReferenceSalesforce
- Set Up a Default No-Reply Email AddressSalesforce
Hands-on resources to go deeper on Organization-Wide Address.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Organization-Wide Address used for?
Q2. What must happen before an Organization-Wide Address becomes available to send from?
Q3. How is access to an Organization-Wide Address controlled?
Discussion
Loading discussion…