On October 2, Cloudflare added email authentication to Quick Tunnels, which expose a local service through a temporary trycloudflare.com address without an account.

In cloudflared 2026.9.3 and later, --allowed-mail accepts permitted email addresses or domains. Visitors authenticate with a one-time PIN sent through Cloudflare Access.

Neither the tunnel creator nor the visitor needs a Cloudflare account. Omitting --allowed-mail, however, leaves the address accessible to anyone who has its link.

The actual command therefore determines whether protection is enabled. A tunnel created by automation warrants particular attention to whether that option was included.

Request limits and authentication boundaries

Quick Tunnels are designed for testing and development, without an uptime guarantee. Each allows up to 200 requests in flight; additional requests receive HTTP 429.

Server-Sent Events (SSE), where a server keeps a connection open to push events, are unsupported. Email authentication also requires an interactive browser, making it unsuitable for non-interactive clients.

Each newly created tunnel also receives a different temporary hostname. This is not a basis for a fixed production address or a long-lived streaming connection.

Checking an allowed and a denied visitor

Cloudflare documents the following command to allow a single email address.

cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com

Testing once with an allowed mailbox and once with a denied mailbox can establish whether the intended access check is active. Changing the allowlist requires restarting the tunnel, and access ends when the process exits.

These are checks inferred from the documentation, not a tunnel test performed for this article.

Quick Tunnels email protection is useful for temporary browser demos, but it is not a guarantee of production uptime or authentication for every client.