Problem
Once an organisation has more than a handful of applications, each one has its own SMTP settings, its own credentials, and its own idea of what the sender address should be. When delivery fails, the investigation starts by working out which application sent the message, then where its configuration lives, then whether that configuration is still the one somebody meant to apply.
Our role
Design and implementation: service, configuration model, and deployment path.
Approach
The relay centralises outbound mail behind one service. Configuration — tenants, sender identities, upstream credentials — is stored in PostgreSQL rather than in the applications, so changing a provider is one edit instead of a deployment per project.
A setup wizard covers first run, because the gap between a repository and a working relay is usually configuration rather than code. An administrative interface handles the ongoing changes, and deployment is Docker-based, with Caddy or a Cloudflare Tunnel providing the external entry point depending on the environment.
Outcome
The service runs, is configurable through the administrative interface, and deploys from a container. Whether it is safe to expose to untrusted senders is a different question: authentication, abuse prevention, TLS, monitoring, and tenant isolation all need review before that claim could be made, and none is made here.
Notes
No credentials, hostnames, or tenant configuration are published. The relay is described as a private service; open relaying is not a supported use.