Configure Network Access for Hyperforce: IP Allowlisting, IPv6, and mTLS

Cause

Why Hyperforce IP Ranges Are Different

Hyperforce is hosted on public cloud infrastructure (AWS, Azure, GCP) with dynamically assigned IP ranges. Unlike classic Salesforce instances with relatively stable IPs, Hyperforce IP ranges can change without advance notice. Additionally, Hyperforce public IP ranges now include both outbound (Salesforce-to-customer) and inbound (customer-to-Salesforce) address blocks — both of which must be accounted for in your network configuration.

Why IPv6 Is Required

Hyperforce uses both IPv4 and IPv6 addresses. Firewalls and allowlists that block or do not explicitly permit IPv6 traffic will prevent connectivity to Hyperforce orgs even if all IPv4 ranges are correctly allowlisted. This is one of the most common causes of post-migration connectivity failures.

Common symptom of a missed IPv6 allowlist: Connectivity works from your corporate office but fails for remote or VPN users on ISPs that prefer IPv6 routing.

Why IP Allowlisting Is Complex for Edge Network Traffic

The Salesforce Edge Network uses Anycast DNS to route traffic to the nearest geographic network location. This means the IP address a user or integration observes when connecting to Salesforce changes based on their location and is not representative of the full range of IPs in use. Standard IP allowlisting does not work reliably for Edge Network traffic. Domain allowlisting or mTLS is required for any Edge-routed connectivity.

Choosing the Right Network Access Approach for Hyperforce

Before following the steps below, use this table to identify which approach applies to your situation:

Your Situation	Recommended Approach
New Hyperforce org, no legacy firewall rules	Domain allowlisting + mTLS
Existing org migrating from classic instance	Update IP allowlist to Hyperforce JSON + add IPv6
API integrations from your servers to Salesforce	Outbound IP allowlist from JSON file
Salesforce calling back to your servers (webhooks, callbacks)	Inbound IP allowlist from JSON file
Using Salesforce Edge Network	Domain allowlisting only — IP allowlisting will not work
Named Credentials calling external endpoints	Update the external endpoint's allowlist with new Hyperforce outbound IPs
Regulated industry requiring IP-based controls	IP allowlist + IPv6 + automate JSON file refresh
Government Cloud org (USA-GOV or similar instance prefix)	Contact your Account Executive — standard JSON file does not apply

Step 1: Obtain the Current Hyperforce IP Ranges

The only accurate, up-to-date source for Hyperforce IP ranges is the Hyperforce IP ranges JSON file

Direct URL: https://ip-ranges.salesforce.com/ip-ranges.json

The JSON file includes separate blocks for outbound and inbound addresses. Do not use static IP lists from older documentation or point-in-time exports — Hyperforce IPs change without advance notice.

If you use infrastructure-as-code tooling (Terraform, Ansible, or similar), automate consumption of this JSON file rather than hard-coding values. A hard-coded snapshot will become stale and cause connectivity failures when IP ranges are updated.

For the full list of IP ranges with additional context, see Hyperforce IPs to Allow (003876184).

If you need Europe-specific IP ranges (for example, for GDPR or regional compliance), use the RIPE-labeled section of the JSON file. Salesforce Support can confirm the specific section applicable to your instance.

Note: The Edge Network is automatically enabled for Hyperforce orgs to optimize performance. To check whether your org uses the Edge Network, go to Setup > My Domain and review the routing settings.

Step 2: Include IPv6 Addresses in Your Allowlist

Add the IPv6 address blocks from the Hyperforce IP JSON file to your firewall rules alongside the IPv4 blocks. Do not configure IPv4-only allowlists for Hyperforce orgs — this is one of the most common causes of connectivity failures after migration.

Before updating your allowlist, explicitly verify the following:

Your firewall ruleset has IPv6 enabled — not just IPv4 with an assumed pass-through for IPv6 traffic
You are not running a dual-stack configuration that silently drops IPv6 on the egress outbound path
If you use a proxy server for outbound Salesforce traffic, confirm the proxy supports IPv6 forwarding — many enterprise proxy servers are IPv4-only by default and will drop IPv6 traffic silently
If you use a VPN, confirm the VPN split-tunnel configuration passes IPv6 traffic to Salesforce domains

Common diagnostic: If connectivity works from your corporate office but fails for remote workers or VPN users, a missing IPv6 allowlist on the proxy or VPN is the most likely cause. Test by temporarily disabling the VPN for an affected user and retesting connectivity directly.

Step 3: Configure Inbound IP Allowlisting (Customer-to-Salesforce traffic)

Hyperforce public IP ranges now include inbound address blocks for traffic directed to your Salesforce org. If your security architecture restricts inbound traffic by IP, add the inbound IP blocks from the JSON file.

Step 4 (Preferred): Adopt mTLS or Domain Allowlisting Instead of IP Allowlisting

Salesforce recommends transitioning to modern security approaches rather than maintaining IP allowlists for Hyperforce, because IP ranges are dynamic and can change without advance notice.

Preferred alternatives include:

mTLS (Mutual TLS) — Recommended for API and integration security
Certificate-based authentication that validates both the client and server identity, independent of IP addresses. To configure mTLS for Hyperforce:

Go to Setup → Mutual Authentication
Upload a CA-signed certificate for your integration endpoint
Configure Salesforce to validate the client certificate on inbound API calls

See Set Up Mutual Authentication for the full setup guide.

Domain Allowlisting — Recommended for firewall rules
Allow traffic to and from Salesforce domain names rather than IP addresses. Salesforce domain names are stable even as underlying IPs change. When configuring domain allowlisting:

Allow outbound traffic to *.salesforce.com and *.force.com on port 443 (HTTPS)
For Salesforce API access, also allow *.my.salesforce.com
Do not restrict by IP for these domain patterns — use FQDN-based (fully qualified domain name) firewall rules

See Set Trusted IP Ranges for Your Org for guidance on network access configuration options.

Step 5: Understand Edge Network Connectivity

If your org uses the Salesforce Edge Network, do not attempt to allowlist by IP for Edge-routed traffic. The Edge Network uses Anycast DNS — the IP addresses users observe when connecting to Salesforce vary by geographic location and do not represent the full routing path. Configuring an IP allowlist for Edge traffic will be incomplete regardless of how many IP ranges you add.

For Edge Network traffic, use domain allowlisting or mTLS only.

The Edge Network is automatically enabled for Hyperforce orgs to optimize performance. To check whether your org uses the Edge Network, go to Setup > My Domain and review the routing settings.

Step 6: Verify Named Credentials and External Credential Callouts After Migration

If your Salesforce org uses Named Credentials or External Credentials to call out to external endpoints, you must verify those external endpoints after a Hyperforce migration.

Named Credentials pass outbound API traffic through Salesforce's egress IP addresses. When your org migrates to Hyperforce, these egress IPs change. If the external endpoint your Named Credential calls has an IP allowlist, it will block post-migration callouts — typically resulting in a connection timeout or 403 Forbidden error on the Named Credential.

To resolve:

Download the current Hyperforce outbound IP ranges from https://ip-ranges.salesforce.com/ip-ranges.json
Provide the outbound IP blocks to the administrator of the external endpoint
Have them update the external endpoint's allowlist to include the new Hyperforce ranges
Test the Named Credential from Setup → Named Credentials using the Test option

Note: This applies to any external system that Salesforce calls outbound — REST APIs, SOAP services, external authentication providers, and event notification endpoints.

FAQ

My integrations stopped working after our Hyperforce migration even though I allowlisted the IP ranges from the old article. What happened?
Classic instance IP ranges are not valid on Hyperforce. You must download and apply the current Hyperforce IP ranges from the JSON file at https://ip-ranges.salesforce.com/ip-ranges.json. The two most common causes of this failure are: (1) the allowlist was updated with classic instance IPs rather than Hyperforce IPs, and (2) IPv6 addresses were not included. Hyperforce connectivity requires IPv6 in addition to IPv4 — an IPv4-only allowlist will cause intermittent or complete connectivity failures depending on how traffic is routed.

Why do I see different IP addresses when I ping my Salesforce instance from different locations?
If your org uses the Salesforce Edge Network, this is expected behavior. The Edge Network uses Anycast DNS to route each request to the nearest geographic network point-of-presence. The IP address you observe when pinging your Salesforce domain depends on your geographic location and changes as routing conditions change. This is not a misconfiguration and is not a problem to solve with IP allowlisting. Use domain allowlisting or mTLS for any network access controls on Edge-routed traffic.

How do I know if my org is on Hyperforce?
Go to Setup → Company Information and check the instance name. Hyperforce instances follow naming patterns such as USA1xxx, AUS1xxx, DEU1xxx, GBR1xxx, IND1xxx. For the most authoritative confirmation, check the Salesforce Trust site, search for your instance, and confirm its platform is listed as Hyperforce.

Note: If you have a custom My Domain and cannot identify your instance name from Setup, go to Setup → My Domain and look at the domain routing details, or contact Salesforce Support to confirm your instance.

Do I need to update my allowlist every time Salesforce updates its IP ranges?

Yes, if you maintain IP-based allowlists for Hyperforce. Salesforce updates the IP ranges JSON file periodically. Here is what you need to know to stay current:
Salesforce adds and modifies IP addresses in the JSON file at least 30 days before those IPs are put into use. You have a guaranteed 30-day window to update your firewall rules after a change is published.

How to detect changes
When Salesforce updates the IP list, the publication date inside the JSON file changes. To track updates:

Save a local copy of the JSON file each time you download it
On your next scheduled poll, compare the publication date of the newly downloaded file against your saved copy
If the publication date has changed, review the delta and update your allowlist accordingly

The JSON file categorizes IPs by region and infrastructure provider. At this time, the provider for instances on Hyperforce is AWS. Customers are advised to allow all the IPs in the file. If you only allow the ranges in your country or region, you will block incoming traffic from users in other locations. At this time, the provider for instances on Hyperforce is AWS. This may expand as Hyperforce evolves.

Do I need to allowlist IPs for the Salesforce Edge Network?
No. The Salesforce Edge Network uses Anycast DNS, which means IP-based allowlisting is not a viable approach for Edge traffic. Use domain allowlisting (*.salesforce.com, *.force.com, *.my.salesforce.com on port 443) or mTLS instead. Attempting to maintain an IP allowlist for Edge Network traffic will result in an incomplete ruleset that breaks whenever Anycast routing changes.

My org is in a regulated industry and we are required to use IP allowlisting. What should we do?
If IP-based allowlisting is a compliance requirement, implement the following:

Download and apply the full Hyperforce IP JSON file including both IPv4 and IPv6 blocks
Include both inbound and outbound IP blocks if your architecture involves Salesforce calling back to your systems
Automate refresh of the JSON file on a regular schedule (weekly or triggered by a change notification)
Layer mTLS on top of IP allowlisting as an additional control — mTLS provides stronger authentication guarantees than IP allowlisting alone and satisfies most regulatory requirements that mandate IP restrictions