Building an AI-Native Email Platform: Our Architecture

Every email platform launched in the last two years claims to be "AI-powered." Most of them bolted a ChatGPT wrapper onto their subject line generator and called it a day. The AI does not touch the infrastructure that actually determines whether your email reaches the inbox.

When we designed Senthop, we made a different choice: AI is embedded in the delivery pipeline itself. Not as a feature you toggle on, but as a structural component that shapes how every email is routed, timed, and evaluated. This post explains the architecture and what that distinction means in practice.

The 15-service topology

Senthop runs as a set of specialised services, each with a single responsibility:

• API (Fastify): The entry point for all programmatic email sending. Handles authentication, compliance checks, rate limiting, and queue dispatch.
• Frontend (Next.js): The dashboard for domain management, analytics, template editing, and configuration.
• Postfix: The outbound MTA (Mail Transfer Agent) that actually delivers messages over SMTP. Also handles inbound mail reception.
• OpenDKIM: Per-domain DKIM signing as a Postfix milter. Automatically discovers signing keys on startup.
• SMTP Worker: Consumes the outbound queue, selects the optimal sending IP, and hands messages to Postfix.
• Inbound Worker: Parses incoming email (RFC 5322), routes to mailboxes, webhooks, or forwarding addresses.
• Events Worker: Dispatches webhook events to customer endpoints with HMAC signing and retry logic.
• Global Router: Selects the optimal region and IP for each message based on recipient provider and current health metrics.

These eight services form the core delivery pipeline. The remaining seven are where AI enters the picture.

The AI layer: five specialised workers

AI Deliverability Worker. Every outgoing message passes through a content analysis stage. The worker feeds the message content, headers, and recipient metadata to Gemini and gets back a deliverability risk score. High-risk signals include: spam trigger phrases, broken HTML that might trip content filters, excessive image-to-text ratios, and missing unsubscribe headers. The analysis runs asynchronously — it does not block sending — but the results feed back into reputation tracking and can trigger alerts.

The same worker handles bounce classification. When a message bounces, the raw bounce message contains an SMTP status code and a human-readable diagnostic. Status codes are standardised, but the diagnostics are not — every provider phrases their rejections differently. Gemini classifies bounces into categories (hard bounce, soft bounce, policy block, rate limit, content rejection) with higher accuracy than regex-based parsers, especially for the long tail of smaller mailbox providers.

IP Warmup Worker. This is the most operationally critical AI worker. It runs hourly, reads delivery metrics from the warmup log, and decides whether each IP should advance to the next warmup stage, hold at the current stage, or regress to a previous one. The decision considers bounce rates, complaint rates, engagement trends, and provider-specific signals. The worker updates daily and hourly sending limits in the IP pool table, which the SMTP worker reads when selecting an IP for each message.

Why AI and not a rule-based engine? Because the optimal warmup pace depends on factors that interact in non-obvious ways. A 2% bounce rate might be fine at stage 3 if the bounces are all soft (temporary) from a single provider experiencing issues, but alarming if they are hard bounces spread across multiple providers. Gemini can weigh these factors contextually in a way that a decision tree cannot.

Inbox Prediction Worker. Before a message is sent, this worker predicts the probability of inbox placement vs. spam folder placement for each major provider. The prediction considers: the sender's current reputation with that provider, the message content analysis score, the sending IP's warmup stage and recent metrics, and historical placement data for similar messages. The prediction is exposed in the API response and the dashboard, letting senders know which messages are at risk before they send.

Send-Time Optimisation Worker. This worker aggregates tracking events (opens, clicks) by provider, region, and hour of day, then asks Gemini to identify the optimal send time for each segment. The insight is not "send email on Tuesday at 10am" (a generic best practice), but "your B2B recipients on Outlook in the UK engage most at 9:15am, while your B2C recipients on Gmail in the US engage most at 7:30pm ET." The optimisation runs nightly and updates a lookup table that the Global Router consults.

Incident Auto-Detection Worker. This one does not use Gemini — it is a rule-based monitor that reads the region health table every 5 minutes and opens or closes status incidents when health metrics cross thresholds. It is included in the AI discussion because it consumes data produced by the AI workers and acts on it automatically.

The Gemini integration pattern

All AI workers go through a centralised Gemini client that manages model selection, rate limiting, and fallback. We use three tiers:

• Lite (Gemini 2.5 Flash Lite): Classification tasks — bounce categorisation, content risk scoring. Low latency, high throughput.
• Standard (Gemini 2.5 Flash): Content analysis, warmup recommendations. Moderate latency, good reasoning.
• Advanced (Gemini 2.5 Pro): Complex reasoning tasks — multi-factor warmup decisions, anomaly investigation. Higher latency, reserved for decisions that justify the cost.

The tiering matters because AI costs scale with usage, and an email platform processes millions of events. Running every bounce classification through the Pro model would be economically absurd. The centralised client ensures that each task uses the cheapest model that can handle it reliably.

What "AI-native" means vs. "AI-bolted-on"

The distinction is architectural. In a bolted-on system, AI is a feature layer on top of an existing pipeline. The pipeline works without it; the AI provides optional enhancements. In a native system, AI is part of the pipeline's control loop — it makes routing decisions, adjusts infrastructure parameters, and shapes delivery strategy in real-time.

Concretely:

• Bolted-on: "Our AI can generate subject lines for your email." (The delivery pipeline is unchanged.)
• Native: "Our AI determines which IP sends your email, at what time, and adjusts your warmup pace based on provider-specific feedback." (The delivery pipeline depends on AI decisions.)

This is not a value judgment — bolted-on AI features can be useful. But when an email platform claims to be AI-powered, it is worth asking: does the AI affect what happens after you hit send? Or only what happens before?

Network isolation and security

The five AI workers need outbound internet access to reach the Gemini API. The core infrastructure (Postgres, Redis, OpenDKIM) must never be publicly reachable. We solve this with Docker network segmentation:

• Internal network: All services can communicate. No outbound internet access.
• Egress network: Attached only to services that need external access (AI workers, webhook dispatcher, inbound worker for forwarding).
• Proxy network: The API and frontend, behind Traefik for TLS termination and routing.

A compromised AI worker cannot reach Postgres directly through the egress network — it must go through the internal network, where it only has access to the BullMQ queues it consumes. Defence in depth, applied to the AI layer the same way it is applied to everything else.

What we are building next

The current architecture treats each AI decision independently. The warmup worker does not know what the inbox prediction worker predicted; the send-time worker does not factor in the deliverability analysis score. The next iteration connects these workers through a shared context layer, so that a low inbox prediction score can automatically influence send-time optimisation (delay the message to a higher-engagement window) or warmup pacing (slow down if prediction accuracy is declining).

We are also working on per-account model fine-tuning: using each customer's historical delivery data to improve predictions specific to their sending patterns, recipient base, and content style. The general Gemini models are good; models that have seen your specific bounce patterns and engagement curves will be better.

If you are interested in how we build email infrastructure, follow this blog — we will be publishing deep dives on specific components as we go. And if you want to try the platform, sign up free and send your first email in five minutes.