If your Salesforce org sends automated emails, workflow alerts, case updates, or outbound messages through Flow or Apex, 2026 brought a change that can break delivery without much warning.
In Spring ’26, Salesforce began blocking emails sent from unverified domains. The domain is the part after the @ symbol, and Salesforce now needs that domain verified before it will send from it. This applies across production, sandboxes, and email relay setups. Hyphenx has been working with Salesforce teams on this shift, and the pattern is clear: this is bigger than a Setup checkbox. It pulls in DNS access, email authentication, automation owners, case teams, IT, and anyone responsible for customer-facing emails.
This blog breaks down what changed, why address-level verification is no longer enough, where Salesforce teams usually get caught, and how to fix your email setup before alerts, case replies, or automated messages start failing.
What Salesforce changed in Spring ’26
Before Spring ’26, Salesforce could send emails from the address assigned to a user, automation, workflow alert, flow, or Apex process. The sender’s domain did not need formal ownership verification inside Salesforce. A receiving mail server could still treat the message as suspicious, but Salesforce would attempt to send it.
Spring ’26 changed that behavior. Salesforce now blocks emails sent from unverified domains, even when the individual sender email address has already been verified. So if user@company.com is verified at the inbox level, company.com still needs domain-level verification before Salesforce can send from it.
This applies to Lightning Experience and Salesforce Classic across all editions, except Salesforce Free Suite and Database.com.
Salesforce rolled out the change in phases. From March 9, 2026, domain verification became required for new orgs, new sandboxes, scratch orgs, and any new sending domain added to an existing org. For existing domains with recent sending activity, Salesforce created temporary allowlists in late February 2026 and again around May or June 2026 to give teams more time. The grace period is narrow. If a domain was not used for sending in the past 30 days, Salesforce can block it immediately.
A few sends are outside this change. Gmail and Office 365 integrations, Einstein Activity Capture, Marketing Cloud, and public email domains like @gmail.com, @hotmail.com, and @outlook.com are exempt.
Core points to remember:
- Domain verification now controls Salesforce email delivery.
- Address verification alone is not enough.
- New orgs, sandboxes, and new sending domains must comply immediately.
- Older domains only get grace if they had recent sending history.
Why domain-level verification is different from address-level verification
This is where many Salesforce teams lose track of the change. Address-level verification proves that a person can access a specific inbox. A user clicks a confirmation link, Salesforce checks the mailbox, and that address becomes verified for that user. This worked well when the main concern was user identity, because it showed that the sender could receive mail at that address. But it did not prove that the company controls the wider domain behind the address. A verified person and a verified company domain are two separate checks.
Domain-level verification proves ownership of the sending domain itself. If Salesforce sends from priya@yourcompany.com, the org needs proof that yourcompany.com is controlled by your organization. That proof happens through DNS records, usually through DKIM or Authorized Email Domains, rather than an inbox click. This matters most with Org-Wide Email Addresses, support addresses, case replies, and automation senders. An Org-Wide Address can be verified as an email address and still fail if the domain behind it has not been verified. For Spring ’26, admins need to check both layers: the sender address and the domain it belongs to. If one layer is missing, Salesforce may block delivery before the message reaches the recipient.
DKIM, Authorized Email Domains, SPF, and DMARC: explained simply
Salesforce gives admins two ways to verify an email-sending domain. You can use an active DKIM key or a verified Authorized Email Domain. Both can satisfy the Spring ’26 sending requirement, but they don’t do the same job for email trust. DKIM is the stronger route for most orgs because it helps receiving mail servers check whether the message really came from your domain.
DKIM: the recommended path
Salesforce recommends DKIM for domain verification. DKIM adds a digital signature to outgoing emails, so the receiving server can check that the message came from an approved source and was not changed on the way. For Salesforce emails, this matters because customer updates, case replies, approval alerts, and automated notifications need to look legitimate when they reach Gmail, Outlook, or a company mail server.
To set it up, an admin creates a DKIM key in Salesforce Setup under DKIM Keys. Salesforce then gives DNS records, usually 2 CNAME records, that your DNS team must publish. Once the records are live and Salesforce verifies them, that domain can send through Salesforce.
There is one catch admins should plan for: each domain and subdomain needs its own active DKIM key. A key for yourcompany.com does not automatically cover support.yourcompany.com, mail.yourcompany.com, or region.yourcompany.com. If your org uses multiple brands, regions, or support addresses, each one needs a separate check.
Authorized Email Domains: the fallback
Authorized Email Domains can also prove domain ownership. This option works when DKIM is not possible or when your team has a specific reason to avoid DKIM for a domain. The setup is simple from the Salesforce side. Go to Setup, search for Authorized Email Domains, add the domain, and follow the TXT record verification steps. Your DNS admin still needs to publish the record before Salesforce can verify ownership. This meets the Salesforce requirement, but it does not add the same inbox trust that DKIM can provide.
SPF and DMARC
SPF and DMARC sit outside Salesforce, but they matter for the same reason: they help protect your domain’s email reputation. SPF tells receiving servers which systems can send email for your domain. DMARC uses SPF and DKIM results to decide what should happen when a message fails checks. The receiving server may allow it, quarantine it, reject it, or send a report. For a clean setup, DKIM, SPF, and DMARC should all pass when you test Salesforce email delivery. That gives admins a better chance of keeping Salesforce messages out of spam and helps stop others from faking emails from your domain.
Where Salesforce teams get caught
The most common assumption we hear is: “Our main users verified their emails a while ago, so we should be fine.” That is where many teams misread the Spring ’26 change. Salesforce is now checking the sending domain, not just the person behind the inbox. Breaks usually show up in shared addresses, automations, relay paths, sandboxes, and Experience Cloud setups.
Org-Wide Email Addresses
Org-Wide Email Addresses are one of the first places to check. Salesforce cannot send system-generated emails from an Org-Wide Address if the domain behind it has not been verified. The individual address may already be verified, but that does not cover the full domain. So addresses like support@yourcompany.com, billing@yourbrand.com, or noreply@yourcompany.com need domain-level verification before Salesforce can safely send from them.
Email Relay and SMTP
Email relay does not bypass the new requirement. Some teams assume that routing Salesforce email through their own mail servers means Salesforce will no longer check the sending domain. It still does. Whether the message goes through Salesforce’s default mail path or your SMTP relay, Salesforce needs proof that your org controls the sending domain. That proof must come through DKIM or Authorized Email Domains.
Flows, Workflow Alerts, and Automations
Automations are risky because they often run quietly in the background. A Flow email action, workflow alert, approval notice, or scheduled notification sends from the user or address assigned to that process. If that domain is unverified, delivery can stop without the business team noticing right away. The first sign may be a missed approval, a customer who never got an update, or a case team wondering why replies slowed down.
Apex Emails
Apex follows the same sending rules. If developers have written custom email logic using Salesforce email classes, the domain used in that logic still needs verification. Admins should review custom senders with the development team instead of assuming the code path is separate.
Sandboxes
Sandboxes need their own setup. DKIM keys and Authorized Email Domains do not copy over when a new sandbox is created. Each sandbox needs fresh records and separate verification. This matters for UAT, release testing, and any sandbox that sends test emails to real users.
Experience Cloud and Public Domain Users
Experience Cloud can involve users with domains your company cannot verify, such as yahoo.com, iCloud.com, or other personal email domains. In those cases, Salesforce’s substitute email address option can help prevent failed sends by using a verified fallback sender.
How to audit and fix your Salesforce email setup
Here is a practical way for an admin team to work through the Spring ’26 email change without missing hidden senders.
Start by listing every domain your org sends from. Include user email domains, Org-Wide Email Addresses, Email-to-Case reply addresses, automation senders, and any address used by Flow, workflow alerts, approvals, or Apex. Then check what is already configured. In Setup, review DKIM Keys and Authorized Email Domains. You can also use Developer Console to pull the current DKIM and Authorized Email Domain records if your team prefers a query-based review.
Next, look for delivery failures. In Setup, inspect email logs and search for this error: 550 5.7.1 Delivery not authorized, message discarded. That error is a clear sign that Salesforce blocked a send because the domain was not approved for delivery.
For each domain, choose one verification route. The better option for most teams is an active DKIM key. If DKIM is not possible for a specific domain, use a verified Authorized Email Domain. Either way, your DNS team must publish the required records. Salesforce admins cannot complete this alone unless they also control DNS, so bring IT or infrastructure into the work early.
For sandboxes, repeat the process separately. DKIM keys and Authorized Email Domains do not carry over from production. A refreshed or newly created sandbox needs its own records and verification.
If your org has Experience Cloud users or public email domains that you cannot verify, turn on “Use a substitute email address for unverified domains” in Deliverability Setup. This gives Salesforce a verified fallback sender for those cases.
Salesforce admin email verification checklist
- Identify all domains used for Salesforce email sending.
- Check user domains, Org-Wide Addresses, Email-to-Case addresses, and automation senders.
- Review Setup > DKIM Keys for active keys.
- Confirm each domain and subdomain has its own DKIM setup where needed.
- Review Setup > Authorized Email Domains for verified entries.
- Search email logs for 550 5.7.1 errors.
- Review flows, workflow alerts, and approval notifications.
- Ask developers to review Apex email logic.
- Confirm Email-to-Case reply addresses use verified domains.
- Review Experience Cloud user domains and fallback sender settings.
- Create separate DKIM keys and Authorized Email Domains for each sandbox.
- Check SPF and DMARC records before production rollout.
- Test delivery end to end in sandbox first.
If your org sends from multiple domains or subdomains, treat each one as its own audit item. This is common after acquisitions, regional brand setups, or separate support teams. One verified parent domain will not automatically protect every sender your Salesforce org uses.
How Hyphenx can help
For teams managing large Salesforce orgs, this audit usually goes beyond a quick Setup check. You need to know every outbound email path, who owns each sending domain, which DNS records are already live, and where custom Apex or automation may still be sending from an unverified address. Sandboxes also need a separate plan, especially if your team tests customer-facing email before release.
Hyphenx works with Salesforce admins, RevOps teams, and IT teams to review outbound email configuration in a practical way. We help identify affected domains, set up DKIM keys and Authorized Email Domains, review SPF and DMARC records, check Apex email logic, and test delivery in sandbox before production changes go live. For orgs using Email-to-Case, Experience Cloud, or heavy automation, this kind of review helps catch broken send paths before they affect customers.
