SMTP Server & Email Delivery Platform
Reliable product notifications, receipts, alerts, lifecycle messages, and operational updates backed by durable acceptance, sender-domain readiness, recipient diagnostics, signed webhooks, abuse controls, and honest delivery states.
A self-hosted, API-first email delivery platform that turns real product events into durable transactional or consent-based messages through isolated Mail Nodes, verified sender identity, and an inspectable Postfix/Rspamd delivery path.
Project brief
The product context, ownership, and current evidence.
Target users
SaaS, e-commerce, CRM, logistics, education, membership, and multi-brand product teams that need controlled transactional or opt-in email with self-hosted delivery nodes and explicit operational evidence.
Intended buyer outcome
Reliable product notifications, receipts, alerts, lifecycle messages, and operational updates backed by durable acceptance, sender-domain readiness, recipient diagnostics, signed webhooks, abuse controls, and honest delivery states.
Owned scope
SMTP and email-delivery architecture · Full-stack and systems engineering · Security · Operations design
Evidence status
All 87 source requirements have an implemented local evidence path. Development, Mailpit, dashboards, API, security, backup/restore, and failure-recovery acceptance are complete; public SMTP infrastructure and inbox observations are not yet accepted.
Problem
Outbound email becomes difficult when application acceptance, queue ownership, SMTP retry, sender identity, domain DNS, DKIM material, bounce processing, suppression policy, multi-tenant authorization, and delivery reporting are spread across unrelated tools. A platform can also become unsafe if it exposes an open relay, logs sensitive content, or treats a successful SMTP response as inbox placement.
Approach
Built a strict TypeScript monorepo with separate Fleet Hub and Mail Node applications and databases, shared API contracts, PostgreSQL outboxes, Redis/BullMQ workers, private Postfix submission, Rspamd DKIM signing, generated OpenAPI, preflight services, signed uploads and webhooks, restricted DSN intake, backup/restore tooling, Docker Compose operations, and fail-closed production configuration.
Current outcome
Version 0.1.0 is committed with the local application and Mailpit acceptance boundary complete. The recorded release evidence includes 94/94 unit and security tests, 7/7 live integration tests, 5/5 Playwright tests, production application and Docker builds, SMTP/DKIM smoke checks, 500-message batch acceptance, and recovery drills. Public infrastructure and recipient-Internet acceptance remain separate pending gates.
Maturity & lifecycle
What is complete, active, and still planned.
All 87 source requirements have an implemented local evidence path. Development, Mailpit, dashboards, API, security, backup/restore, and failure-recovery acceptance are complete; public SMTP infrastructure and inbox observations are not yet accepted.
Evidence reviewed
Discovery
CompleteLegitimate transactional and opt-in mail use cases, operator roles, sender-identity requirements, abuse boundaries, delivery truth, and production infrastructure dependencies were defined.
Scope & architecture
CompleteFleet Hub, isolated Mail Nodes, separate data ownership, queue responsibility, DKIM storage, delivery state, infrastructure identity, and explicit migration decisions are documented and traceable.
Design & prototype
CompleteHub and Node dashboards, 81-operation OpenAPI surface, domain onboarding, message composer, diagnostics, and safe Mailpit delivery workflows are implemented and inspected.
Build & integrate
CompleteHub, Node, worker, PostgreSQL, Redis/BullMQ, Postfix, Rspamd, Caddy, DKIM synchronization, DSN, webhooks, maintenance, and backup/restore paths are integrated locally.
Verify & launch
In progressLocal static, unit, integration, browser, Compose, SMTP, DKIM, batch, recovery, and restore gates passed. An authorized VM, public HTTPS, dedicated IP, PTR/DNS, TCP 25, remote MX, and controlled DSN acceptance remain.
Handover & iterate
PlannedProduction runbooks, monitoring, provider acceptance evidence, post-deployment deliverability observation, versioned releases, and operational iteration follow the external launch gate.
Real-world solutions
How the service solves operational email problems across real fields.
Each pattern connects a business event to a dependable delivery path while keeping consent, sender identity, failure evidence, and infrastructure limits visible.
SaaS and account platforms
Operational problem
Verification, password-reset, security, billing, and workflow emails become fragile when feature code calls SMTP directly and failures disappear between the application and provider.
Solution pattern
Use an authenticated email API with idempotent acceptance, templates, scheduling, durable queues, recipient events, and signed webhooks so account-critical messages remain traceable and retry-safe.
E-commerce and marketplaces
Operational problem
Order confirmations, payment receipts, shipment updates, returns, and seller notifications cross multiple systems and need the exact order context that triggered each message.
Solution pattern
Connect commerce events to versioned message payloads, sender-domain policy, batches, suppressions, and recipient-level delivery records that support customer care and reconciliation.
CRM and customer operations
Operational problem
Lifecycle messages and opt-in campaigns need consent, unsubscribe, bounce, complaint, rate, and organization rules—not only a send button.
Solution pattern
Centralize authorized CRM ingress, suppression enforcement, one-click unsubscribe, scoped API keys, scheduled work, signed lifecycle webhooks, and auditable delivery diagnostics.
Logistics and field operations
Operational problem
Dispatch changes, job assignments, delayed-delivery notices, and exception escalations can become operational blind spots when messages are delayed or silently rejected.
Solution pattern
Persist every accepted notification, expose queue and recipient state, separate temporary retry from permanent failure, and return webhook evidence to the operating system.
Education and membership systems
Operational problem
Enrollment, verification, fee, schedule, renewal, and account notices often span several programs or organizations with different sending domains and access boundaries.
Solution pattern
Use organization-isolated nodes, verified domain defaults, role-based operations, templates, controlled batches, and per-recipient history for dependable member communication.
Multi-brand product operations
Operational problem
Agencies, platform operators, and product groups need separate sender identities and operational ownership without mixing domains, keys, queues, or diagnostics.
Solution pattern
Assign isolated Mail Nodes and domain identities per organization, then manage preflight, health, migrations, backups, and webhook contracts through one fleet control plane.
The implementation provides engineering and operational controls; legal, regulatory, retention, and industry-specific compliance still require an authorized domain review.
System map
How the product boundary fits together.
- 01
Fleet Hub
The public CRM API and management dashboard own organizations, users, scoped keys, node assignment, fleet operations, suppression policy, and audited migrations.
- 02
Isolated Mail Node
Each organization owns a separate Node boundary for domains, DNS, DKIM, messages, recipients, attempts, queues, health, attachments, and local enforcement.
- 03
Delivery pipeline
PostgreSQL outbox records durable acceptance, BullMQ performs application work, Rspamd signs the selected domain, and Postfix owns SMTP retry after MTA submission.
- 04
Evidence and operations
Telemetry, DSNs, suppressions, signed webhooks, preflight, reconciliation, backups, restore drills, and explicit migrations keep state inspectable and recoverable.
Product benefits
Practical value without overstating the evidence.
Reliable product-to-email flow
SaaS, commerce, CRM, and operational events enter through one authenticated API while each organization receives an isolated Mail Node and independent boundary.
Durable acceptance
PostgreSQL transactions and an outbox protect accepted work before BullMQ dispatch, while Postfix owns remote retry after local MTA acceptance.
Safer sender-domain onboarding
A, SPF, DKIM, DMARC, forward DNS, PTR compatibility, public IP, and service health are exposed as explicit preflight evidence before sending is enabled.
Actionable delivery diagnostics
Recipient state, SMTP responses, attempts, queue IDs, DSNs, suppressions, and webhook events remain inspectable without calling SMTP acceptance an inbox delivery.
Consent and abuse controls
Scoped API keys, rate limits, suppression enforcement, one-click unsubscribe, restricted DSN intake, and open-relay denial keep legitimate use inside the product boundary.
Operable recovery paths
IP change, DNS invalidation, Rspamd failure, backup verification, paused restore, and explicit node migration are designed as observable operational workflows.
Claim boundary
Constraints and unresolved risks
- The implementation repository is private; source, credentials, message content, customer data, DKIM private keys, provider details, and internal infrastructure are not public portfolio evidence.
- Automated tests use deterministic DNS and Mailpit and do not contact recipient MX servers. Mailpit acceptance cannot establish public delivery behavior.
- REMOTE_ACCEPTED means the configured downstream SMTP service returned success; it does not mean inbox placement and a later authenticated DSN may still establish a bounce.
- Public HTTPS, provider PTR and forward-confirmed DNS, public inbound and outbound TCP 25, remote Internet MX acceptance, and controlled public DSN evidence remain SKIPPED until authorized infrastructure exists.
- Inbox placement, reputation, filtering, throttling, and operating-scale outcomes require post-deployment observation and are not deterministic product claims.
- The platform supports legitimate transactional and opt-in mail only; it excludes spoofing, harvesting, purchased-list automation, filter bypassing, reputation evasion, and automatic IP, domain, or node cycling after rejection.
Evidence base
What supports this case study
Committed implementation checkpoint
Private master commit 842bd0a records the version 0.1.0 Fleet Hub, Mail Node, worker, shared packages, infrastructure, tests, operations, and release documentation as one reviewable implementation checkpoint.
Requirement and architecture traceability
All 87 source requirements map to implemented local evidence, with nine accepted architecture decisions separating Hub and Node ownership, queue responsibility, DKIM storage, infrastructure identity, delivery truth, and explicit migration.
Automated and live local verification
The release record reports 94/94 unit and security tests across 27 files, 7/7 live Compose integration tests, 5/5 Playwright tests, application and image builds, SMTP/Mailpit smoke, DKIM alignment, open-relay denial, and 500-message batch reconciliation.
Failure, recovery, and data-safety drills
Rspamd failure and recovery, public-IP change and DNS invalidation, safe resume, webhook retry, backup verification, credential-prefix protection, and paused restore behavior were exercised and recorded.
External acceptance boundary
Public deployment, provider PTR, public TCP 25, recipient-MX acceptance, controlled public DSNs, inbox placement, and reputation remain explicitly SKIPPED rather than inferred from local evidence.
Engineering highlights
- Fleet Hub control plane with isolated one-organization Mail Nodes and no cross-database joins
- API-first single-message and 500-message batch acceptance with idempotency and explicit domain selection
- PostgreSQL transactional outbox, BullMQ dispatch, private Postfix submission, and clear retry ownership
- Per-domain RSA-2048 DKIM lifecycle and dynamic Rspamd signing with restrictive key materialization
- A, SPF, DKIM, DMARC, forward-DNS, PTR-compatibility, public-IP, service, disk, and port preflight
- Recipient-level attempts, SMTP diagnostics, late DSN updates, suppressions, complaints, and signed lifecycle webhooks
- Scoped API keys, RBAC, CSRF, encryption, SSRF controls, rate limits, redacted logs, and open-relay denial
- Explicit IP-change pause, node migration, backup verification, paused restore, and operational recovery workflows
- Generated 81-operation OpenAPI contract plus Fleet Hub and emergency Mail Node dashboards
- Mailpit-only automated acceptance with public infrastructure and inbox-placement claims kept separate
Technology and domains
01 / Product boundary
Self-hosted SMTP needs an application control plane, not only an MTA configuration.
The product connects authorized application traffic, organization policy, domain identity, durable acceptance, operational diagnostics, and controlled SMTP delivery without exposing internal infrastructure.
- 01.1Fleet Hub is the only CRM ingress and applies authentication, organization, scope, domain, idempotency, and suppression policy before forwarding work.
- 01.2Each organization has one active isolated Mail Node and may have one explicit migration target; Hub and Node databases never rely on cross-database joins.
- 01.3Hub dashboard actions and API routes share the same application services, and Node dashboards and fleet routes follow the same rule.
- 01.4PostgreSQL, Redis, Rspamd controls, worker internals, private Postfix submission, and control sockets remain private.
02 / Durable message flow
Acceptance, queueing, SMTP submission, remote retry, and recipient truth have separate owners.
The architecture avoids PostgreSQL/Redis dual-write loss and duplicate remote delivery by assigning each state transition to one durable subsystem.
- 02.1A PostgreSQL transaction creates the logical message, recipients, attachment references, and outbox record before the API returns durable acceptance.
- 02.2An idempotent dispatcher creates deterministic BullMQ work for validation, MIME construction, and private Postfix submission.
- 02.3After Postfix accepts responsibility, BullMQ completes and Postfix owns temporary remote SMTP retry; the application does not create a second delivery job.
- 02.4Single messages and batches of up to 500 logical messages preserve independent recipient and aggregate states instead of opening an uncontrolled connection burst.
03 / Sender identity
A sending domain becomes usable only after identity and infrastructure evidence agree.
Domain readiness combines authoritative sender records with the Mail Node infrastructure profile and pauses safely when relevant evidence changes.
- 03.1Creation generates an independent domain identity, RSA-2048 DKIM key, selector, and DNS plan while sending remains paused in PENDING_VERIFICATION.
- 03.2A, SPF, DKIM, DMARC, forward DNS, provider-controlled PTR compatibility, outbound IP, TLS, Postfix, Rspamd, database, Redis, and disk checks feed preflight.
- 03.3The caller must use an allowed verified domain and an aligned From address; resolution follows explicit domain, API-key default, then organization default and never guesses.
- 03.4An outbound-IP or required-DNS change records history, invalidates evidence, pauses affected sending, emits events, and resumes only after verification.
04 / Delivery truth
A successful SMTP response is evidence of remote acceptance, not evidence of inbox placement.
Recipient-level states and sanitized diagnostics preserve what the system actually knows and allow later authenticated events to refine that truth.
- 04.1SUBMITTED_TO_MTA means local Postfix accepted responsibility; REMOTE_ACCEPTED means a configured downstream SMTP server returned success.
- 04.2A later authenticated DSN can move a previously accepted recipient to BOUNCED, while temporary outcomes remain DEFERRED for Postfix retry.
- 04.3Message detail records attempts, queue ID, remote host and IP when observed, outbound identity, SMTP code, enhanced status, and sanitized response.
- 04.4Signed webhooks reuse stable event IDs across retry so downstream systems can verify signatures and deduplicate lifecycle updates.
05 / Safety and consent
The platform is designed for legitimate transactional and opt-in mail, with abuse paths deliberately excluded.
Security controls span product authorization, content and key protection, network boundaries, consent workflows, and SMTP relay policy.
- 05.1CRM keys, sessions, fleet credentials, DKIM material, retained bodies, recipient data, and attachments use scoped access, keyed hashes, encryption, and redacted logs.
- 05.2Marketing messages add one-click unsubscribe support and enforce organization and node suppression state for hard bounce, complaint, unsubscribe, and manual reasons.
- 05.3Public Postfix accepts only validated signed bounce recipients and denies unauthorized relay; normal message submission remains HTTPS through Fleet Hub.
- 05.4Spoofing, harvesting, purchased lists, filter bypass, reputation evasion, and rejection-triggered IP, domain, or node cycling are outside the product.
06 / Verification and launch
Local product acceptance is complete while Internet delivery remains an infrastructure-specific gate.
The release record separates deterministic application evidence from provider, network, recipient, and reputation conditions that local tests cannot establish.
- 06.1Documentation, environment drift, secret scan, Prisma migration, Compose, lint, strict TypeScript, unit, integration, browser, build, SMTP, DKIM, and log-review gates passed.
- 06.2The live local stack exercised 500-message acceptance, Rspamd failure/recovery, public-IP change/recovery, webhook retry, backup verification, and paused restore.
- 06.3Automated email always terminates at Mailpit and never contacts recipient MX servers, preserving a safe deterministic test boundary.
- 06.4Production acceptance still requires an authorized Linux VM, dedicated IP, public HTTPS, PTR and forward DNS, firewall/NAT, inbound and outbound TCP 25, authoritative records, remote MX evidence, and controlled DSNs.
Use cases / Client relevance
Where this product evidence can support a real engagement.
These applications reflect demonstrated product reasoning and the stated maturity boundary—not an unsupported production or client-result claim.
Explore SMTP & Email Delivery Infrastructure ↗- Provide transactional email for SaaS account, security, billing, notification, and workflow events through a controlled application API.
- Operate consent-based lifecycle or campaign messages with suppression enforcement, one-click unsubscribe, rate policy, and recipient-level evidence.
- Give a CRM or multi-tenant product one Fleet Hub while keeping each organization on an isolated self-hosted Mail Node.
- Replace fragile direct SMTP calls with durable acceptance, idempotency, scheduled work, retries, batches, signed webhooks, and inspectable failure states.
- Onboard and rotate multiple sending domains with generated DNS plans, DKIM lifecycle, preflight, explicit defaults, and safe pause/reverify behavior.
- Plan a deliberate node or infrastructure migration with audited prepare, verify, cutover, rollback, and completion states instead of reputation-triggered routing.
Questions teams ask
Scope, safety, and evidence boundaries.
Is this SMTP platform an open relay?
No. Normal CRM submission enters Fleet Hub over authenticated HTTPS. Postfix private submission is internal, and the public SMTP listener accepts only validated signed bounce recipients while denying unauthorized relay.
Does REMOTE_ACCEPTED mean an email reached the inbox?
No. It means the configured downstream SMTP server returned a successful response. Inbox placement, filtering, later DSNs, reputation, and recipient behavior remain separate observations.
What email use cases does the platform support?
It is designed for legitimate transactional and opt-in email, including SaaS notifications, CRM lifecycle messages, account and billing events, controlled batches, templates, suppressions, unsubscribe, complaints, and signed delivery webhooks.
What is complete in version 0.1.0?
The local product implementation, dashboards, API, queues, Postfix/Rspamd/Mailpit path, domain and security controls, operations, tests, and recovery drills are complete at the recorded checkpoint. The evidence includes 94 unit tests, 7 integration tests, and 5 Playwright tests.
What remains before a production SMTP launch?
An authorized production environment must still provide public HTTPS, a dedicated egress IP, provider PTR, forward-confirmed DNS, authoritative SPF/DKIM/DMARC records, inbound and outbound TCP 25, remote MX acceptance, controlled DSNs, monitoring, and post-deployment observation.
Related engineering notes
Related engineering notes
Have a related product problem?