Founding Principles: Why Cloud Server for Email Exists

• February 2022

Cloud Server for Email was founded on specific beliefs about how commercial email infrastructure should be built and operated. This note documents those founding principles and how they shape the infrastructure and services we provide.

Cloud Server for Email was founded on the conviction that commercial email infrastructure should be built and operated with the same operational rigour that other mission-critical business infrastructure receives — not as an afterthought to the marketing stack, but as a foundational system whose quality determines the commercial performance of the programmes it serves. This conviction emerged from observing how many commercial email programmes operate on infrastructure that is adequate for basic delivery but inadequate for the monitoring, control, and quality discipline that sustainable deliverability requires.

The Infrastructure Gap We Founded To Close

Most commercial email programmes in 2022 fall into one of two categories: programmes using shared ESP infrastructure that limits their visibility, control, and deliverability capability, and programmes that have migrated to dedicated infrastructure but without the operational practices to use it effectively. The first category lacks the tools; the second has the tools but not the framework for using them systematically. Cloud Server for Email was founded to address both: dedicated PowerMTA infrastructure that provides the tools, combined with the managed service layer that implements the operational practices that make the tools deliver their full value.

The specific capabilities that we believe every commercial email programme above 500,000 monthly messages should have: per-event accounting log data with full SMTP response text; per-ISP domain block configuration calibrated to the programme's current reputation level; VMTA-based traffic isolation between different email types and traffic quality levels; dedicated IP pools that build reputation exclusively from the programme's own sending behaviour; daily Postmaster Tools monitoring with early-warning alerts; and DMARC aggregate report processing with monthly review. These capabilities are not advanced features reserved for large enterprises — they are the operational baseline that reliable commercial email requires.

We built the operational note library — the collection of notes of which this is one — as the documentation of the practices that dedicated infrastructure enables. Every note in this library describes a practice that is either impossible on shared infrastructure or dramatically more effective on dedicated infrastructure with correct configuration. The library is both our operational framework and our knowledge transfer mechanism: it documents what we know about commercial email infrastructure management, built from years of operating high-volume sending programmes at scale.

Our Principles for Infrastructure Design

Evidence over assumption. Every configuration decision should be based on accounting log data, Postmaster Tools monitoring, and ISP-specific signal analysis — not on generic best practices applied without validation. The accounting log is the ground truth; decisions that contradict accounting log evidence should be reconsidered. We built our infrastructure to produce the data that makes evidence-based decisions possible, and our operational practices to make reading and acting on that data routine.

Prevention over remediation. Reputation events are preventable through consistent monitoring and quality discipline. The investment in prevention — daily monitoring, quarterly list quality audits, pre-campaign verification — is always lower than the commercial cost of reputation recovery. Our infrastructure is designed to produce the early-warning signals that make prevention possible, and our managed service is designed to ensure those signals are read and acted on before they become incidents.

Isolation over commingling. Different traffic types (transactional, promotional, cold email), different traffic quality levels (high-engagement, low-engagement, new acquisition), and different sending domains should be isolated from each other through VMTA architecture and separate IP pools. Commingling creates the reputation contamination problems documented throughout this library. Isolation creates the clean attribution of signals to their correct sources that makes reputation management meaningful.

Calibration over configuration-and-forget. Per-ISP domain block configuration, IP pool sizing, and monitoring thresholds should be regularly reviewed and updated as reputation levels, ISP rate limits, and programme volume change. A configuration that was correct six months ago may not be correct today. The quarterly calibration review is the operational discipline that keeps the infrastructure aligned with the current reality of the programme's ISP relationships.

What We Build For

We build email infrastructure for the long term: infrastructure that gets better over time as IP reputation accumulates, domain reputation compounds, and operational practices become more precisely calibrated to the programme's specific ISP relationships. We build for the programme that will be sending in five years, not just the programme that is sending today. The warmup investment, the domain reputation building, the monitoring infrastructure, and the operational practices we implement from day one are all investments in the long-term performance of the infrastructure — not optimisations for the first few campaigns.

We build infrastructure that makes the practices in this operational library achievable and sustainable for the programmes we serve. The accounting log pipeline, the VMTA architecture, the per-ISP domain block configuration, the monitoring integration — all of it is designed to make the operational practices these notes document accessible without requiring each programme to build and maintain the infrastructure engineering that supports them.

The operational notes in this library are the intellectual foundation on which our infrastructure decisions and our managed service practices are built. They document what we know; the infrastructure implements what we know; the managed service applies what we know to each programme's specific context. The programmes that engage with this library — reading the practices, understanding the principles, applying them to their own sending context — are the programmes that will use our infrastructure most effectively and achieve the most durable deliverability performance. That is the outcome we founded Cloud Server for Email to produce: email infrastructure that delivers at the level commercial programmes need, for as long as they need it, with the operational discipline and monitoring capability that makes that sustained performance achievable.