SMTP Auto

Project Overview

SMTP Auto is a fully autonomous orchestration platform that provisions, configures, warms up, and continuously monitors production-grade email-sending infrastructure with minimal human intervention. It was built to address a problem every growth-stage business eventually encounters: running a reliable outbound email program from a self-hosted mail server is technically demanding, operationally fragile, and easy to get wrong in ways that are expensive to recover from. A single misconfigured authentication record, a missed certificate renewal, an unnoticed blocklist listing, or a ramp-up schedule that moves too aggressively can silently destroy deliverability for months.

Rather than accepting those failure modes as the cost of doing business — or outsourcing the problem to third-party sending services with their own pricing pressure and message-throughput limits — SMTP Auto encapsulates the specialist knowledge of a seasoned email-operations engineer into a single, policy-driven system. The platform takes a freshly provisioned Linux virtual machine and a domain name and, over the course of a month, delivers a trusted sender with a strong reputation, verified authentication, and automated policy escalation. From that point onward, the same system continues to watch the infrastructure, intervene when problems arise, and notify operators only when a human decision is genuinely required.

The business value is straightforward: predictable inbox placement, reduced operational overhead, independence from proprietary sending platforms, and a measurable reduction in the time-to-deliverability window that usually precedes any new outbound email program.

Key Features & Functionality

SMTP Auto covers the entire lifecycle of an outbound mail system rather than any single slice of it.

Provisioning. The platform takes a bare server and produces a fully hardened mail relay. It installs and configures the mail transfer agent, the signing layer, the recipient authentication layer, a TLS certificate pipeline, host-level firewalling, and an intrusion-prevention layer. Every configuration step is idempotent, so operators can re-run provisioning at any point without fear of partial state corruption.

Authentication and DNS. The platform generates and publishes the three modern email authentication records — the sender policy framework, domain keys, and DMARC — directly through registrar APIs. It supports multiple DNS providers and validates each published record against live resolvers before proceeding. Policy strength escalates automatically as the domain proves itself.

Warm-up. New sending infrastructure must be ramped gradually or receiving networks will classify it as abusive. SMTP Auto runs a multi-week graduated warm-up program that begins with a small daily send volume and scales into the thousands, drawing from a curated set of realistic business-style message templates. Volumes are adjusted in response to real-world feedback from bounce rates, complaint signals, and deliverability telemetry.

Monitoring. Health checks run continuously: mail queue depth, TLS certificate expiry, blocklist status across dozens of authoritative lists, queue backlog, and authentication alignment. The system owns its own state and knows when it is healthy, degraded, or in recovery.

Intelligent decisions. A language-model advisor is consulted for non-obvious pacing and reputation decisions, with a strict monthly spending ceiling and a deterministic rule engine that takes over seamlessly if the advisor is unavailable.

Notifications and dashboard. Operators receive structured updates through a messaging channel of their choice and can use a local web dashboard to inspect state, trigger validations, and view audit history.

Technology Stack

The platform is built primarily in modern Python. Its user-facing command-line interface uses a widely adopted CLI framework, and the configuration layer uses a type-safe validation library to ensure every deployment is fully specified before any remote action is attempted. Remote execution is handled through a mature SSH/SFTP client, and configuration files are generated from templates using a battle-tested templating engine. Persistent state, metrics, and audit records are stored in an embedded relational database, keeping the operational footprint small and easily portable.

The web dashboard is built on a high-performance asynchronous web framework with signed-cookie session management. Terminal output uses a rich formatting library for clear, professional presentation. Email messages are built as standards-compliant MIME documents. DNS resolution uses a mature resolver library, and external integrations — DNS provider APIs, notification services, and the language-model API — are handled through conventional HTTP clients and first-party SDKs. Testing is implemented with a modern Python test runner and supports both synchronous and asynchronous code paths.

The server-side components — the mail transfer agent, the signing daemon, the mailbox server, the certificate authority client, the firewall, and the intrusion-prevention system — are all open-source and widely deployed at enterprise scale.

Technical Complexity & Challenges

Running outbound email well is one of those problems that looks simple from a distance and reveals enormous surface area up close. The project had to reconcile several genuinely hard problems simultaneously.

Distributed state consistency. The platform coordinates configuration across four moving targets: the remote server, a DNS provider, a certificate authority, and the sending reputation external receivers hold about the domain. Any action on one must be reflected correctly in the others, and the system must tolerate partial failures without corrupting either its own state or the remote server.

Idempotency under failure. Because remote provisioning can fail mid-sequence for many reasons — network partitions, registrar throttling, package-manager races — every operation was designed so re-running it produces the same end state. This required careful discipline when generating configuration, managing service restarts, and publishing DNS records.

Adaptive decision-making with a cost ceiling. The team wanted the platform to benefit from a large language model for genuinely judgment-based decisions, such as interpreting mixed deliverability signals during warm-up, without introducing unbounded spend or a hard dependency on an external service. The design resolves this with a two-tier decision engine: an advisory layer that consults a language model when beneficial, and a deterministic rules layer that covers the same decisions through policy. Either layer alone is sufficient to run the system, and the cost layer enforces a strict monthly ceiling before any paid call is made.

Observability for non-interactive infrastructure. Because the platform runs unattended, its own audit trail had to be trustworthy. Every decision, every remote command, every policy change, and every advisory consultation is persisted with a timestamp and the context in which it occurred. This enables post-incident review without re-running anything.

Security under remote automation. The platform holds credentials for a DNS registrar, a server, and a language-model provider. Each was treated as a separate blast radius, with least-privilege design and no credential ever written into generated output, templates, or logs.

Design & User Experience

Although SMTP Auto is an infrastructure tool, the team deliberately invested in user experience because operators are exactly the kind of users who suffer most from poor tooling.

The command-line interface is structured around clear verbs — provisioning, warming, validating, monitoring, rotating, reporting — each with rich terminal output that presents state as readable tables and panels rather than walls of log text. The operator always knows what phase the system is in and what the next milestone is.

The companion web dashboard surfaces the information operators need during incident response, including live warm-up progress, readiness criteria, authentication record validation, blocklist status, domain-reputation scoring, budget consumption, and a searchable audit log. Navigation is organised around the operator's mental model of the system rather than the underlying module structure, and forms use inline validation to catch input mistakes before they propagate.

Notifications are intentionally terse. Operators only hear from the platform at meaningful thresholds: provisioning complete, a warm-up milestone, a blocklist event, a budget advisory, or full readiness. Noise is the enemy of trust in an automation platform, and the notification design reflects that.

Scale & Scope

The codebase contains roughly two dozen core Python modules totalling approximately ten thousand lines of production code, supported by a substantial unit-test suite spanning the decision engine, budget enforcement, DNS management, warm-up scheduling, domain scoring, blocklist checking, and configuration validation. Dozens of template files underpin the generated server configuration, the professional-style warm-up correspondence, and the web dashboard.

The system integrates with ten distinct external services and subsystems, ranging from two DNS provider APIs to a language-model API, a notification API, a certificate authority, an intrusion-prevention daemon, a firewall, a mail transfer agent, a signing daemon, and a mailbox server. The warm-up engine alone coordinates volume scaling across a multi-week schedule, and the monitoring layer evaluates against a multi-criterion readiness gate before declaring the infrastructure production-ready.

Documentation is substantial: a detailed architecture document, an operational runbook, a troubleshooting guide, and an engineering-standards document that defines coding, logging, and sub-agent routing conventions.

Business Impact & Use Case

The primary audience for SMTP Auto is any organisation that needs to send legitimate, high-volume outbound email under its own infrastructure rather than through a third-party sending provider. This typically includes growth-stage businesses running transactional and lifecycle email programs, specialist agencies managing client correspondence at scale, and platform businesses whose cost structure, compliance posture, or control requirements make self-hosted email strategically important.

The platform directly reduces three categories of operational cost. First, it eliminates the weeks of specialist engineering time ordinarily required to provision and warm up a sender correctly, which is often the gating item for launching a new outbound program. Second, it removes the ongoing toil of monitoring and reacting to deliverability incidents, because the system catches and responds to most categories of failure before an operator would notice. Third, it avoids the long-term expense and vendor lock-in of building an outbound program on top of a third-party sending service.

From a commercial perspective, the platform's most tangible impact is time-to-first-clean-send: a domain that would typically require thirty to ninety days of careful manual warm-up to reach strong deliverability can be stood up, warmed, and validated on a deterministic schedule without the usual setbacks of human error. Industries where this matters most include financial services, software-as-a-service, e-commerce, regulated communications, and any business where email is a primary channel for revenue-generating customer interaction.

Development Approach

The project was built with a strong emphasis on correctness, maintainability, and operational safety. Every module has an explicit responsibility and a docstring describing it; every function that crosses a network boundary is wrapped in structured error handling with logging before and after the external call. Configuration is validated at load time rather than at point of use, which prevents partially valid deployments from ever executing.

The test suite is organised module-by-module and focuses on the areas where regressions would be most expensive: decision logic, budget enforcement, authentication record generation, and external API adapters. External dependencies are mocked at the library boundary to keep tests fast and deterministic.

Release discipline includes a clear separation between configuration, state, and runtime code; structured documentation for every operational procedure; and a design that allows the most sensitive pieces — the decision engine, the warm-up schedule, and the budget enforcement — to be reasoned about independently of the surrounding orchestration. The combination of clear architectural boundaries, comprehensive test coverage, detailed operational documentation, and conservative design choices means the platform is in a condition where a new engineer can take ownership of it after a short onboarding period, and where the system itself can operate unattended for long stretches without accumulating risk.