09-Jul-2026 — Setting up direct-to-inbox for committee replies

This is the companion to Setting up a Gmail inbox for committee replies. It covers the newer direct-to-inbox option, where committee mail arrives in your NGX inbox straight from Cloudflare with no Gmail account, no Google Cloud project, and no OAuth to maintain. If you are choosing how a group should receive committee replies, read both and pick one; you do not need both.

Introduction

Every NGX site can receive committee replies in one of three ways:

No inbox (the default). Committee mail is forwarded straight to members' personal inboxes via Cloudflare Email Routing. Nothing appears in Admin → Inbox. This is the starting point for a new group.
Gmail inbox. Cloudflare forwards a role address into a dedicated Gmail account, and NGX reads it through the Gmail API. This is the route the Gmail inbox guide describes.
Direct-to-inbox (this guide). A Cloudflare Email Worker delivers each message straight to NGX over a signed webhook. There is no mailbox in the middle.

Direct-to-inbox is the simplest to run because there is no Google side at all. It is push-only, so replies appear in the inbox the moment they are received.

How direct-to-inbox compares to the Gmail inbox

	Gmail inbox	Direct-to-inbox
Google account	A dedicated Gmail account per mailbox	None
Google Cloud / OAuth / Pub/Sub	Required	None
How mail travels	Cloudflare forwards the role address into Gmail; NGX reads it via the Gmail API	A Cloudflare Worker posts the message straight to NGX
Delivery	Poll every 30s, or push via Pub/Sub	Real-time on receipt
7-day token expiry to watch	Yes (Testing-mode refresh token)	Not applicable — there is no token
Where you set it up	Mostly in Google	Entirely in NGX — Cloudflare API calls made within Admin → Mail Settings & Admin → Committee Settings
Junk mail	Filtered by Google — junk lands in the Gmail account's Spam folder, which NGX doesn't read	No spam folder in the path — Cloudflare's SPF/DKIM/DMARC checks apply, but anything that passes arrives straight in your inbox
If the site is unavailable	Mail waits in the Gmail account; NGX catches up when it's back, so nothing is missed	The router forwards each message to the safety-net address instead — nothing bounces, but mail arriving during the outage lands there, not in this inbox

Before you start

You need:

Member-administrator access to the NGX site.
Cloudflare Email Routing enabled for the domain, with MX records in place and your committee role addresses (secretary@, walks@, and so on) already existing as Cloudflare routing rules. The MX and authentication-record tools live in the admin UI, so you do not need the Cloudflare dashboard for this.
To know whether the site owns its Cloudflare zone or is a subdomain of a shared zone (for example kent.ngx-ramblers.org.uk under ngx-ramblers.org.uk). The setup differs slightly. NGX works this out for you and shows the matching instructions; if it cannot, it shows a "Cloudflare zone not resolved" warning.

There is also one platform-level prerequisite that a platform administrator sets once for the whole system, not per group: the shared secret NGX_INBOUND_SECRET must be set in the platform admin shared secrets and the site redeployed. Until it is, the "route into inbox" action returns a clear error telling you to set it. If you are a group administrator and hit that error, ask whoever runs the platform to set it.

Part 1 — Choose the direct-to-inbox provider

Go to Admin → Mail Settings and open the Inbox tab.
Under "How this inbox receives mail", choose Direct to inbox — via Cloudflare Email Routing, no Gmail account. The choice saves immediately.

That switches the site's inbox provider. The next step wires Cloudflare up to actually deliver the mail, and it depends on whether your site owns its zone or is a subdomain.

Admin → Mail Settings → Inbox: choose “Direct to inbox” as the provider.

Part 2 (own-zone site) — Route your committee mail into the inbox

If your site owns its Cloudflare zone:

Make sure Cloudflare Email Routing and MX are configured and your committee role addresses exist as routing rules (Admin → Committee Settings → Email routing, or the MX and authentication-record tools).
On the Inbox tab, click Route this site's committee mail into the inbox. NGX deploys the shared email-inbox-router worker and repoints every @yourdomain routing rule at it. You will see a confirmation such as "Mail for N addresses now arrives in this inbox."
If it reports "No committee addresses were found", add the role addresses as Cloudflare routing rules first, then click the button again.

The Direct-to-inbox panel: no Gmail setup, then “Route this site’s committee mail into the inbox”.

Part 2 (shared-zone subdomain) — Use the parent zone's router

If your site is a subdomain of a shared zone, there are no Cloudflare rules to add on the subdomain itself — delivery is provided by the parent zone's router. Two things need setting:

On your subdomain site: with the provider set to Direct to inbox (Part 1), go to Committee Settings → Email routing and choose where this site's unmatched @domain mail should go — deliver to this inbox, forward to an address, or drop. This is the only catch-all choice a subdomain can make.
On the parent (apex) site: an administrator of the parent site goes to Committee Settings → Email routing → Edit catch-all and selects Shared inbox router (deliver to inboxes, forward the rest). They also provide a safety-net forward address, used only if a site cannot be reached, and set the apex site's own unmatched-mail destination.

Once both are set, the router fans each message out by recipient domain to the right site's webhook, and each site files it according to its own provider and catch-all setting. A subdomain cannot edit the shared zone's catch-all — that is set once, on the apex site.

Part 3 — Map roles and set the catch-all

These apply to both cases:

Role mailboxes (shown on the Inbox tab): confirm which committee roles map to the inbox, and set per-role notification — none, email the member who holds the role, or send to a different address.
Catch-all (Committee Settings → Email routing): decide what happens to @domain mail that matches no role rule — deliver to this site's inbox, forward to an address, or drop.

Notifications work the same regardless of provider: the same "notify the assigned member" per-role controls apply, and a digest of new inbox messages goes out every five minutes.

Reading replies

Committee replies appear in Admin → Inbox for whoever holds each role, exactly as they do with the Gmail route. Delivery is real-time — a message is filed the moment Cloudflare receives it.

The Email inbox on Kent (kent.ngx-ramblers.org.uk, a shared-zone subdomain): a reply delivered straight into the site's inbox by direct-to-inbox.

What makes this robust

Nothing is ever dropped in transit. If a site cannot be reached, errors, or is not set to direct-to-inbox, the router forwards the message to the safety-net address rather than bouncing it. Mail is never silently lost.
Messages are filed against the address they were sent to — a reply to walks@ is stored under the Walks role, not under every role a member happens to hold.
Push-only, so there is no polling and no token to keep alive — none of the 30-second delay or 7-day token housekeeping that the Gmail route needs.

Troubleshooting

"Route into inbox" fails with a message about a shared secret. The platform-level NGX_INBOUND_SECRET has not been set, or the site has not been redeployed since it was. Ask your platform administrator to set it in the shared secrets and redeploy.
"No committee addresses were found" when routing an own-zone site. Add your committee role addresses as Cloudflare Email Routing rules first (Committee Settings → Email routing), then try again.
A subdomain cannot change the shared catch-all. That is expected — the shared inbox router catch-all is set once on the apex (parent) site only. On the subdomain you only choose where your unmatched mail goes.
"Cloudflare zone not resolved" warning. NGX could not work out whether the site owns its zone. Check that Cloudflare Email Routing and MX are set up for the domain via the MX and authentication-record tools.
Replies are not appearing. Confirm the provider is set to Direct to inbox on the Inbox tab, that the own-zone route was applied (or, for a subdomain, that the apex site's catch-all is set to the shared inbox router), and that the role addresses exist as Cloudflare rules.