Customer trust is our highest priority at Salesforce. To comply with the latest browser and security standards, Salesforce required that customers deploy enhanced domains in 2023. That feature updated the hostname formats for the domains that serve Salesforce orgs.
In the Winter ’25 release (starting in August 2024), Salesforce stopped redirecting previous non-enhanced domains in sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds.
Support ends for incorrect instanced URLs in API calls via the Update Instanced URLs in API Traffic release update. Salesforce enforces that change on a rolling basis in production orgs shortly after Winter ’27 deployment.
This article was updated in July 2024 to focus on the most common questions about the end of those redirections. Previous questions about deploying and testing enhanced domains can be found in the “Archived Questions” section.
As always, you can use the revision history at the end of the article to track changes to this article.
Enhanced Domains Essentials
Redirections
Other Questions
Get Started
Enable and Deploy Enhanced Domains
Update Your Org
Testing
URL (Hostname) Changes
Experience Cloud Sites & Salesforce Sites
Other Product- or Feature-Specific Questions
Other Questions
Enhanced domains are the latest version of the My Domain feature. Because they meet the latest browser requirements, including allowing users to access Salesforce with browsers that block third-party cookies, they’re required in all Salesforce orgs. This feature was enforced in the Winter ’24 release, starting in September 2023 for production orgs.
Enhanced domains apply an org’s company-specific My Domain name to all URLs that Salesforce hosts for your org. This feature also changes domain suffixes (the part after the My Domain name) to meet the latest security standards. With no instance names, enhanced My Domain URLs are easier for users to remember and don’t change when an org is moved to another Salesforce instance.
For more information, see Enhanced Domains in Salesforce Help and the Enhanced domains video (available in English only).
See Determine Whether Enhanced Domains Are Enabled in Salesforce Help.
After enhanced domains are deployed in an org, that org’s previous non-enhanced My Domain URLs are redirected, like with any My Domain change.
Here are some special considerations around redirections:
These redirections are in place to help prevent disruption. We highly recommend that customers update all references to their old URLs after they deploy a new My Domain. One way you can find the places those old URLs are used is to temporarily disable redirections during your testing.
For more information on redirections, see My Domain Redirections in Salesforce Help.
For the list of URLs for which redirections stop and instructions on how to test for that change, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
In sandboxes, Developer Edition orgs, demo orgs, patch orgs, scratch orgs, and Trailhead Playgrounds, redirections for legacy (non-enhanced) My Domain URLs stopped in Winter ’25, starting in August 2024.
In production orgs and demo orgs, legacy host name redirections end with the enforcement of the Update References to Legacy Host Names release update, which was introduced in Spring ’25. You can enable and disable those redirections until Spring ’26, which is deployed to production orgs starting in January 2026. In that release, Salesforce stops those redirections via the Update References to Legacy Host Names release update, and you can’t reenable them.
Also, if your org was created before October 2020, Salesforce stops redirections for hostnames that contain your instance name but not your My Domain name on the same schedule.
Finally, in Summer ’25, Salesforce introduced the Update Instanced URLs in API Traffic release update, which is enforced on a rolling basis shortly after Winter ’27. See End-of-Support Schedule for Incorrect Instanced URLs in API Traffic.
For more details on the schedule for the end of legacy redirections, see Enhanced Domains Timeline in Salesforce Help. To review the affected hostnames, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
Previous site URLs that end in *.force.com are no longer redirected in sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds with the Winter ’25 release, starting in August 2024.
In production orgs and demo orgs, previous site URLs that end in *.force.com end with the enforcement of the Update References to Legacy Host Names release update in Spring ’26. For more details on the schedule for the end of legacy redirections, see Enhanced Domains Timeline in Salesforce Help.
Yes, redirections for legacy (non-enhanced) host names stop in Spring ’26 for API traffic.
What this means: If you use an instanced URL (such as na45.salesforce.com when your org is currently on USA123) or an old login URL (for example, MyDomainName--SandboxName.my.salesforce.com instead of MyDomainName--SandboxName.sandbox.my.salesforce.com) in your API traffic, those URLs are no longer redirected. As a reminder, your org’s My Domain login URL didn't change with enhanced domains.
The timing is slightly different based on the type of URL.
To help you test for the end of support for instanced URLs in API traffic, Salesforce introduced a release update in Summer ’25. Look for Update Instanced URLs in API Traffic on the Release Updates page in Setup. To get notified about the specific rollout dates for that change, join the My Domain and Enhanced Domains Trailblazer Community Group
For more information, see Salesforce Help: Enhanced Domains Timeline.
Salesforce delayed their plan to stop redirections in production orgs twice. Both times, the delay was intended to give customers more time to test.
To help you prepare for this change, Salesforce added the Update References to Legacy Host Names release update in Spring '25. That release update is enforced in Spring '26, which is deployed to production orgs starting in January 2026. Also, Salesforce plans to disable redirections for you in Summer '25 and in Winter ’26. For more information, see Enhanced Domains Timeline in Salesforce Help.
That release update was initially scheduled to be enforced in sandboxes in Winter ’26 and in all other orgs, including production, in Spring ’26.
Salesforce delayed the enforcement of this release update twice:
If Salesforce hasn't stopped redirections for legacy domains in your org, you can control those redirections via the Redirect legacy (non-enhanced) My Domain hostnames setting in the Redirections section of the My Domain Setup page. That setting is available only in production, demo orgs, and some new sandboxes. When Salesforce stops those redirections, that setting has no effect.
For more information, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
If the hostname matches the formats in My Domain Login and Application URL Formats with Enhanced Domains in Salesforce Help, Salesforce redirects your previous My Domain hostnames until you deploy another My Domain change or until you disable or remove your previous My Domain.
Incorrect instanced URLs in API traffic continue to work until the Update Instanced URLs in API Traffic release update is enforced.
For more information, see Understand Redirections for Previous My Domain Hostnames in Salesforce Help.
After enhanced domains were deployed, your previous non-enhanced hostnames are redirected. In sandboxes, Developer Edition orgs, demo orgs, patch orgs, scratch orgs, and Trailhead Playgrounds, those redirections stopped in Winter ’25, starting in August 2024.
Starting in October 2025, you could temporarily enable these redirections in a new sandbox. See the Winter ’26 release note, Test the End of Legacy Host Name Redirections in New Sandboxes.
In production, demo orgs, and sandboxes, redirections for those legacy URLs stop with the enforcement of the Update References to Legacy Host Names release update. For more information, see Enhanced Domains Timeline in Salesforce Help.
To learn the specific date that your org gets that release, navigate to Trust Status, search for your instance or My Domain name, and click the Maintenance tab. For more information, see Get Your Org Status and Upcoming Maintenance Dates with My Domain in Salesforce Help.
That support ends on a rolling basis shortly after your org gets Summer ’26. To get notified about the specific rollout dates for that change, join the My Domain and Enhanced Domains Trailblazer Community Group.
Note: Although API traffic that uses your correct instanced URL continues to work after these changes, that API traffic stops working if your org’s instance changes. Your org’s instance name can change during regular maintenance, such as an instance refresh, or during a migration to the latest infrastructure, such as Hyperforce. For that reason, we recommend that you use your My Domain login URL in API calls.
For more information, see Enhanced Domains Timeline in Salesforce Help.
To help you test, in Winter ’25, Salesforce stopped legacy redirections in sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds. In production orgs and demo orgs, you can temporarily disable redirections from the My Domain page in Setup.
For details on My Domain redirections, the corresponding settings, and how to log redirections after a My Domain change, see My Domain Redirections in Salesforce Help.
For the list of legacy URLs and instructions on how to test for that change, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
To test the Update Instanced URLs in API Traffic release update, enable Block API traffic that uses an incorrect instanced URL in the Redirections section of the My Domain page in Setup.
NOTE: If you enable that setting before the related known issue is resolved, SOAP login URLs via Visualforce pages can return a 400 Bad Request error. Salesforce plans to deploy a fix for that issue June 16–18, 2026, so we recommend that you test this change after June 18, 2026.
For more information, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
Enable the Hostname Redirects event log. For more information, see Log My Domain Hostname Redirections in Salesforce Help.
Yes. The Hostname Redirects event log captures both successful and blocked redirections for the hostnames associated with the My Domain before the last My Domain deployment. It also captures successful and blocked redirections to legacy hostnames listed on Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
In the log, the REDIRECT_REASON for redirections that were blocked because Salesforce stopped redirections for the legacy URL is Redirection was blocked because redirections for the legacy SOURCE_HOSTNAME are no longer supported.
Use the REFERRER and ORIGIN fields in the log, available in API version 58.0 and later. (API version 58.0 corresponds to the Summer ’23 release.)
Note: The information contained in those fields is determined by the Referrer-Policy HTTP header sent with the request. So in some cases, these log fields can be null. For more information, see Object Reference for the Salesforce Platform: Hostname Redirects Event Type.
If those fields are null, you can also try these methods:
In the end, you may not be able to identify the source of every redirection. We recommend that you focus on high-volume, high-impact areas and prepare to make some updates and help users when redirections end.
The documentforce.com domain is the legacy domain for files stored in Salesforce. Those can include images and PDF attachments. The new URLs end in .file.force.com. Often calls to these URLs are from a user’s bookmark, hard-coded references to images, or cached content. An example of a hard-coded reference is an image in an email template.
The redirection log captures any call to your legacy URLs, including requests from bots. It’s an unfortunate reality that bots constantly crawl the internet, both to identify valid URLs and to attempt to find vulnerabilities. That kind of request is generally referred to as an “untargeted attack”. Also, other bots will make requests to known URLs, attempting to take advantage of known exploits.
If you cleaned up the logged redirections that you could identify, searched for and removed hard-coded references, and tested Salesforce with redirections disabled – including integrations – that’s the best way to ensure that you’re prepared for the end of legacy redirections.
The way a redirection works is that Salesforce sends a special redirect response to a request, telling the requester that the URL is no longer valid and to use the new URL. If the requester isn't configured to process that redirect response, the user or process isn't redirected. For this reason, calls to some of your old URLs can fail even with redirections in place. For this reason, we highly recommend that you test all integrations and calls to the URLs that changed.
If Setup pages for your org aren't served on the salesforce-setup.com for your org and the My Domain setting Require first-party use of Salesforce cookies is enabled, accessing older Setup pages that were built in Classic requires an extra step. Users see a message that directs them to open the page in Salesforce Classic.
Salesforce is rolling out the new setup domain (salesforce-setup.com for Setup pages). When your Setup pages are served on that domain, the message will no longer appear.
For more information on the new salesforce-setup.com domain, see this documentation:
Summer ’24 Release Note: Add the New Setup Domain
Knowledge Article: New Setup Domain Rollout FAQ
That option is available only after you deploy a change to your My Domain. Otherwise, there are no previous My Domain URLs to redirect.
The other reason this option can be unavailable is if you deployed a change and then clicked Remove Previous My Domain. (Like the checkbox, that button is only visible after you deploy a change to your My Domain.)
With Partitioned Domains, My Domain hostnames for your Developer Edition org, demo org, patch org, sandbox, scratch org, or Trailhead Playground include a word related to the org type. For example, partitioned domains for Developer Edition orgs include the word develop. Partitioned domains allow Salesforce to maximize the availability of your orgs by gradually rolling out delivery changes. And it’s easier to identify an org by a URL when the domain is partitioned. Partitioned domains are used by default in qualifying new orgs (of the types listed above). They’re not required in existing orgs, and they aren’t for production orgs.
Enhanced Domains are the current version of My Domain that meets the latest browser requirements. Sandboxes with enhanced domains are always partitioned. (They include the word “sandbox”.) Sandboxes are only partitioned through enhanced domains; you can’t enable partitioned domains in a sandbox without enhanced domains, and you can’t disable partitioned domains in a sandbox with enhanced domains. Enhanced domains were enforced in Winter ’24 and can’t be disabled.
For general questions, join our monitored My Domain and Enhanced Domains Trailblazer Community group. You can search for answers and post new questions in that group.
For time-sensitive questions and issues, submit a case to Salesforce Customer Support.
These questions are no longer relevant when enhanced domains are enforced.
Get Started
We know that there's a lot of information out there on this feature, and that the feature itself is complex.
The Enhanced domains video (available in English only) provides an overview of the feature, the deployment and enforcement timeline, the impact, and where to start. More information is also below.
The best place to start is usually determining what the impact is for you. To do that, we recommend you start with these pages in Salesforce Help. (Note that the impact isn't based on the Salesforce edition you use, but rather which functionality you use.)
Useful reference:
Whew! That's a lot of information. You can also view these previous webinars:
We also encourage customers to join the monitored My Domain and Enhanced Domains group in the Trailblazer Community.
The Deploy Enhanced Domains (formerly "Enable Enhanced Domains") release update was first made available with the Summer ’21 release.
Enhanced domains were enforced in phases starting in Winter ’23.
For additional timeline details, see Enhanced Domains Timeline in Salesforce Help.
Because enhanced domains affect all application URLs, we recommend that you test and deploy enhanced domains before this change is enforced. We also recommend that you test enhanced domains in a sandbox before you update production.
For details on how to set up, test, and deploy enhanced domains, see Plan for a My Domain Change, Enhanced Domains and Update Your Org and Test My Domain Changes in Salesforce Help.
For example project, pre-deployment, and post-deployment checklists, see Example My Domain Change Checklists in Salesforce Help. Those checklists are also available in Quip in My Domain Change Checklists Templates.
A couple of notes on the checklists:
For details about the change being enforced, see the Summer ’23 Release Note: Deploy Enhanced Domains (Release Update), and check out the Enhanced domains video (available in English only).
For details on how to set up, test, and deploy enhanced domains, see Plan for a My Domain Change, Enhanced Domains and Update Your Org and Test My Domain Changes in Salesforce Help.
You can also view these previous webinars:
We also encourage you to join the monitored My Domain and Enhanced Domains group in the Trailblazer Community.
Enable and Deploy Enhanced Domain
Important: Don't get locked out! Before you deploy enhanced domains, understand whether your My Domain login URL changes and make sure that you can log in after the change. For details, see Preserve Login Access During a My Domain Login URL Change in Salesforce Help.
In Setup, on the My Domain page, edit My Domain Details and select Use enhanced domains. Then, after Salesforce provisions your new My Domain, deploy your new My Domain from the same Setup page.
For details on how to set up, test, and deploy enhanced domains, see Plan for a My Domain Change, Enhanced Domains and Update Your Org and Test My Domain Changes in Salesforce Help.
As part of the provisioning process for your new domain, Salesforce performs a cursory check to ensure that you have network access to the new domains. If you don’t have the required access, the My Domain page lists the URLs you can’t access in red. To prevent potential access issues, you can't click the Deploy New Domain button.
The access issues can be temporary or they can require action.
To deploy your My Domain, revisit the My Domain Setup page after the access issues are resolved.
Update Your Org
At a high level, update references to your changed URLs.
When you enable enhanced domains, all URLs across your org contain your company-specific My Domain name, including Experience Cloud sites and Salesforce sites. Because your org’s URLs change, we recommend that you test your org’s functionality in a sandbox with enhanced domains before enabling this feature in production. Pay particular attention to customizations that reference your old URLs.
For a list of the areas to update, see Update Your Salesforce Org for Your New Domain in Salesforce Help. For guidance on planning for this change and example checklists, see Plan for a My Domain Change in Salesforce Help.
The change to external-facing URLs such as Experience Cloud sites and Salesforce sites deserves additional attention. These changes can require updates to your external-facing links and the configuration of any custom domains pointing to these URLs. For more information, see Considerations for Enhanced Domains in Salesforce Help.After you enable enhanced domains, test. Salesforce recommends that you test enabling enhanced domains in a sandbox to identify the updates to make when you deploy a My Domain in production. For more information, see Test Your New My Domain in Salesforce Help.
One method is to download your org's metadata and search for occurrences of old URLs. For a list of URLs to search for, see My Domain URL Format Changes with Enhanced Domains Deployment in Salesforce Help. To search your Salesforce code, download the metadata. Then use a command-line interface such as Salesforce CLI.
Depending on how unique the instance name or My Domain name is relative to the rest of the metadata, searching for the org's instance name (when deploying a My Domain) or My Domain name (when enabling enhanced domains) can be easier.
Depending upon your configuration, you may need to make updates before and after you deploy enhanced domains. To determine whether you need to make any updates to your authentication configuration and understand the steps to take, see Update Authentication After a My Domain Change in Salesforce Help.
If your users can authenticate with alternate identity providers or a SAML Single Sign-On (SSO) authentication method from your My Domain login page or Experience Cloud site login page, those authentication methods stop working when the page's URL changes and can be removed from the page.
To restore these authentication methods:
Testing
After you Update Your Org for My Domain Changes, follow the guidance on Test My Domain Changes in Salesforce Help. Note that Salesforce highly recommends that you temporarily disable all redirections before you test.
Here are some common themes for issues that you can encounter after you deploy enhanced domains.
NOTE: This is not a comprehensive list of the issues that can arise. We recommend testing enhanced domains in a sandbox to verify your configuration before you deploy enhanced domains in production.
When you deploy enhanced domains in production without renaming your My Domain or changing your My Domain suffix, these issues that can arise.
| Behavior | Related Updates |
|---|---|
| Errors when attempting to access Salesforce pages, including but not limited to: Experience Cloud sites, Salesforce Sites, Visualforce pages, and content. | Update your Allowlists, trusted domains, permitted domains, and other hostname-based restrictions. Update hard-coded references to your old URLs. Update your version of the Mobile Publisher for Experience Cloud app. |
| Users can't access Experience Cloud sites or Salesforce Sites. | Update IP-based restrictions to include the IPv6 range. Update authentication (SSO, MFA, named credentials). Update the identity providers on your login page. Update hard-coded references to your site URL. Update trusted domains for inline frames. Update network-level restrictions that specify only IP addresses. |
| Your custom domain that serves your Experience Cloud site or Salesforce Sites stops working. | Update the domain configuration as required. |
| Open CTI (Computer Telephony Integration) or Click to Dial stops working. | Update your telephony provider and Open CTI. For more information, see the Knowledge Article, Enhanced Domains and Open CTI with Visualforce (Spring ‘23). |
| Integrations, external software, or connected apps can't access your Experience Cloud sites or Salesforce Sites. | Update authentication to use your new site login URL. Work with the third party to update their configuration to use your new site login URL. Work with the third party that to ensure that they support Server Name Indication (SNI). |
| External software and connected apps can't access your sites. | Update authentication to use the new site login URLs. |
| Users can't access Enablement Sites (myTrailhead) that uses your sites URL that ends in *.force.com. | Contact Salesforce Customer Support to update your authentication provider with your new sites login URL. |
| Images stored in Salesforce fail to load on both external and internal pages. | Update the URL references to content stored in Salesforce. Update badge and image URLs in Enablement Sites (myTrailhead) |
| Some functionality within installed packages from AppExchange stops working. | Verify whether the package has been updated and install a patch or version that supports enhanced domains. |
When you deploy enhanced domains in a sandbox, or deploy enhanced domains in a production org and also change your My Domain name or suffix, your My Domain login URL also changes. Thus you can encounter the issues listed above and these additional common issues.
| Behavior | Related Updates |
|---|---|
| Users and processes can't access your Salesforce org. | Update authentication (SSO, MFA, named credentials). Update the identity providers on your login page. Update hard-coded references to your My Domain login URL. |
| Third-party connected apps and integrations fail to connect to your org or site. | Update authentication. Update hard-coded references to your My Domain login URL. Ensure that third parties can process the redirect header from Salesforce. |
| A Messaging for Web deployment that was previously published no longer appears to your customer. | Republish all pre-existing deployments of Messaging for In-App. |
| Users can't access Enablement Sites (myTrailhead) that uses your My Domain login URL. | Contact Salesforce Customer Support to update your authentication provider with your new My Domain login URL. |
| Service Cloud Voice stops working. | Work with your telephony provider to update your configuration with your new URLs. Update the allowlist in Amazon Connect with your new Visualforce URL. Note: When you deploy enhanced domains in an org on Spring ’23, Salesforce updates Amazon Connect except for the allowlist. |
For more information on the related updates, see Update Your Org for My Domain Changes in Salesforce Help.
URL (Hostname) Changes
Enhanced domains have no impact on instanced URLs in the format <instanceName>.salesforce.com. However, we recommend against using those URLs, because they can change with an org migration, which is part of regular maintenance. Also, API calls to a Hyperforce org can’t use that method.
If you find instanced URLs during your updates for enhanced domains, we highly recommend that you use one of the following:
login.salesforce.com for production orgs and test.salesforce.com for sandboxes.For more information, see Log In to Salesforce with Code in Salesforce Help.
If you find another URL that contains your instance name, enhanced domains probably changed that URL. For more information, see My Domain URL Format Changes with Enhanced Domains Deployment and Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.
If your org is served by URLs with the *.cloudforce.com or *.database.com suffixes, you must move to the Standard (*.my.salesforce.com) My Domain suffix before you can enable enhanced domains. Thus, when enhanced domains are enforced, you will also move to the *.my.salesforce.com suffix.
This means:
When you enable enhanced domains, you must select Standard in the Domain Suffix field. Only then can you select Use enhanced domains.
Your login URL changes in production (because the suffix changes). When you plan to deploy enhanced domains and update your org, follow the steps related to when your My Domain login URL changes.
After you deploy enhanced domains, your previous *.cloudforce.com or *.database.com URLs are redirected until you deploy another My Domain or until Salesforce stops those redirections, whichever comes first. For more information, see My Domain Redirections in Salesforce Help.
If your users log in to Salesforce via a branded login page on the .cloudforce.com domain, the branded login page remains available. After the user logs in, Salesforce serves your org on the enhanced domain URLs.
Do enhanced domains prevent users or APIs from using the standard login URLs?
No. Deploying enhanced domains doesn’t prevent users or APIs from logging in with login.salesforce.com (for production orgs) or test.salesforce.com. After you enable enhanced domains, you can control this behavior with two options in the Policies section of the My Domain Setup page. For more information, see Set My Domain Login and Redirect Policies in Salesforce Help. For more information on all the options related to My Domain hostnames, see Understand Redirections for Previous My Domain Hostnames in Salesforce Help.
To add an extra layer of security, Salesforce recommends that you use your org’s My Domain login URL instead of login.salesforce.com or test.saleforce.com to log in to Salesforce with code and APIs. For more information, see Log In to Salesforce with Code in Salesforce Help.
To determine whether an API integration is impacted when you deploy enhanced domains, look at the URL that the integration uses to connect to Salesforce. If that URL changes, the integration can stop working until you update the URL. For a list of the URLs that change when you deploy enhanced domains, see My Domain URL Format Changes with Enhanced Domains Deployment in Salesforce Help. Although your previous URLs are redirected by default, not every third party can process those redirections. More importantly, Salesforce stops some redirections in Winter ’25 and Spring ’25, so be sure to update API integrations that rely upon the old URL.
More information:
In a sandbox, your My Domain login URL (https://MyDomainName--SandboxName.my.salesforce.com) changes when you deploy enhanced domains: the word "sandbox" is added to it.
https://MyDomainName--SandboxName.sandbox.my.salesforce.com).https://test.salesforce.com URL continue to work when you deploy enhanced domains unless the My Domain option, Prevent login from https://test.salesforce.com, is enabled.In production, your My Domain login URL (https://MyDomainName.my.salesforce.com) doesn't change when you deploy enhanced domains unless you also change your My Domain name or suffix.
https://login.salesforce.com URL continue to work when you deploy enhanced domains unless the My Domain option, Prevent login from https://login.salesforce.com, is enabled.In both sandboxes and production, if an API uses your *.force.com Experience Cloud site or Salesforce Site URL, those URLs change with enhanced domains. Update the API to use the new site URL after you deploy enhanced domains.
If the API integration uses any other URL to integrate with Salesforce, check the URL format; it probably changes when you deploy enhanced domains.
When you deploy enhanced domains in production:
MyDomainName.lightning.force.com hostname formatMyDomainName--PackageName.container.lightning.com hostname format changeInstanceName.lightning.force.com hostname format changeWhen you deploy enhanced domains in a sandbox, all of the corresponding URLs change:
MyDomainName--SandboxName.lightning.force.com hostname change (the word "sandbox" is added)MyDomainName--SandboxName--PackageName.container.lightning.com hostname format change InstanceName.lightning.force.com hostname format changeFor more information, see My Domain URL Format Changes with Enhanced Domains Deployment.
Do I need to update hardcoded URL references in managed or installed Visualforce pages?
If you own the Visualforce page, yes, you must update any hardcoded URL references in the page, ideally using a relative or dynamically created URL instead. However, keep in mind that you probably can't edit Visualforce pages delivered by a package directly because the page is managed by the package. (And even if you can update it, you don't want your changes to be overridden by the next package update.)
For managed packages, Salesforce highly recommends that package developers use relative paths to build any links. If the package developer used that approach, the link should work after you enable enhanced domains.
We recommend that you testing those pages in a sandbox with enhanced domains enabled and redirections (temporarily) disabled. If you find an issue, contact the package developer so that they can publish a new version of their package that works with enhanced domains.
For more information, see Link to Salesforce Domains in Packages in Salesforce Help and Call Salesforce URLs Within a Package in the ISVForce Guide. (Tip: the second page provides examples of building dynamic URLs that apply to more than packages.)
No, you can't change the suffix of the URLs that Salesforce hosts for your org with enhanced domains.* Enhanced domains aren’t about customizing URLs. This feature affects internal Salesforce suffixes only. It’s required for compliance with browser standards and prevents disruption when your org is moved to another Salesforce instance. You can read about the impacted URLs here.
To serve an Experience Cloud site or Salesforce Site using a custom domain that you own, such as https://www.example.com, see Custom Domains in Salesforce Help.
* If your My Domain login URL ends in *.database.com or *.cloudforce.com, you must adopt the standard *.my.salesforce.com suffix as part of deploying enhanced domains.
Yes! In fact, we recommend combining these two changes. If you want to rebrand the URLs that Salesforce hosts for your org, you can combine the updates and testing for a My Domain name change and enabling enhanced domains. To make the changes together, update the My Domain name value and select the enable enhanced domains setting on the My Domain Details page and save it as one change to be provisioned and deployed.
In addition to one round of testing, this also means one change for your end-users. Most importantly, this is the best way to preserve the redirections from your Salesforce org’s current URLs. If you change your My Domain more than one time, only the last set of My Domain URLs for your org are redirected. So if you enable enhanced domains and then change your My Domain name, your original Salesforce org URLs (before the two changes) aren’t redirected.
Experience Cloud Sites & Salesforce Sites
Enhanced domains use a My Domain-based hostname for Salesforce Sites and Experience Cloud sites instead of force.com-based hostnames, and sandbox URLs contain the word “sandbox”. This doesn't apply to custom domains, which continue to be preferred. Using a custom domain, such as www.example.com, is recommended. For more information on custom domains, see Custom Domains in Salesforce Help.
Example Salesforce URLs without enhanced domains in an HTTPS non-sandbox org:
https://SalesforceSitesSubdomain.secure.force.comhttps://ExperienceCloudSitesSubdomainName.force.comExample Salesforce URLs with enhanced domains in an HTTPS non-sandbox org:
https://MyDomainName.my.salesforce-sites.comhttps://MyDomainName.my.site.comA full comparison is documented in Salesforce Help. See My Domain URL Format Changes with Enhanced Domains Deployment.
For details on the updates you may need to make to your sites when you deploy enhanced domains, see Update Your Org for My Domain Changes in Salesforce Help.
No. The *.force.com site URLs aren't compatible with third-party cookie blocking. Enhanced domains change the Salesforce-hosted URL structure to solve for this.
Yes. Use a custom domain. A custom domain is a domain that you own, such as https://www.example.com, that you use to serve your site. For more information, see Custom Domains in Salesforce Help. Salesforce highly recommends custom domains.
Yes, although there are fewer steps than if users access your site via a *.force.com domain. Most importantly, you don't need to update your domain in Salesforce Setup. Your custom domain uses your new Salesforce-hosted site URL automatically.
When you deploy enhanced domains, work with third parties that integrate with your org to ensure that they support SNI. There are also a few potential steps to take based on how your custom domain is configured. For more information, see Update Your Org for My Domain Changes in Salesforce Help.
No. Enhanced domains don't change the live.siteforce.com hostnames. Custom domains using live.siteforce.com continue to function as before when you enable enhanced domains.
To understand the reason that the user can't access the site, review the user's login history.
If the login history reflects an IP restriction: If IP restrictions are configured in Salesforce with only IPv4 addresses, users can see an error when they access your site that ends in *.my.site.com via IPv6 after you enable enhanced domains. To prevent that error, update your IP allowlists or restrictions to allow IPv6 source addresses for authorized users. In particular, review and update the login IP range restrictions for the relevant profiles, including the site's guest user profile.
If you wish to add IP ranges that cover the entire IPv4 and IPv6 Internets, add these ranges:
:: to ::fffe:ffff:ffff 0.0.0.0 to 255.255.255.255 ::1:0:0:0 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
For more information on setting IP restrictions Salesforce, see Network Access, Session Settings, and Profile-based IP restrictions.
If the user is experiencing authentication issues, see Update Your Org for My Domain Changes in Salesforce Help.
Review potential domain restrictions. For Experience Cloud sites verify that *.my.site.com is allowed.
For more information, see the Knowledge Article, Restore Access to Sites After Enhanced Domains Auto-Deployment
Both IP allowlists and pinned certificates are methods of restricting the traffic that is allowed into your network or to connect to your servers. They're not Salesforce features, but someone at your organization may use them to secure your network. If you’re unsure whether your company or network uses these methods, check with your IT or Information Security (InfoSec) department.
An Internet Protocol (IP) allowlist includes the addresses that are allowed to access the network. Connections from IP addresses not on the list are rejected. For the list of IP addresses to allow, see the Salesforce Knowledge Article, Salesforce IP Addresses and Domains to Allow.
For the areas within Salesforce where you can restrict access by IP address, see Network Access, Session Settings, and Profile-based IP restrictions.
At a very high level, certificate pinning restricts which certificates are considered valid for a website. The website can have multiple valid certificates, but certificate pinning only lets you connect using some of them. Generally speaking, Salesforce doesn’t recommend certificate pinning. If your company requires the use of certificate pinning, check to see which type of pinning is used. Salesforce doesn’t recommend pinning leaf certificates.
After I updated my custom domain's proxy or CDN to point to the new site URL ending in *.my.site.com or *.my.salesforce-sites.com, users see an SSL connection error.
Example format of the error:SSL Connection ErrorError 26[custom domain URL][time stamp ]What happened?The proxy failed to connect to the web server, SSL connection failed.
This error indicates an issue completing a valid SSL handshake with the origin server.
The most common cause that we've seen for this issue is an update of the Host HTTP header value or proxy server to point to the MyDomainName.my.site.com or MyDomainName.my.salesforce-sites.com URL. To use an external option, configure your proxy or CDN service so that the requests sent to Salesforce contain the originally requested Host HTTP header instead. For
Troubleshooting steps:
Other Product- or Feature-Specific Questions
If your knowledge article links use the *.lightning.force.com or *.my.salesforce.com domain, those domains don't change in production orgs when you deploy enhanced domains. In a sandbox, the word “sandbox” is added to those URLs.
If your knowledge article uses your Experience Cloud site *.force.com URL, the knowledge article uses your new *.my.site.com URL, and you must update all hard-coded references to those URLs.
If your Account Engagement configuration uses the Connector User and your org's login URL changed, the login URL that Account Engagement uses behind the scenes must be updated. To force this update, within Account Engagement, update the Connector User. You can use the same user, but you must save the user again in Account Engagement. Then log out and back in to your org to complete the process.
If you’re using the Account Engagement Integration User, no changes are needed.
Note: No change to the Account Engagement tracker domain configuration is required when you deploy a My Domain or enable enhanced domains. Likewise, no change to the Connector User is required if you enable enhanced domains on an existing My Domain, because that doesn’t change the login URL.
As with all features, we recommend that you test in a sandbox environment. In particular, look for hard-coded URLs. For more information, see the Knowledge Article, Updating Hard-Coded References. For more information on the various areas to update in your org, see Update Your Salesforce Org for Your New Domain in Salesforce Help.
There are two possible areas of impact: the enablement site (myTrailhead) login URL and their badge art.
Badge Art
When you deploy enhanced domains, the URLs for content (files) stored in Salesforce change. If your badge art is stored in Salesforce, update your modules and trails with the new badge art URLs. For more information, see Configure Your Enablement Site in Salesforce Help.
Enablement Sites (previously myTrailhead) login URL
When you configure enablement sites, you have the option to use your My Domain login URL or site URL as your enablement site (myTrailhead) login URL.
*.force.com site URL as your enablement site login URL, the *.force.com URL changes with enhanced domains. Contact Salesforce Customer Support to update your enablement sites (myTrailhead) login URL after you deploy enhanced domains.The webto.salesforce.com hostname remains the same with and without enhanced domains.
For information on updating your package to use the System.DomainCreator Apex class, see Link to Salesforce Domains in Packages in Salesforce Help and Call Salesforce URLs Within a Package in the ISVforce Guide.
For details on enhanced domains and how to enable the feature, see Enhanced Domains in Salesforce Help and these two webinars:
Other Questions
For the recommended adoption order, benefits of each enhancement, and where to get more information on each of these enhancements, see the Knowledge Article, Recommended Adoption Order for MFA, Enhanced Domains, and Hyperforce.
If enhanced domains aren’t deployed and Salesforce deploys the feature with Spring ’23, admins see the banner when they log in. If the option Automatically deploy enhanced domains with Spring ’23 is disabled, the banner no longer displays.
To close the banner in Lightning Experience, an individual user can click the X. The banner is persistent in Salesforce Classic.
For the announcement about the banner, see the Winter ’23 Release Note: Other My Domain Changes.
No, enhanced domains do not change the IP range for the org. However, an eventual Hyperforce upgrade for the org will essentially remove support for IP address allowlists. We do not recommend using IP allow-listing. We recommend that you read this article; especially the first several paragraphs, and move toward allowing the required domains.
| Date | Revision |
|---|---|
| November 22, 2022 | Initial article publication |
| November 29, 2022 | Added two questions: |
| December 5, 2022 | Added How do enhanced domains impact enablement sites (myTrailhead)? |
| December 7, 2022 | Minor updates to What are some common issues that arise after deploying enhanced domains? |
| December 17, 2022 | Added links to the Enhanced domains video (available in English only). |
| December 19, 2022 | Added Do enhanced domains impact existing API integrations? |
| January 9, 2023 |
|
| January 18, 2023 | Added What’s the recommended order for adopting MFA, enhanced domains, and Hyperforce? |
| January 23, 2023 | Added How can I restore the authentication providers on my login page? |
| January 25, 2023 | Added Enhanced domains are already enabled in my org. Who did that? And does that mean that I'm done? |
| February 18, 2023 |
|
| March 3, 2023 | Updated If I find an issue during testing, can I disable enhanced domains? Added a link to the KA Disable Enhanced Domains. |
| March 15, 2023 | Updated After deploying enhanced domains, some users can’t access my Experience Cloud site
|
| April 28, 2023 | Updated What's the impact of enhanced domains on orgs that use the cloudforce.com or database.com suffix? to clarify that those URLs are redirected like other previous My Domain URLs. |
| May 15, 2023 | Added I enabled redirection logging. How can I identify where the link lives that the user clicked before they were redirected? |
| June 26, 2023 |
|
| October 23, 2023 | Updated Will my old URLs be redirected? to reflect that we use 307 redirect codes, not 308. |
| July 12, 2024 |
|
| August 7, 2024 |
Added the question, Does redirection logging capture attempts to access a legacy domain that's no longer redirected? Updated the following questions to reflect the new timeline for the end of redirections for legacy (non-enhanced) domains.
Updated all links to My Domain URL Format Changes When You Enable Enhanced Domains to reflect the updated Help topic title in Winter '25, My Domain URL Format Changes with Enhanced Domains Deployment. |
| August 28, 2024 |
Added the question, How can I disable legacy redirections in my production or demo org? Updated these questions to reflect that legacy hostname redirections end in Spring '25, not Winter '25, in demo orgs. |
| December 8, 2024 |
Updated the introduction for this Knowledge Article and these questions to reflect that legacy hostname redirections end with the enforcement of the Update References to Legacy Host Names release update, which is introduced in Spring '25:
Updated these questions to use the past tense when referring to the end of redirections in Winter '25:
Added the question, Why did Salesforce delay the end of legacy redirections for production orgs? |
| December 13, 2024 |
Updated the introduction for this Knowledge Article and these questions to reflect that the Update References to Legacy Host Names release update, which is introduced in Spring '25, is enforced in Spring '26: |
| April 11, 2025 |
Added this question for the Update Instanced URLs in API Traffic release update, to be introduced in Summer '25: Do redirections stop in API traffic, too? Updated these questions for the Update Instanced URLs in API Traffic release update, to be introduced in Summer '25.
Removed references to "future" Help updates that are now complete: |
| December 19, 2025 |
Added these questions:
In these sections and questions, removed references to previous releases and clarified the updated timeline for the support of incorrect instanced URLs in API calls:
Other Changes:
|
| March 26, 2026 |
|
000393816

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.