Considerations for Custom Domains That Use a Third-Party Service or CDN
Review how IP address tracking works when a third party serves your custom domain. Understand what happens if you update your domain’s external configuration after you activate the domain in Salesforce, and clean up unnecessary Domain Name Service (DNS) records.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: Enterprise, Performance, and Unlimited Editions. |
| Applies to: Salesforce Sites and LWR, Aura, and Visualforce sites |
IP Address Tracking and Restrictions
When you use a third party to serve your domain, Salesforce uses and logs the source IP address from the TCP/IP connection to Salesforce.
The True-Client-IP request header is used for location-targeting features
within an Experience Cloud site. If you use an external content delivery network (CDN) and
location-based audience targeting in Experience Cloud, set this header in your CDN. For more
information, see Prerequisites for a Custom Domain That Uses a Third-Party Service or CDN.
IP restrictions at the profile level ignore the True-Client-IP request
header for custom domains served by an external service or CDN. To restrict your guest
users’ access to valid IP addresses for your custom domain, set the profile-level IP
restrictions to allow only the IP addresses for your CDN or reverse-proxy server. For
example, allow the addresses that your CDN uses to connect to Salesforce.
Other source IP address request headers, such as the X-Forwarded-For (XFF) request header, are ignored. As a result, you can't pass the original source IP address to Salesforce for use with profile IP range restrictions, login history source IP addresses, and event log lines.
Third-Party Changes After Domain Activation
Salesforce validates that your domain points to your org when you add or view your domain in Salesforce. If you update your proxy, web application firewall (WAF), CDN, or the third-party settings after you activate the domain, that change happens outside Salesforce. As a result, Salesforce continues to serve the domain as if it uses HTTPS, even if the third-party configuration doesn’t have a valid HTTPS certificate for your custom domain. In this situation, your custom domain can experience disruption.
If you suspect this cause for a disruption, view your custom domain details to validate that your domain points to your org.
DNS Records to Validate Domain Ownership
When you add your domain, Salesforce checks DNS to validate that you own the domain. To pass this verification, you add a canonical name (CNAME) or text (TXT) record for your domain in DNS. After you configure your domain that uses a third-party service or CDN, you can delete the TXT or CNAME record. Deleting unnecessary DNS records can improve performance. Optionally, to make it easier to switch to another domain configuration option in the future, you can keep the CNAME record in DNS. If you choose to keep the record, check with your third-party provider to ensure that their services are supported with that configuration.
Streaming API Features Send CometD HTTP Requests
If your third-party Experience Cloud site includes features that call the Streaming API, the API sends HTTP POST requests to your third-party content delivery network (CDN), not to Salesforce. CDNs have request rate limits, which can be exceeded when your site has many active users at the same time. For more information, see Streaming API Developer Guide: Using an Experience Cloud Site with Streaming API-Based Features.
