Architected a four-service cold email platform that sends through real SMTP/IMAP mailboxes instead of a locked-down ESP, with warmup automation, weighted rotation, and a genuine-vs-bot open tracking model.
Web app, sending worker, IMAP poller, and Redis, containerized behind Nginx
Apple Private Relay ranges matched to classify opens as genuine or proxied
Mailbox health and bounce-rate thresholds pause sending without human intervention
Cold outbound on a conventional ESP fails on its own terms: the provider suspends the account for the exact behavior the tool exists to perform. Sending through real mailboxes avoids that, but you inherit everything the ESP was handling, send caps, rotation, warmup, bounce processing, reply detection, and deliverability monitoring.
Built a four-service system sending through real Hostinger and Gmail OAuth2 mailboxes: a Next.js/Supabase app, a standalone BullMQ/Nodemailer sending worker, a dedicated IMAP poller for replies and bounces, and Redis for queueing, behind an Nginx reverse proxy.
The sending worker is a standalone process, not a route handler. A deploy of the web app cannot interrupt an in-flight campaign, and the worker's rate limiting, jitter, and mailbox rotation live in one place that owns the whole send decision.
Daily send caps auto-raise on a warmup schedule per mailbox, and a weighted rotation spreads volume across the pool according to each mailbox's current health rather than round-robin, so a struggling mailbox naturally receives less traffic before it fails.
Multi-step sequences evaluate their conditions at dispatch time, not at schedule time. A reply that lands an hour before step three is due cancels that step, which only works if the decision is deferred to the moment of sending.
Apple Mail Privacy Protection and corporate scanners prefetch tracking pixels, which inflates open rates into uselessness. Opens are classified by matching the requesting IP against 286K real Apple Private Relay CIDR ranges and applying timing-based prefetch detection, then reported as two distinct numbers, genuine and raw, rather than one misleading one.
Spam-folder placement cannot be read from your own server. The system combines DNSBL checks against Spamhaus and SURBL with an anomaly check for the classic silent-foldering signature, flat bounce rate while engagement drops sharply, and labels that signal 'inferred, not measured' in the UI rather than presenting it as fact.
if (bounceRate.stable() && engagement.drop7d > 0.5) {
flag(mailbox, 'possible_spam_placement', { inferred: true });
}SMTP and IMAP credentials are stored AES-256-GCM encrypted per mailbox, decrypted only inside the worker at send time, the web app never holds a usable credential in memory.
If something here looks like what you're facing, tell me about it. The first conversation is an architecture discussion, not a sales call.
