This article lists the domains Beamery needs to reach from your corporate network, and how to configure your web gateway, proxy, CASB (Cloud Access Security Broker) or browser policy so every part of the platform works. It's written for IT, network and security teams, and for the Beamery admins who work with them.
Why does this matter?
Corporate security tools can block one Beamery feature while the rest of the platform works normally. When that happens, your users don't see a "blocked" message. They see a generic error, a button that does nothing when clicked, broken images, or a browser "CORS" error. It looks like a Beamery bug, but the cause is a network or browser rule.
A few examples of what a single blocked domain causes:
Bulk messaging fails with "There was an error sending the email, please try again later" when mail.beamery.com is blocked.
Image and logo uploads stop working, often as a "Choose" button that does nothing, when the file upload service is blocked.
Image upload in the campaign email builder fails with "Offline mode is enabled" when the email editor's service is blocked.
Allowing the domains below up front prevents these failures, and saves your users and your IT team the troubleshooting.
Please note that Beamery cannot see or work around these blocks. The request is stopped on your network or in the browser before it reaches Beamery, so it never appears in our logs. Only your IT or security team can lift it.
Who does this apply to?
Any organization whose users reach Beamery through a secure web gateway, forward proxy, CASB policy, URL-category filter, endpoint security product, or a managed browser policy (for example, Microsoft Edge Tracking Prevention set by IT).
The changes are made by your IT or security team in those tools. There's nothing to change inside Beamery, and no Beamery permission is required.
How do I configure our network for Beamery?
Rules that apply to every domain in this article
Allow HTTPS on port 443.
Permit the OPTIONS method, not just GET and POST. Browsers send an OPTIONS "preflight" request before many API calls. Blocking the preflight alone is enough to break a feature.
Exclude the domains from CASB or cloud service control category blocks (for example "Webmail", "File storage" or "File sharing"). CASB rules are evaluated separately from URL allowlists, so allowing a URL does not lift a CASB block on its own.
If you use TLS/SSL inspection, add the domains to your bypass list.
Apply the exceptions to every policy set your users fall under, including on-premises and roaming or VPN clients.
Use wildcards where your tooling supports them. They keep working when a service adds or changes a subdomain.
Beamery domains
Allow all Beamery subdomains:
*.beamery.comThe platform relies on several Beamery subdomains. Allowing them one at a time tends to cause new failures as features change, so we recommend the wildcard rather than individual hosts.
About mail.beamery.com
Some gateways categorize mail.beamery.com as a consumer webmail service and block it. That categorization is incorrect:
mail.beamery.com is not a webmail service, and users never visit it directly. It is a Beamery API endpoint.
When a user sends an email or bulk message from Beamery, the platform sends the request to this endpoint, and Beamery's mail service processes and delivers the message. The browser does not send any email itself.
It is part of the standard Beamery platform covered by your existing subscription. There is no separate configuration for users to set up and no separate agreement.
Make sure mail.beamery.com (or *.beamery.com) is excluded from any CASB "Webmail" ruleset as well as allowed on your URL filter.
File and image upload (Filestack)
Beamery uses Filestack, a third-party service (formerly called Filepicker), for file upload and image delivery. If it's blocked, these areas are affected:
Company logo upload in Company Settings
Image upload and image blocks in Pages and Event Pages
Image upload in Convert flows and forms
Viewing campaign touchpoints and stored image assets
Any other file chooser in the platform
Allow these wildcards:
*.filepicker.io
*.filestackapi.com
*.filestackcontent.comMany web filters classify these domains as "online file storage" or "file sharing." Exclude them from that category block as well as allowing them.
Please note that allowing filepicker.io alone is NOT enough. Upload, the file chooser dialog, image processing and image delivery each use different hosts. This is the most common reason a team reports "we already allowed Filestack and it still fails."
If your tooling does not support wildcards, allow each of these hosts:
filepicker.io
www.filepicker.io
dialog.filepicker.io
assets.filepicker.io
cdn.filepicker.io
filestackapi.com
www.filestackapi.com
static.filestackapi.com
upload.filestackapi.com
cloud.filestackapi.com
cdn.filestackcontent.comFilestack may use regional upload endpoints that are not on this list, which is why we recommend the wildcards.
Campaign email builder (Unlayer)
The campaign email builder in Beamery is Unlayer, a third-party editor. An exception for *.beamery.com does not cover it, so allow it separately:
*.unlayer.comOr, if you need individual hosts:
Host | Methods | What happens if it's blocked |
|---|---|---|
| GET | The campaign email builder may not load. |
| OPTIONS, POST | Image upload in the campaign builder fails with "Offline mode is enabled." |
| POST | Editor events. No user-facing impact confirmed. |
Please note that Microsoft Edge can classify Unlayer's hosts as trackers and block them inside the browser through Tracking Prevention. Add the exception to Edge Tracking Prevention (or the policy that manages it) as well as to your network rules.
Other third-party services
| Hosts | Purpose | What happens if they're blocked |
|---|---|---|
| Feature flags | Features can stop working outright. Allow these. Do not treat them as optional. |
| SMS (TextRecruit) | SMS stops working, where SMS is enabled. |
| In-app guidance | In-app guides and walkthroughs don't appear. |
| Support widget | The in-app support widget is unavailable. |
| Error monitoring | No visible change for users, but Beamery can't see errors your users hit, which slows down troubleshooting. |
| Web fonts | Text displays in fallback fonts. |
| Location features | Location pickers don't work as expected. |
| Performance monitoring | No visible change for users. |
How do I confirm a block is the cause?
If one feature fails for your users but works for Beamery Support, check these in order:
Test off the corporate network. Have the affected user try the same action on a personal device or guest Wi-Fi, with the VPN off. If it works there, the cause is a network rule.
Check the browser. Click the "Blocked content," shield or tracking icon in the address bar. In Edge, this lists blocked hosts. If a host from this article appears, add a Tracking Prevention exception. Please note that InPrivate and Incognito windows do not rule this out, since Edge applies Strict tracking prevention in InPrivate by default.
If you've already allowed a domain and it still fails, confirm the exception covers the CASB policy (not only the URL category), covers every host in the relevant section above, applies to every policy set (on-premises and roaming), and includes the browser as well as the network.
What's next?
You should now be able to give your IT or security team everything they need to allow Beamery on your network. Share this article with them directly.
If a feature still fails after the changes, contact Beamery Support and include a HAR file and the browser console log captured while reproducing the problem. In Chrome: open DevTools, go to the Network tab, tick Preserve log, reproduce the error, then right-click and choose Save all as HAR with content. The HAR shows Support exactly which host was blocked and by which product.