In a nutshell
- Allow the domains in the tables below, or simply
*.flowsign.appplus the third-party services. - All traffic is HTTPS on port 443. Nothing uses plain HTTP, websockets or other ports.
- If your proxy inspects TLS, its certificate must be trusted by every browser that uses Flowsign. Otherwise pages fail to load with no way to click through.
- Some web filters block the
.apptop-level domain by default. Make sure.appis allowed.
Flowsign domains
Third-party services
Flowsign works without the services marked Recommended, but blocking error reporting means we can’t see problems your team runs into. Signing pages don’t load analytics.
Ports and protocols
Every connection from the browser is HTTPS (TLS) on TCP port 443. Flowsign doesn’t need port 80, websockets, or any other port or protocol.HSTS and TLS inspection
Every.app domain is on the HSTS preload list built into Chrome, Edge, Safari and Firefox. Browsers only ever connect to flowsign.app and its subdomains over HTTPS, and they refuse the connection if the certificate isn’t valid and trusted. There’s no warning page to click past.
If your proxy or firewall inspects TLS traffic, either:
- exclude the Flowsign domains from inspection, or
- make sure the proxy’s root certificate is installed and trusted on every device and browser that opens Flowsign.
The .app top-level domain
Some web filters and DNS security services block newer top-level domains like.app by default, or put them in an “uncategorised” group. If Flowsign doesn’t load at all, check that .app, or at least *.flowsign.app, is allowed.
flowsign.app addresses, such as signing@flowsign.app and team@flowsign.app. Mail is sent through Resend, with DKIM signed for flowsign.app and a return path on send.flowsign.app.
If signing requests or notifications land in spam or quarantine, allow the flowsign.app sender domain in your email filter. Links in Flowsign emails always point to my.flowsign.app.

