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):

• Newsletter and bulk email sending
• Event notification emails (new events, changes, cancellations)
• Booking confirmation, cancellation, and waitlist emails
• Member welcome and renewal reminder emails
• Configurable email templates and sender identity per group

Inbound (via Cloudflare Email Routing):

• Role-based email addresses (e.g. chairman@group-a-ramblers.org.uk, events@group-a-ramblers.org.uk)
• Single-recipient forwarding to a committee member's personal email
• Multi-recipient forwarding via Cloudflare Workers (e.g. secretary@ forwards to 3 committee members simultaneously)
• Catch-all routing for unmatched addresses
• Destination address verification to prevent misuse
• SPF, DKIM, and DMARC validation on all inbound mail
• Full email routing logs with 30-day audit trail
• Admin UI for managing all routing rules, destinations, and workers

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:

• Single recipient — a direct Cloudflare routing rule forwards to one personal email
• Multiple recipients — a Cloudflare Worker script is deployed that forwards to all recipients simultaneously
• Catch-all — a fallback rule captures any unmatched addresses

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:

• Per-role configuration — select forwarding target (member email, custom address, or multiple recipients) for each committee role
• Destination verification — register and verify forwarding addresses via Cloudflare's email confirmation flow
• Worker management — deploy, update, and delete multi-recipient Worker scripts directly from the admin UI
• Status monitoring — real-time status badges showing ACTIVE, OUTDATED, MISSING, or PENDING for each role's forwarding
• Orphan detection — identifies deployed Worker scripts not linked to any routing rule
• Email routing logs — 30-day rolling audit trail showing all routed emails with SPF/DKIM/DMARC validation results
• Worker invocation logs — execution monitoring for multi-recipient Workers (requests, errors, subrequests)

Authentication and Deliverability

All inbound email passes through Cloudflare's authentication pipeline:

• SPF (Sender Policy Framework) — validates the sending server is authorised
• DKIM (DomainKeys Identified Mail) — validates the message hasn't been tampered with
• DMARC (Domain-based Message Authentication) — policy enforcement combining SPF and DKIM

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