Email at Scale: Outbound via Brevo, Inbound via Cloudflare

From Ramblers Head Office's perspective, the most immediately deployable capability across groups is email. This article covers both the outbound and inbound email architecture, their design philosophy, and what multi-tenant email at 500 groups would require.

What Groups Receive Today

Groups already on the NGX Ramblers platform receive a complete email solution covering both directions:

Outbound (via Brevo):

Inbound (via Cloudflare Email Routing):

Outbound Email Architecture

Brevo handles all outbound email. This was an intentional design decision: the platform was built to operate within Brevo's free account tier, which covers outbound sending. However, the Brevo integration is extensible — any additional Brevo capabilities (inbound email parsing, marketing automation, transactional webhooks, etc.) could be integrated into the platform if a paid Brevo plan were adopted.

flowchart LR
    subgraph ngx["NGX Ramblers"]
        ADMIN@{ icon: "ngx:user", label: "Group admin", pos: "b", h: 48 }
        EMAIL["Outbound Email Service<br/>group-scoped"]
        ADMIN --> EMAIL
    end

    subgraph brevo["Brevo"]
        SEND@{ icon: "ngx:brevo", label: "Brevo API", pos: "b", h: 48 }
        TPL["Templates per group"]
        LIST["Contact lists per group"]
    end

    EMAIL --> SEND
    SEND --> TPL
    SEND --> LIST
    LIST -->|"newsletters"| M1@{ icon: "ngx:user", label: "Members", pos: "b", h: 48 }
    LIST -->|"event notifications"| M1
    LIST -->|"booking confirmations"| M1

    style ngx fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143
    style brevo fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143

Inbound Email Architecture

Cloudflare Email Routing handles all inbound email with sophisticated per-role forwarding. This is fully managed through the NGX Ramblers admin UI — no Cloudflare dashboard access required.

How It Works

Each committee role (chairman, secretary, events coordinator, etc.) gets a dedicated email address on the group's domain. The admin configures where each address forwards to:

flowchart TD
    SENDER@{ icon: "ngx:user", label: "External sender", pos: "b", h: 48 }
    SENDER -->|"chairman@group-a-ramblers.org.uk"| CF

    subgraph CF["Cloudflare Email Routing"]
        CFI@{ icon: "ngx:cloudflare", label: "Cloudflare", pos: "b", h: 48 }
        CFI --> MATCH["Rule matcher<br/>literal match on To address"]
        MATCH -->|"single recipient"| DIRECT["Direct forward rule"]
        MATCH -->|"multiple recipients"| WORKER["Cloudflare Worker<br/>email-fwd-group-a-chairman"]
        MATCH -->|"no match"| CATCH["Catch-all rule"]
    end

    DIRECT -->|"forward"| R1@{ icon: "ngx:user", label: "Committee member", pos: "b", h: 48 }
    WORKER -->|"forward to all"| R2@{ icon: "ngx:user", label: "Recipient 1", pos: "b", h: 48 }
    WORKER -->|"forward to all"| R3@{ icon: "ngx:user", label: "Recipient 2", pos: "b", h: 48 }
    WORKER -->|"forward to all"| R4@{ icon: "ngx:user", label: "Recipient 3", pos: "b", h: 48 }
    CATCH -->|"fallback"| R5@{ icon: "ngx:user", label: "Secretary", pos: "b", h: 48 }

    style CF fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143

Admin UI Capabilities

The NGX Ramblers admin interface provides full control over email routing without needing Cloudflare dashboard access:

Authentication and Deliverability

All inbound email passes through Cloudflare's authentication pipeline:

Authentication results are logged and visible in the admin UI, helping diagnose deliverability issues.

Complete Email Flow — Both Directions

Outbound (platform to members): NGX Ramblers → Brevo API → member inboxes

Inbound (public to committee): external sender → Cloudflare Email Routing → committee member inboxes

Admin: all routing rules, destinations, and logs managed through the NGX Ramblers admin UI — no Cloudflare dashboard access required

Multi-Tenant Email Requirements at 500 Groups

For a national rollout, the multi-tenant architecture must prioritise:

  1. Per-group Brevo configuration — each group needs its own sender identity, templates, and contact lists
  2. Email isolation — Group A's member list must never receive Group B's emails
  3. Shared Brevo account vs per-group accounts — a single Brevo organisation with sub-accounts, or a centralised account with list-level segregation
  4. Deliverability at scale — SPF, DKIM, and DMARC records per group domain to maintain inbox placement across 500 sending domains
  5. Cloudflare email routing per group — each group needs its own set of routing rules and verified destinations. Currently each group has its own Cloudflare zone — in a multi-tenant model, this could be managed centrally via the super-admin concept
  6. Inbound routing at scale — in practice, most groups use a single contact address forwarding to one person via a simple Cloudflare routing rule (no Worker required). Multi-recipient Workers are available for groups that need them but are the exception rather than the norm. This means scaling to 500 groups is primarily a matter of managing simple routing rules, not thousands of Worker scripts