Security
A mail server that receives on behalf of other people's domains has to be strict about identity. These are the properties this deployment actually enforces, not aspirations.
Receive-only by design
The panel has no outbound mail path: no relay, no SMTP client, no signing milter. Every hosted domain publishes SPF -all and DMARC p=reject, so a forged sender claiming your domain fails both checks at the receiving end.
- SPF -all on every hosted domain
- DMARC p=reject with sp=reject
- No open relay, verified from outside
Keys, not passwords
Accounts authenticate with a single access key issued by the panel. Keys are stored hashed, can be rotated at any time, and API keys can be bound to an IP allowlist so a leaked secret is useless off-network.
- Access keys stored hashed
- Per-key IP allowlist
- Scope and expiry per API key
Isolation between accounts
Ownership is checked separately from role on every mutating route. An account can use a domain published by an operator, but it cannot edit, suspend, or delete a domain it does not own.
- Ownership checked on every write
- 404 rather than 403, so existence is not confirmed
- Borrowed domains are read-only
Abuse controls
Mailbox creation is capped per plan, both at any moment and per day. Request rates are enforced per key, and deleted mailboxes still count toward the daily ceiling so churn cannot bypass it.
- Daily mailbox ceiling per tier
- Per-key request budget
- TTL and scheduled purge
Reporting a vulnerability
Mail [email protected]with the steps to reproduce. Please do not open a public issue, and do not test against mailboxes you do not own.