How I solved mandatory IP Allowlisting on Marketing Cloud Engagement as a freelancer

· 12 min read

EN · ES · CA

A step-by-step guide for consultants who work across several MCE instances, with a dynamic IP, from anywhere.

Why I needed this

Salesforce is making IP Allowlisting in blocking mode (Log Violations and Deny Access) mandatory for every Marketing Cloud Engagement account. It applies to both UI login and API access, there is no opt-out, and it is being rolled out in waves until January 2027. Each account receives an email with its own date. Some accounts go live on October 15, 2026.

On that date, Salesforce applies a baseline list of IP ranges based on the successful logins of the last six months. If you log in from an IP that is not on the list, you are blocked.

That is a real problem if you:

  • work with several clients, each with their own MCE account,
  • have a dynamic IP at home,
  • want to work from a hotel, an airport or a co-working space,
  • and don't want to depend on each client's corporate VPN.

My goal was simple: one fixed IP that I can give to every client, that works from anywhere, and that only affects Marketing Cloud traffic.

The solution in one picture

Laptop ──(WireGuard)──> EU server, fixed IP ──> Marketing Cloud
   │
   └──(direct)──> Everything else (Salesforce core, YouTube...)
  • A small cloud server in the EU with a fixed public IPv4.
  • A private WireGuard tunnel between my laptop and that server.
  • A small proxy on the server, only reachable from inside the tunnel.
  • A PAC file that tells the browser: Marketing Cloud domains go through the proxy, everything else goes direct.
  • Postman and API scripts use the same proxy.

The result: Marketing Cloud always sees the same IP. My normal browsing, video calls and core Salesforce orgs keep using my normal connection.

Before you start

Why not a commercial VPN? Shared VPN IPs change and are used by thousands of people. Adding them to an allowlist defeats the purpose. Since April 2026, Salesforce core also blocks connections from anonymizing VPNs and high-risk IPs, and can freeze the user. With this setup, core traffic never goes through the server, so that risk doesn't apply.

What you need:

  • A Mac or a Windows PC. I set this up on a Mac, so the main steps use macOS. The server part is the same for any system, and there's a section with the Windows equivalents after step 6.
  • About two hours.
  • A cloud provider account. I used Hetzner Cloud (Germany). OVHcloud or Scaleway work too. Pick a server in the EU if your clients care about GDPR.
  • Basic comfort with the Terminal.

Cost (October 2026): the smallest server I could get was around €14.50/month including VAT (server plus IPv4), billed by the hour, no commitment. As a freelancer, it's a business expense. Cheaper plans exist but were out of stock when I set this up.

Step 1. Create an SSH key on your Mac

In the Terminal:

ssh-keygen -t ed25519 -C "you@yourdomain.com"
cat ~/.ssh/id_ed25519.pub
  • Press Enter to accept the default location. If it asks to overwrite an existing key, answer n and just use the existing one.
  • Use a passphrase and save it in your password manager.
  • Copy the line that starts with ssh-ed25519. This is the public key; it's safe to share. The private key never leaves your Mac.

To avoid typing the passphrase every time:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Step 2. Create the server

In your provider's console:

  1. Type: the smallest shared vCPU plan. You don't need dedicated CPU; WireGuard uses almost nothing.
  2. Location: EU.
  3. Image: Ubuntu LTS.
  4. Networking: enable a public IPv4. This is the IP you will give to your clients.
  5. SSH key: paste your public key.
  6. Create the server and write down its IPv4.

Then, two important settings:

  • Firewall: create one that only allows inbound TCP 22 (SSH) and UDP 51820 (WireGuard), and apply it to the server.
  • Protect the IP: enable deletion protection on the IPv4, and if your provider offers it, disable auto delete. If the IP changes, you have to ask every client to update their allowlist.

Also enable two-factor authentication on your provider account and keep the recovery codes safe. Whoever controls this account controls the IP your clients trust.

Step 3. Configure the server

Connect from your Mac:

ssh root@YOUR_SERVER_IP

Then paste this whole block. It installs WireGuard and the proxy, applies basic hardening, and prints the configuration for your laptop at the end.

export DEBIAN_FRONTEND=noninteractive
apt update && apt -y upgrade
apt -y install wireguard tinyproxy unattended-upgrades
dpkg-reconfigure -f noninteractive unattended-upgrades

# SSH with keys only
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/99-hardening.conf

# Prefer IPv4 for outgoing connections (your allowlist uses the IPv4)
echo "precedence ::ffff:0:0/96 100" >> /etc/gai.conf

SERVER_IP=$(curl -4 -s https://ifconfig.me)

# WireGuard keys and config
mkdir -p /etc/wireguard && cd /etc/wireguard
( umask 077
  wg genkey | tee server.key | wg pubkey > server.pub
  wg genkey | tee laptop.key | wg pubkey > laptop.pub
  cat > wg0.conf <<EOF
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = $(cat server.key)

[Peer]
PublicKey = $(cat laptop.pub)
AllowedIPs = 10.8.0.2/32
EOF
)
systemctl enable --now wg-quick@wg0

# Proxy, only listening inside the tunnel
cat > /etc/tinyproxy/tinyproxy.conf <<EOF
User tinyproxy
Group tinyproxy
Port 8888
Listen 10.8.0.1
Timeout 600
LogLevel Info
MaxClients 50
Allow 10.8.0.0/24
ConnectPort 443
EOF
mkdir -p /etc/systemd/system/tinyproxy.service.d
printf "[Unit]\nAfter=wg-quick@wg0.service\nRequires=wg-quick@wg0.service\n" \
  > /etc/systemd/system/tinyproxy.service.d/override.conf

# PAC file, served only inside the tunnel
mkdir -p /srv/pac
cat > /srv/pac/mc.pac <<'EOF'
function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, ".exacttarget.com") ||
      dnsDomainIs(host, ".marketingcloudapis.com") ||
      dnsDomainIs(host, ".marketingcloudapps.com") ||
      dnsDomainIs(host, ".exct.net")) {
    return "PROXY 10.8.0.1:8888";
  }
  return "DIRECT";
}
EOF
chmod 755 /srv/pac && chmod 644 /srv/pac/mc.pac

cat > /etc/systemd/system/pac-server.service <<'EOF'
[Unit]
Description=PAC file server
After=wg-quick@wg0.service
Requires=wg-quick@wg0.service

[Service]
ExecStart=/usr/bin/python3 -m http.server 8080 --bind 10.8.0.1 --directory /srv/pac
User=nobody
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now tinyproxy pac-server
systemctl restart tinyproxy

echo "=========== CONFIG FOR THE WIREGUARD APP ON YOUR MAC ==========="
cat <<EOF
[Interface]
PrivateKey = $(cat /etc/wireguard/laptop.key)
Address = 10.8.0.2/32

[Peer]
PublicKey = $(cat /etc/wireguard/server.pub)
Endpoint = ${SERVER_IP}:51820
AllowedIPs = 10.8.0.1/32
PersistentKeepalive = 25
EOF

Important: the block printed at the end contains your laptop's private key. Copy it straight into the WireGuard app (next step). Don't paste it into a chat, a ticket or an email. If you do by mistake, generate a new key pair.

Once it's in the app, delete the copy from the server:

rm /etc/wireguard/laptop.key

Step 4. Set up WireGuard on your Mac

  1. Install WireGuard from the Mac App Store.
  2. Click the small arrow next to + (bottom left) and choose Add Empty Tunnel. Don't use "Import from file", that one asks for a file.
  3. Delete the default content and paste the whole block from the previous step, both the [Interface] and the [Peer] sections.
  4. Name it, enable On-Demand for Wi-Fi and Ethernet with Any SSID, and save.
  5. Activate it. If macOS asks to add a VPN configuration, allow it.

Why AllowedIPs = 10.8.0.1/32 matters: only traffic to the proxy goes through the tunnel. Nothing else. That's why it can stay on all the time without affecting your connection.

Check that it works:

curl -x http://10.8.0.1:8888 https://ifconfig.me/ip

It should return your server's IPv4. On the server, wg show should list your peer with a recent latest handshake.

Step 5. Send only Marketing Cloud through the server

On recent macOS versions, proxy settings changed from Wi-Fi → Details can stay linked to the current network only. To make it work on any Wi-Fi, set it per network interface from the Terminal.

First, list your interfaces:

networksetup -listallnetworkservices

Then apply the PAC file to the ones you use (Wi-Fi, your USB or Thunderbolt Ethernet adapter, iPhone USB...). Don't apply it to the WireGuard tunnel itself or to Thunderbolt Bridge.

for svc in "Wi-Fi" "USB 10/100/1000 LAN" "iPhone USB"; do
  sudo networksetup -setautoproxyurl "$svc" http://10.8.0.1:8080/mc.pac
  sudo networksetup -setautoproxystate "$svc" on
  echo "== $svc"; networksetup -getautoproxyurl "$svc"
done

Adjust the names to match your list. Each one should show the PAC URL and Enabled: Yes. Restart your browser (Cmd+Q).

Captive portals (hotel or airport Wi-Fi with a login page) are not a problem: until the tunnel connects, the PAC file isn't reachable and the Mac goes direct. Once the tunnel is up, Marketing Cloud goes through the server.

Step 6. Postman and scripts

Postman doesn't use PAC files. In the desktop app:

Settings → Proxy

  • Disable "Use the system proxy".
  • Enable "Use custom proxy configuration".
  • Proxy type: HTTP and HTTPS.
  • Proxy server: 10.8.0.1, port 8888 (not 8080, that's the PAC server).
  • Proxy bypass: localhost,127.0.0.1

All Postman traffic will go through the server. That's fine: the volume is tiny.

For your own scripts:

export HTTPS_PROXY=http://10.8.0.1:8888

Using Windows instead of a Mac

I set this up on a Mac. The Windows steps below follow exactly the same logic, but I haven't run them myself, so tell me if something is different on your machine. Steps 2, 3 and 8 (server and MCE) don't change.

Step 1 (SSH key). Windows 10 and 11 include OpenSSH. In PowerShell:

ssh-keygen -t ed25519 -C "you@yourdomain.com"
type $env:USERPROFILE\.ssh\id_ed25519.pub

Copy the line that starts with ssh-ed25519 and use it in step 2. To connect to the server in step 3, use ssh root@YOUR_SERVER_IP from PowerShell.

Step 4 (WireGuard).

  1. Download WireGuard for Windows from the official site, wireguard.com.
  2. Click the arrow next to Add Tunnel and choose Add empty tunnel.
  3. Delete the default content, paste the whole block from step 3 ([Interface] and [Peer]), give it a name and save.
  4. If you see the option Block untunneled traffic (kill-switch), make sure it's unchecked. Otherwise it would block everything that doesn't go through the tunnel.
  5. Click Activate. On Windows, the tunnel runs as a service and stays active after a restart.

Step 5 (PAC file). This part is easier than on a Mac, because on Windows the setting applies to all networks at once:

  1. Go to Settings → Network & internet → Proxy.
  2. Under Use setup script, turn it on.
  3. Script address: http://10.8.0.1:8080/mc.pac
  4. Save.

Chrome and Edge use this setting directly. In Firefox, check that Settings → Network Settings is set to Use system proxy settings.

Step 6 (Postman and scripts). Postman is configured exactly the same way. For scripts in PowerShell:

$env:HTTPS_PROXY = "http://10.8.0.1:8888"

Testing. In PowerShell, use curl.exe (with .exe, because curl alone can be an alias for a different command):

curl.exe -x http://10.8.0.1:8888 https://ifconfig.me/ip

It should return your server's IPv4.

Step 7. Test everything

  1. Open https://ifconfig.me in your browser. It should show your normal IP, not the server's.
  2. On the server, watch the proxy: journalctl -u tinyproxy -f
  3. Open https://mc.exacttarget.com. You should see CONNECT lines for exacttarget.com and marketingcloudapps.com domains.
  4. In Postman, GET https://ifconfig.me/ip should return the server's IP.

In MCE, the IP allowlist settings page will also show your current IP. It should be the server's.

Step 8. Add the IP to each MCE account

  • Add your server's IPv4 to the allowlist of each account, as a single-IP range (start and end the same).
  • Don't enable blocking mode yourself before your enforcement date, and don't accept the recommended ranges blindly. Salesforce asks customers to wait until after the date before changing settings.
  • On your enforcement date, check that your IP is still on the list after Salesforce applies its configuration, and check the Access Log to confirm your logins come from the server's IP.
  • For accounts managed by someone else, send their admin your IP in advance.

Plan B: if you're ever locked out

Turn off the tunnel in the WireGuard app. Without the tunnel, the PAC file can't load and your browser goes direct with your normal IP. If you've been logging in from home regularly, that IP is probably in Salesforce's baseline list. Log in, add the server's IP again, and turn the tunnel back on.

Also, ask each client to have a second admin who logs in from a fixed office IP. Being the only admin is a risk, with or without this change.

Security notes

  • Marketing Cloud traffic is already encrypted with HTTPS end to end. The server only forwards encrypted traffic; it can't read your data, and nothing is stored on it.
  • The real risk is someone taking control of the server, because its IP is trusted by your clients. That's why: SSH with keys only, firewall closed except WireGuard and SSH, automatic security updates, nothing else running on the server, and 2FA on the provider account.
  • Choose an EU location and accept your provider's data processing agreement, so you can answer GDPR questions from clients.

Things that went wrong for me (so they don't for you)

  • My traffic left through IPv6. The first test returned the server's IPv6 instead of the IPv4. The gai.conf line in step 3 fixes it.
  • The PAC file returned 404. Files created after a umask 077 were only readable by root. The chmod lines in step 3 fix it.
  • The tunnel stayed in "Restarting". When editing the tunnel, I accidentally deleted the [Peer] section. Both sections must be there.
  • Postman returned "Unsupported method CONNECT". I had used port 8080 (PAC server) instead of 8888 (proxy).
  • Proxy settings only applied to one Wi-Fi. Use networksetup per interface, as in step 5.

Final thoughts

I still believe platform security shouldn't depend on each customer's network setup, and that allowlisting should be one option among others. But enforcement is here, and with a bit of preparation it doesn't have to stop you from working.

If your account is in an early wave, don't wait until the day. Check your IP list now.

Pep Aguiló, freelance Salesforce Marketing Cloud architect, working with Marketing Cloud since 2013.

Prices and provider availability as of October 2026. This setup is what works for me; review it with your clients' security requirements in mind.

← Back to the blog