QuotaGuard gives your MCP server two fixed egress IPs, so calls into the Salesforce API clear Network Access restrictions instead of getting rejected at the network layer.
Salesforce's Network Access controls, set under Setup, let admins restrict API access to specific trusted IP ranges. An MCP server calling Salesforce from a cloud platform with a rotating IP fails that check the moment a security-conscious admin turns the restriction on, regardless of how valid the connected app's credentials are.
Register your two QuotaGuard IPs in Network Access once and the restriction stops being the reason your integration breaks.
Salesforce gives admins two separate levers for IP-based restriction, and an MCP server calling the API can hit either one depending on how the org is configured.
Network Access, configured under Setup > Security, lets admins define trusted IP ranges for the whole org. Login and API calls from outside those ranges can be challenged or blocked entirely, depending on the profile and session settings applied.
Each Connected App carries its own IP relaxation setting: enforce IP restrictions, relax them, or require an activation code from an unrecognized IP. An MCP server authenticating through a Connected App can be blocked by this setting even if Network Access itself looks permissive.
A Connected App's OAuth token can authenticate successfully and still get the request rejected once the IP restriction check runs. The failure looks like a permissions problem right up until the response names the IP.
Whether the block comes from org-wide Network Access or a Connected App's own IP relaxation setting, the underlying cause is identical: the MCP server doesn't have a fixed address to register.
Lambda, Cloud Run, Render, and most container platforms reassign the outbound IP on redeploys and scaling events. A trusted range or Connected App entry written for last week's IP fails silently the next time the platform rotates.
Salesforce's Connected App setting can require an email-based activation code for unrecognized IPs. That flow assumes an interactive human session; it isn't a workable pattern for an MCP server making unattended, repeated calls.
Admins who care about API security lean toward enforcing IP restrictions on Connected Apps rather than relaxing them, which means the gate an MCP server hits here tends to correlate with exactly the orgs worth building the integration for.
One fixed pair of IPs satisfies both restriction layers at once. QuotaGuard Static covers this for most MCP deployments; Shield is the call when the Salesforce data itself is regulated.
Point your MCP server's outbound HTTP client at your QuotaGuard proxy URL. Both static IPs go live behind a load balancer immediately, and you add them to Network Access trusted ranges and the Connected App's allowed IP list once.
If your HTTP client supports per-host proxy configuration, send only calls to your Salesforce instance's API hostname through QuotaGuard. Everything else your MCP server does goes direct, keeping unrelated traffic fast and easy to debug.
QuotaGuard Static and Shield both carry outbound HTTPS through a blind CONNECT tunnel and never decrypt the payload. Shield adds a TLS-encrypted customer-to-proxy hop, the right call if your MCP server's Salesforce records include PHI, payment data, or anything under a HIPAA, PCI-DSS, or SOC 2 requirement.
Common questions about Salesforce MCP static IPs and QuotaGuard. See the MCP server static IP overview for how this gate shows up across other enterprise systems.
Does my MCP server definitely need a static IP for Salesforce?
Only if the org has Network Access trusted ranges configured, or the Connected App you're authenticating through enforces IP restrictions. Both are standard, admin-configurable Salesforce security controls under Setup, not exotic settings.
What's the difference between Network Access and Connected App IP restrictions?
Network Access is an org-wide trusted IP range setting under Security. Connected App IP relaxation is a separate, app-specific setting with three modes: enforce restrictions, relax them, or require an activation code from unrecognized IPs. An MCP server can be blocked by either one independently.
How long does setup take?
About two minutes. Set your QuotaGuard proxy URL as the environment variable your MCP server's HTTP client reads, then add both static IPs to Network Access and the Connected App's IP settings. No code changes beyond the proxy configuration.
Can I just use the activation code workaround instead of a static IP?
Not for an MCP server making unattended calls. The activation code flow sends a code to an email address for confirmation, which assumes an interactive human session. It isn't a workable pattern for repeated, automated server-to-server calls.
Static or Shield for a Salesforce MCP server?
Static is the right default. Use Shield if your MCP server's Salesforce records include PHI, payment data, or anything under a HIPAA, PCI-DSS, or SOC 2 requirement, since Shield keeps the customer-to-proxy hop TLS-encrypted instead of plaintext.
Will my static IPs change if I redeploy or upgrade my plan?
No. Your two static IPs stay fixed through redeploys, scaling events, and plan upgrades or downgrades, so the Network Access and Connected App entries you set once keep working without re-registration.
Can I get a dedicated IP for my Salesforce MCP server instead of a shared pair?
Dedicated IPs are available on Enterprise plans and above, provisioned on request rather than automatically. The standard shared, load-balanced pair is sufficient for most Salesforce MCP deployments since it's fixed and clears both restriction layers the same way.
For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.
Get the fixed identity and security your application needs today.