We run the mail. Outbound transactional and bulk sending through separate Postfix instances, inbound through its own, mailboxes on Dovecot, filtering and scoring through Rspamd. Sender identity is checked against live DNS before a message is allowed to claim a customer's domain.
| Measure | Value | Source | Measured |
|---|---|---|---|
| Mail components in production | 5 (Postfix outbound, Postfix bulk, Postfix inbound, Dovecot, Rspamd) | kubectl get deployments -n mail | |
| Sending paths separated by reputation class | 2 (transactional and bulk, on distinct instances) | kubectl get deployments -n mail | |
| Sender-domain checks performed before a send is authorised | 2 (domain ownership proven by DNS record, and SPF authorisation verified live) | transactional sender-identity resolution in the email service |
What building it taught us
When a marketing email does not arrive, the campaign tool reports it as sent. That is technically true and completely useless. The message was accepted for delivery and then dropped, deferred or filed as spam by a receiving system according to rules the campaign tool cannot see and its vendor will not explain. This is the single most common unexplained failure in digital marketing, and an agency that only has a campaign tool has no way to investigate it.
Running the infrastructure changes what is knowable. We separate bulk from transactional sending so that a newsletter cannot damage the reputation that password resets depend on. We check, against live DNS at send time, whether a domain has really been proven to belong to the tenant claiming it and whether its SPF record actually authorises us — and if that lookup fails we record no verdict rather than guessing, because a guess here sends mail that fails authentication and teaches receiving systems to distrust the domain.
Inbound taught its own lessons. We once lost a class of incoming message because a webhook posted form-encoded data and the handler tried to parse it as JSON, returning a cheerful 200 while discarding the content. Three separate silent drops existed on that path. Nothing alerted, because everything reported success. Systems that fail by succeeding are the hardest to find and the reason we instrument ingestion paths obsessively on client work.
There is a connection limit that is worth stating too, because it is the sort of detail that only shows up under real load: a mail server permits a bounded number of simultaneous connections per user and address, per process. Exceed it and things stop working in ways that look like authentication failures. Capacity planning for mail is real engineering, and almost nobody budgets for it.
Built with
- Postfix
- Dovecot
- Rspamd
- SPF
- DKIM
- DMARC
- IMAP
- Java
- Spring Boot
Tell us what you are trying to do
A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.