Patterns
Guide email-domain setup
Treat sending authentication, incoming routing and testing as separate stages with honest readiness.
On this page
User goal
Treat sending authentication, incoming routing and testing as separate stages with honest readiness.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Review separate Sending and Receiving statuses in Email domains. |
| 2 | Add a domain or continue an existing sample setup. |
| 3 | Provide domain, public email address, display name and inbox. |
| 4 | Inspect sample sending DNS records and copy values if demonstrating the UI. |
| 5 | Review receiving guidance, then the test step. |
| 6 | Finish the local wizard; no domain change or test delivery occurs. |
Decision and composition rules
- A ready sending domain does not establish incoming routing.
- A visible public email address is distinct from private app-owned routing.
- Current steps are a UI prototype; provider architecture is documented separately.
Edge cases and recovery
- Continue does not validate or verify DNS.
- Test buttons report local completion without sending/checking mail.
- Never copy fictional DNS values into a real domain.
- Production must obtain authenticated provider status and preserve pending/error recovery.
Persistence boundary
The demonstrated frontend uses local React state or static fixtures. Read the readiness topic before connecting these actions to authenticated persistence. A visible toast, badge or timer is not a server acknowledgement.
Source references
| File | Responsibility |
|---|---|
| components/views/email-domains-settings.tsx | Wizard |
| helpdesk-notes/Email Domain Infrastructure.md | Provider design |
Examples from the app
Actual Sonarist components with fictional conversations, people, example.com addresses and simulated operational states. Captured at 2× resolution or higher. Select an image to inspect it full size.
Related topics
Source audit: 2026-10-08 · Revision 10f45d1377b5 · Documentation v1.0.0