A newsletter system built from zero, done right

Easy.Tools wanted to send newsletters and lifecycle mail to the contact base their product had gathered (and eventually to offer sending to their own customers), but there was no proper infrastructure underneath it. Everything risked going out from the same domains as their core product mail, which is the fastest way to burn deliverability. Newsletters are the most exposed traffic there is, so mixing them with transactional and automation streams meant one bad send could take down the whole operation. They needed a system designed to grow, not a quick fix.

I treated this as building a sending platform, not configuring a tool. The core principle was isolation: separate the streams by their risk profile and never let the riskiest traffic touch the domains that carry the business. From there I worked outward: a clean authentication model, a domain and IP strategy sized for scale, consent rules that only send to people who actually want the mail, and warm-up so nothing goes out cold. Every decision was made so the client could run it themselves afterwards, with monitoring that flags the moment something drifts.

1. 01

   Kickoff and architecture

   I ran discovery on the existing setup and access, gathered requirements, then designed the full blueprint: a sub-account model on a proven cloud sending platform with dedicated IPs, routing and a clear map of how every kind of mail would flow.

2. 02

   Authentication and domains

   I built the authentication model (SPF, DKIM and DMARC with a stable return-path and tracking setup) and defined a domain strategy where customers can either send through a shared, fully authorized domain or verify and authenticate their own.

3. 03

   Stream and consent separation

   I split traffic into distinct streams (transactional, onboarding, automation, billing and marketing) so newsletters run on their own isolated domains and infrastructure. Sending is consent-driven: only contacts who finished the core product path and show real engagement enter the newsletter flow.

4. 04

   Warm-up and provider routing

   I designed a ramp-up model that sends in batches, watches bounces and reputation, then scales volume only when the signals stay clean. I added quality-based IP pools and routing that recognizes regional mailbox providers and sends them through the right channel instead of getting throttled.

5. 05

   Hygiene and monitoring

   I set up suppression and blocklist logic, full bounce analysis, activity cohorts that quiet down or retire non-openers, and monitoring dashboards with alerts on bounce, complaint and open-rate thresholds pushed to the team and to me.

6. 06

   Operating model and handover

   I delivered the documentation, playbooks and monitoring SOPs, plus per-stream statistics the team can pull by date range and channel. The system launches in stages (a small share of traffic first) with a clear incident and review cadence so they can run it independently.

Easy.Tools now has a real newsletter and lifecycle sending system instead of ad-hoc blasts: authenticated, stream-isolated infrastructure that protects their core domains while newsletters run safely on their own. Sending is consent-driven and self-throttling, so volume grows on reputation rather than burning it, and the team can operate it with documentation and alerting that surface problems early. The design is built to scale toward roughly a million sends a day as they add more brands and streams.