{"id":"69bb38f63f1c7d8bc1820a11","title":"Brevo Email","path":"how-to/technical-articles/2026-03-18-single-instance-multi-tenant-exploration/brevo-email","contentMarkdown":"# Email at Scale: Outbound via Brevo, Inbound via Cloudflare\n\n_____\n\nFrom 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.\n\n## What Groups Receive Today\n\nGroups already on the NGX Ramblers platform receive a complete email solution covering both directions:\n\n**Outbound (via Brevo):**\n- Newsletter and bulk email sending\n- Event notification emails (new events, changes, cancellations)\n- Booking confirmation, cancellation, and waitlist emails\n- Member welcome and renewal reminder emails\n- Configurable email templates and sender identity per group\n\n**Inbound (via Cloudflare Email Routing):**\n- Role-based email addresses (e.g. `chairman@group-a-ramblers.org.uk`, `events@group-a-ramblers.org.uk`)\n- Single-recipient forwarding to a committee member's personal email\n- Multi-recipient forwarding via Cloudflare Workers (e.g. `secretary@` forwards to 3 committee members simultaneously)\n- Catch-all routing for unmatched addresses\n- Destination address verification to prevent misuse\n- SPF, DKIM, and DMARC validation on all inbound mail\n- Full email routing logs with 30-day audit trail\n- Admin UI for managing all routing rules, destinations, and workers\n\n## Outbound Email Architecture\n\nBrevo 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.\n\n```mermaid\nflowchart LR\n subgraph ngx[\"NGX Ramblers\"]\n ADMIN@{ icon: \"ngx:user\", label: \"Group admin\", pos: \"b\", h: 48 }\n EMAIL[\"Outbound Email Service
group-scoped\"]\n ADMIN --> EMAIL\n end\n\n subgraph brevo[\"Brevo\"]\n SEND@{ icon: \"ngx:brevo\", label: \"Brevo API\", pos: \"b\", h: 48 }\n TPL[\"Templates per group\"]\n LIST[\"Contact lists per group\"]\n end\n\n EMAIL --> SEND\n SEND --> TPL\n SEND --> LIST\n LIST -->|\"newsletters\"| M1@{ icon: \"ngx:user\", label: \"Members\", pos: \"b\", h: 48 }\n LIST -->|\"event notifications\"| M1\n LIST -->|\"booking confirmations\"| M1\n\n style ngx fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n style brevo fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n```\n\n## Inbound Email Architecture\n\nCloudflare 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.\n\n### How It Works\n\nEach 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:\n\n- **Single recipient** — a direct Cloudflare routing rule forwards to one personal email\n- **Multiple recipients** — a Cloudflare Worker script is deployed that forwards to all recipients simultaneously\n- **Catch-all** — a fallback rule captures any unmatched addresses\n\n```mermaid\nflowchart TD\n SENDER@{ icon: \"ngx:user\", label: \"External sender\", pos: \"b\", h: 48 }\n SENDER -->|\"chairman@group-a-ramblers.org.uk\"| CF\n\n subgraph CF[\"Cloudflare Email Routing\"]\n CFI@{ icon: \"ngx:cloudflare\", label: \"Cloudflare\", pos: \"b\", h: 48 }\n CFI --> MATCH[\"Rule matcher
literal match on To address\"]\n MATCH -->|\"single recipient\"| DIRECT[\"Direct forward rule\"]\n MATCH -->|\"multiple recipients\"| WORKER[\"Cloudflare Worker
email-fwd-group-a-chairman\"]\n MATCH -->|\"no match\"| CATCH[\"Catch-all rule\"]\n end\n\n DIRECT -->|\"forward\"| R1@{ icon: \"ngx:user\", label: \"Committee member\", pos: \"b\", h: 48 }\n WORKER -->|\"forward to all\"| R2@{ icon: \"ngx:user\", label: \"Recipient 1\", pos: \"b\", h: 48 }\n WORKER -->|\"forward to all\"| R3@{ icon: \"ngx:user\", label: \"Recipient 2\", pos: \"b\", h: 48 }\n WORKER -->|\"forward to all\"| R4@{ icon: \"ngx:user\", label: \"Recipient 3\", pos: \"b\", h: 48 }\n CATCH -->|\"fallback\"| R5@{ icon: \"ngx:user\", label: \"Secretary\", pos: \"b\", h: 48 }\n\n style CF fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n```\n\n### Admin UI Capabilities\n\nThe NGX Ramblers admin interface provides full control over email routing without needing Cloudflare dashboard access:\n\n- **Per-role configuration** — select forwarding target (member email, custom address, or multiple recipients) for each committee role\n- **Destination verification** — register and verify forwarding addresses via Cloudflare's email confirmation flow\n- **Worker management** — deploy, update, and delete multi-recipient Worker scripts directly from the admin UI\n- **Status monitoring** — real-time status badges showing ACTIVE, OUTDATED, MISSING, or PENDING for each role's forwarding\n- **Orphan detection** — identifies deployed Worker scripts not linked to any routing rule\n- **Email routing logs** — 30-day rolling audit trail showing all routed emails with SPF/DKIM/DMARC validation results\n- **Worker invocation logs** — execution monitoring for multi-recipient Workers (requests, errors, subrequests)\n\n### Authentication and Deliverability\n\nAll inbound email passes through Cloudflare's authentication pipeline:\n\n- **SPF** (Sender Policy Framework) — validates the sending server is authorised\n- **DKIM** (DomainKeys Identified Mail) — validates the message hasn't been tampered with\n- **DMARC** (Domain-based Message Authentication) — policy enforcement combining SPF and DKIM\n\nAuthentication results are logged and visible in the admin UI, helping diagnose deliverability issues.\n\n## Complete Email Flow — Both Directions\n\n**Outbound** (platform to members): NGX Ramblers → Brevo API → member inboxes\n\n**Inbound** (public to committee): external sender → Cloudflare Email Routing → committee member inboxes\n\n**Admin**: all routing rules, destinations, and logs managed through the NGX Ramblers admin UI — no Cloudflare dashboard access required\n\n## Multi-Tenant Email Requirements at 500 Groups\n\nFor a national rollout, the multi-tenant architecture must prioritise:\n\n1. **Per-group Brevo configuration** — each group needs its own sender identity, templates, and contact lists\n2. **Email isolation** — Group A's member list must never receive Group B's emails\n3. **Shared Brevo account vs per-group accounts** — a single Brevo organisation with sub-accounts, or a centralised account with list-level segregation\n4. **Deliverability at scale** — SPF, DKIM, and DMARC records per group domain to maintain inbox placement across 500 sending domains\n5. **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\n6. **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\n","contentHtml":"

Email at Scale: Outbound via Brevo, Inbound via Cloudflare

\n
\n

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.

\n

What Groups Receive Today

\n

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

\n

Outbound (via Brevo):

\n\n

Inbound (via Cloudflare Email Routing):

\n\n

Outbound Email Architecture

\n

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.

\n
flowchart LR\n    subgraph ngx["NGX Ramblers"]\n        ADMIN@{ icon: "ngx:user", label: "Group admin", pos: "b", h: 48 }\n        EMAIL["Outbound Email Service<br/>group-scoped"]\n        ADMIN --> EMAIL\n    end\n\n    subgraph brevo["Brevo"]\n        SEND@{ icon: "ngx:brevo", label: "Brevo API", pos: "b", h: 48 }\n        TPL["Templates per group"]\n        LIST["Contact lists per group"]\n    end\n\n    EMAIL --> SEND\n    SEND --> TPL\n    SEND --> LIST\n    LIST -->|"newsletters"| M1@{ icon: "ngx:user", label: "Members", pos: "b", h: 48 }\n    LIST -->|"event notifications"| M1\n    LIST -->|"booking confirmations"| M1\n\n    style ngx fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n    style brevo fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n
\n

Inbound Email Architecture

\n

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.

\n

How It Works

\n

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:

\n\n
flowchart TD\n    SENDER@{ icon: "ngx:user", label: "External sender", pos: "b", h: 48 }\n    SENDER -->|"chairman@group-a-ramblers.org.uk"| CF\n\n    subgraph CF["Cloudflare Email Routing"]\n        CFI@{ icon: "ngx:cloudflare", label: "Cloudflare", pos: "b", h: 48 }\n        CFI --> MATCH["Rule matcher<br/>literal match on To address"]\n        MATCH -->|"single recipient"| DIRECT["Direct forward rule"]\n        MATCH -->|"multiple recipients"| WORKER["Cloudflare Worker<br/>email-fwd-group-a-chairman"]\n        MATCH -->|"no match"| CATCH["Catch-all rule"]\n    end\n\n    DIRECT -->|"forward"| R1@{ icon: "ngx:user", label: "Committee member", pos: "b", h: 48 }\n    WORKER -->|"forward to all"| R2@{ icon: "ngx:user", label: "Recipient 1", pos: "b", h: 48 }\n    WORKER -->|"forward to all"| R3@{ icon: "ngx:user", label: "Recipient 2", pos: "b", h: 48 }\n    WORKER -->|"forward to all"| R4@{ icon: "ngx:user", label: "Recipient 3", pos: "b", h: 48 }\n    CATCH -->|"fallback"| R5@{ icon: "ngx:user", label: "Secretary", pos: "b", h: 48 }\n\n    style CF fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n
\n

Admin UI Capabilities

\n

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

\n\n

Authentication and Deliverability

\n

All inbound email passes through Cloudflare's authentication pipeline:

\n\n

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

\n

Complete Email Flow — Both Directions

\n

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

\n

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

\n

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

\n

Multi-Tenant Email Requirements at 500 Groups

\n

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

\n
    \n
  1. Per-group Brevo configuration — each group needs its own sender identity, templates, and contact lists
    2. \n
  2. Email isolation — Group A's member list must never receive Group B's emails
    3. \n
  3. Shared Brevo account vs per-group accounts — a single Brevo organisation with sub-accounts, or a centralised account with list-level segregation
    4. \n
  4. Deliverability at scale — SPF, DKIM, and DMARC records per group domain to maintain inbox placement across 500 sending domains
    5. \n
  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. \n
  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
    7. \n
\n"}