Domains belong to projects
A normalized domain has one project owner, making sender context unambiguous.
Multi-project workspace
Separate each client, website, or SaaS product into its own operational boundary without creating another subscription. Domains, keys, contacts, logs, and sender state stay project-local; plan usage stays workspace-wide.
Acme Storeacme.store
6.8kLakeside Weblakeside.dev
3.1kClient Portalportal.co
1.4kSeparation where it matters
Projects are designed for builders who move between client work, experiments, and live products all day.
A normalized domain has one project owner, making sender context unambiguous.
Choose a project-bound key, selected projects, or full workspace access.
Contacts, suppressions, broadcasts, automations, and deliverability state do not leak between clients.
Switch projects without switching accounts, billing portals, or support workflows.
How it works
The workspace owns membership, billing, and pooled limits. Projects own operational resources.
Use the product or client name. The immutable slug keeps API and portal routes stable.
Attach one or several sending domains and optionally enable the receiving capability.
Use a project key for the application or a broader key for a trusted agent.
See project contribution and the single workspace allowance from the same dashboard.
Free starts with one project. Pro unlocks unlimited projects with 25,000 pooled emails and 10 included domains.