Why system mail should use its own delivery identity
Security, billing, support, and status notifications should not compete with customer traffic. Separate identities make incidents easier to isolate and explain.
Architecture note
security, billing, support, notify, status, ops, and bounce separated by domain
The problem with one shared sender
A hosted email platform has two very different sending jobs. Customers send product email from their own domains, while the platform sends verification, password reset, invoice, support, and status notifications.
When those flows share the same sending domain, one operational problem can blur the evidence trail. A billing notice, a password reset, and a customer campaign may all appear to have the same identity, the same bounce path, and the same reputation surface.
A better model
Sendix separates platform mail by purpose. Security mail can come from security.sendix.dev, billing notices from billing.sendix.dev, support replies from support.sendix.dev, and operational notices from notify.sendix.dev or status.sendix.dev.
Bounce handling still routes through the controlled delivery domain so the platform can process returns, classify failures, and keep delivery logs accurate without mixing unrelated business flows.
What operators gain
Separate sender identities make it easier to rotate DKIM keys, lock a single stream, trace a complaint, or explain a delivery issue to a customer. The DNS records also become easier to audit because each domain has a narrow purpose.
This design matters most during incidents. If support mail is delayed, password reset mail should not automatically inherit the same operational blast radius.
Operator checklist
- Give each platform mail stream its own sender address and DKIM selector.
- Keep customer sending domains out of platform notification traffic.
- Route bounces into one controlled processing path with clear reason codes.
- Document ownership for DNS, rotation, abuse review, and customer support.