Salesforce has three main ways to send email: Salesforce outbound mail servers (Option 1), an SMTP email relay (Option 2), or OAuth mailbox sending through Microsoft 365 or Gmail (Option 3). This guide explains when to use each option, how email logging and security policies differ, and what the 2026 Salesforce domain verification deadlines mean for your org.
Use this quick rule of thumb to identify which option you’re using today. If Salesforce automation sends the email, you’re usually in Option 1. If IT requires centralized inspection and journaling, you’re usually in Option 2. If users send 1:1 emails to customers, you’re usually in Option 3.
Send emails directly from Salesforce using Salesforce’s own mail servers. Salesforce creates the message and delivers it through its outbound email infrastructure. No external mail system is involved, and you do not need to connect Salesforce to Microsoft 365, Exchange, Gmail, or any other SMTP server.
In this model, Salesforce is the sending infrastructure, which is why domain verification requirements are most relevant to Option 1.
You can send emails from Salesforce, but have them delivered through your company’s email relay. Salesforce creates the message, then hands it off to your SMTP relay server, which forwards it through your mail system and applies your standard controls before delivery.
Salesforce still generates the email content, but it does not send the email directly to the recipient. Instead, Salesforce connects to your company’s relay server using SMTP and passes the message into your mail infrastructure (for example, Microsoft 365 Exchange or Gmail).
From there, the relay server enforces your organization’s policies, such as security scanning, archiving, and logging, and then sends the email to the recipient.
This option can improve compliance controls, but deliverability still depends on your relay configuration and sender authentication (SPF, DKIM, DMARC) being correctly aligned.
You can write emails in Salesforce, but send them through your user’s Microsoft 365 or Gmail mailbox. Salesforce connects to the user’s mailbox using OAuth, then delivers the message using that mailbox’s mail server instead of Salesforce’s email infrastructure.
The email is composed in Salesforce, but it's sent from the user’s personal account in Microsoft 365 Exchange or Gmail.
As a result, the message travels through the user’s mailbox server for delivery, not through Salesforce’s outbound email systems.
Because these emails originate from the user’s mailbox, this approach often aligns best with deliverability expectations and "Sent Items" visibility.
Now that you know the three sending paths, here’s the policy change that affects how Salesforce treats sender domains.
Within the next few months, every Salesforce org needs to complete domain verification. Production orgs must verify by April 27, 2026, and sandboxes must verify by March 30, 2026. For the full rollout schedule, refer to the Salesforce Help article.
This requirement applies to anyone using Option 1 (sending email directly through Salesforce mail servers). A common example is automation, like an alert email sent to your sales team whenever a rep closes an opportunity. Because that message is generated by automation, it’s typically delivered through Salesforce’s mail servers.
Even if your users send 1:1 emails via Option 3, many orgs still rely on Option 1 for automation.
Starting March 9, 2026, Salesforce requires domain ownership verification for sending email. Any domain used as a "from" address in Salesforce must be verified. This change does not affect emails sent through Gmail or Microsoft 365 (Outlook) integrations or via Salesforce Einstein Activity Capture (EAC) (Options 2 and 3).
There are 2 options for verifying your email-sending domains.
Although both options satisfy the domain verification requirements, DKIM is typically the recommended path because it will digitally sign outgoing email, help improve inbox placement or sender reputation, and protect the message’s integrity during transit.
If you’re emailing prospects or customers from Salesforce, Option 3 typically improves deliverability, keeps messages visible in both Salesforce and the mailbox, and ensures your company policies apply.
At Concept, we usually recommend Option 3 (sending Salesforce emails through your Microsoft 365 Exchange or Gmail server) when connecting email to Salesforce, but the right choice can vary based on your requirements and use case.
If most email is automated or IT requires all outbound to be relayed and journaled centrally, Option 1 or Option 2 may be a better fit.
Salesforce provides a detailed setup guide (linked here), but below are the high-level steps.
Salesforce email can be simple once you separate how the message is sent from how the sender domain is secured. Start by identifying which option you rely on most (automation and system alerts typically map to Option 1, while user-to-customer emails usually map to Option 3, and compliance-heavy environments often require Option 2). Then confirm your domain verification approach (DKIM is usually the strongest long-term choice) and complete verification ahead of the 2026 deadlines, so outbound mail is not interrupted.
For Salesforce help, reach out to Concept.