Salesforce requires verified email-sending domains in Spring ’26. Admins should check DKIM, authorized domains, relay, and automation paths before messages fail.
Key takeaways
- Inventory every Salesforce sending domain this week.
- Verify each domain with DKIM or an authorized email domain.
- Test Case, approval, relay, and org-wide email paths.
- Assign one Salesforce owner and one DNS owner.
- Document the verification method and last test date.
Salesforce email can fail if the sending domain is not verified.
That is the admin action behind Salesforce’s Spring ’26 email-sending domain verification requirement. If Salesforce sends from company.com, Salesforce needs proof that your organization controls company.com.
The current Salesforce Help article says delivery fails for emails sent from Salesforce if the email domain, meaning the part after the @ symbol, is not verified. Salesforce lists two verification paths: an active DKIM key or a verified authorized email domain.
For admins, this is not only a deliverability setting. It can affect case responses, approval alerts, invoice reminders, renewal notices, and other emails that users may not think of as “Salesforce email.”
What is Salesforce email domain verification?
Salesforce email domain verification is a domain-level control for outbound email sent from Salesforce. It checks whether the domain after the @ symbol has been verified.
This is separate from individual email address verification.
Example:
jane@company.comcan be an approved individual sender.company.comstill needs domain-level verification.- If
company.comis not verified, Salesforce says delivery can fail.
That distinction matters. Many orgs have verified users, org-wide email addresses, and email relay settings that have worked for years. Spring ’26 adds a broader domain check to that path.
Salesforce says the requirement applies to email relay. Teams using Microsoft 365, Google Workspace, Proofpoint, Mimecast, or another mail gateway should not assume relay removes the need to verify the sending domain in Salesforce.
When did Salesforce announce the email domain change?
Salesforce published the current Spring ’26 Help article on June 10, 2026. Salesforce’s broader security-related product updates roadmap was published on June 2, 2026.
The Help article also describes temporary allowlist generation for existing orgs. Salesforce says the allowlist generally includes domains used between January 7, 2026 and February 25, 2026, and also during May 2026. For Government Cloud orgs, Salesforce says the allowlist includes domains used between January 25, 2026 and February 25, 2026, and also during May 2026.
That detail is useful, but it should not become the plan.
A domain may continue working because Salesforce saw it during the usage window. That does not prove the domain is cleanly configured. It also does not help with a new sending domain added later, such as support.company.com, billing.company.com, or a domain introduced by a managed package.
Treat the allowlist as temporary protection. Treat verification as the durable fix.
What breaks if Salesforce email domains are not verified?
Outbound email can fail when Salesforce sends from an unverified domain.
The affected paths can include more than user-composed messages. Admins should check every place Salesforce sends from a company-branded address, including:
- Case auto-response rules
- Case escalation notifications
- Flow “Send email” actions
- Workflow email alerts still in use
- Approval process notifications
- Experience Cloud registration emails
- Experience Cloud password reset emails
- Salesforce email relay traffic
- Managed package notifications
- Apex email using
SingleEmailMessage - Org-wide email addresses
- List emails sent from Sales Cloud
The operational risk is not limited to customer-facing email. Internal notifications matter too.
A failed approval alert can delay a quote. A failed case notification can make a support team miss an SLA. A failed billing reminder can turn into a collections issue. None of those failures look like a Salesforce configuration problem at first. They look like a process problem.
The wrong test is “can one user send one email.”
The right test is whether every sending domain is verified, and whether the important email paths still work after verification.
How should Salesforce admins prepare now?
Start with a sending-domain inventory. List every domain Salesforce uses in the From address.
Review these areas first:
- Setup email settings
- Org-wide email addresses
- DKIM keys
- Authorized email domains
- Email relay configuration
- Case routing addresses
- Case email templates
- Flow email actions
- Workflow email alerts
- Approval process email alerts
- Apex classes that call
Messaging.sendEmail - Managed packages that send email
Then match each sending domain to a verification method.
Salesforce says admins can verify a domain with an active DKIM key or a verified authorized email domain. In many orgs, DKIM is the cleaner control because it fits the existing DNS-based mail authentication model. It also gets the right team involved. Salesforce admins can configure Salesforce. DNS owners must publish and maintain the required records.
Do not leave this only with the Salesforce admin.
The Help article states that the change requires Salesforce admins and DNS admins. That matches what we see in mid-market orgs. Marketing may own one domain. IT may own DNS. Sales Ops may own Salesforce. Support may own case email. Nobody owns the full sending path until something fails.
Assign two owners:
- One Salesforce owner for the inventory and configuration
- One DNS owner for the records and mail authentication checks
If your company uses multiple domains, do not collapse them into one line item. company.com, support.company.com, and mail.company.com are different domains for this work.
What should IT and ops test after verification?
Run a business-process test, not a setup-page test.
Salesforce configuration can look correct while a real message still fails later in the mail path. Test the routes that users and automations use every day.
At minimum:
- Create a test Case and confirm the auto-response arrives.
- Trigger a Flow email action from a sandbox or safe production test.
- Submit an approval and confirm the approver receives the email.
- Send from each org-wide email address.
- Test each email relay path.
- Test Experience Cloud registration and password emails if used.
- Test managed package notifications that send customer or partner emails.
- Ask the email administrator to confirm SPF, DKIM, and DMARC alignment.
Use Salesforce Email Log Files where needed. Ask the mail team to check gateway logs too. Salesforce may show an attempted send while the mail gateway rejects, rewrites, or quarantines the message.
Also check the sender addresses in templates and automation. Older Workflow email alerts and Apex email code often contain addresses that have not been reviewed in years. A hardcoded noreply@oldbrand.com can create a failure even if the primary company domain is verified.
Does this affect every Salesforce org?
It can affect any Salesforce org that sends email from a domain that has not been verified.
The impact depends on your org’s email setup, domains, relay design, and whether Salesforce included your domains in the temporary allowlist windows. The Help article confirms two important points: the requirement applies to email relay, and domain-level verification is in addition to individual email verification.
Use this rule of thumb: if Salesforce sends email from a domain your company owns, verify that domain.
Do not rely on old behavior. Do not rely on one successful send from one user. Do not assume a sandbox result proves production is clean, especially if DNS, relay, org-wide email addresses, or managed package settings differ between environments.
This is a short admin hardening task. The work is discovery, DNS coordination, configuration, and testing. It does not need to become a large project, but it does need an owner.
What should admins do this week?
Build the inventory first, then verify and test the highest-risk email paths.
A practical one-week plan:
- Export or document all org-wide email addresses.
- List every domain used by Flow, Workflow, approvals, Case email, Experience Cloud, Apex, and managed packages.
- Check DKIM keys and authorized email domains in Setup.
- Confirm who owns DNS for each sending domain.
- Verify each required domain using DKIM or an authorized email domain.
- Test Case auto-responses, approval alerts, relay traffic, and org-wide email sending.
- Save the results in an admin runbook with the domain, verification method, owner, and last test date.
LOVALTO would treat this as a focused hardening task. The goal is not to redesign email. The goal is to prevent a small configuration gap from blocking customer, billing, support, or approval messages.
Start with the domains. Then test the business emails that would create the most noise if they failed.