Self-hosting a relay
Running a relay means operating an internet-facing mail service. You need to manage DNS, delivery queues, backups, abuse reports, and sending reputation. The hosted Comail deployment is not a ready-made configuration for an unrelated operator.
Source and deployment ownership
Section titled “Source and deployment ownership”Application source is split across repositories. comail-relay owns the relay, web sidecar, labeler, label API, webhook bridge, and EU warmer. comail-web owns the public website and docs. Inbox, Builders, and other services have their own repositories.
The current Relay and website repositories require access. Public Relay source publication is separate unfinished work; this page does not imply that you can anonymously clone and run the hosted release. Contact the operator about source access before planning an independent deployment.
The old atmosphere-mail checkout is not the current application build tree. Instructions that expect its root Dockerfile or a combined infra/ application build no longer describe the current release process.
Comail’s private infrastructure repository owns the hosted NixOS configuration, credentials, and deployment workflows. Those files are specific to the hosted service. Follow the application repository’s README and contribution guide for its build requirements and license.
Prerequisites
Section titled “Prerequisites”For an independent deployment, arrange:
- A stable public sending IP, working forward and reverse DNS, and the ports required for your service. Verify outbound port 25 with your host provider before committing to a deployment. Provider restrictions vary.
- Control of the operator signing domain and all required DNS records.
- Private storage for API credentials and signing keys, plus a tested backup and recovery process.
- Persistent relay state and a reviewed deployment process with health checks and rollback.
- A monitored abuse contact and registrations for the feedback programs you intend to use.
Member-domain DKIM keys and operator keys have different storage and recovery requirements. Read DKIM rotation before changing either.
Build and validate
Section titled “Build and validate”Build the binaries from the current owning repository and use its tests. A successful build does not configure a host or prove mail delivery.
Before opening the service to members, verify authentication, DNS ownership checks, TLS, queue recovery, rate limits, and abuse handling. Test delivery to mailboxes you control and inspect the received authentication headers. Keep admin interfaces private.
The hosted service deploys through CI/CD. Its release configuration and commands must not be copied into an independent deployment without adapting and reviewing them. This page does not provide a supported one-command installation of the full stack.
Operator signing and labels
Section titled “Operator signing and labels”The relay can create operator DKIM keys when its configured key file is absent. Publish the corresponding public keys before relying on those signatures. See DKIM rotation for selectors, storage, and current rotation limits.
Running a relay does not automatically grant labels from Comail’s hosted labeler. An independent operator must configure its own verification and label service, or agree on a supported relationship with another operator. Clients must know which labeler they trust.
Federation limits
Section titled “Federation limits”The current system does not provide transparent routing between independent relays, automatic member migration, shared complaint attribution, or synchronized suppression lists. Publishing AT Protocol records does not supply those functions by itself.
A sender can retain its domain and DID, but a new operator must still verify ownership and decide whether to accept the sender. IP reputation, operator signatures, feedback registrations, and local queue state do not move automatically. See federation and reputation portability.
After deployment
Section titled “After deployment”Monitor delivery responses, queue depth, authentication failures, bounces, and complaints. Verify that provider reports reach the intended operator destination. A parser in the source does not establish an active provider registration.
Use the owning repository’s issue tracker for concrete problems and include the release revision and a redacted error. Do not include private keys, tokens, message bodies, or member data.