Business Email for SaaS Founders: The Complete Stack
founders@, support@, and API sends on one domain — the email setup every product company needs before launch.
Part of the collection Business email, industry by industry
Before you ship, decide who receives abuse@, support@, and billing@. Founders who skip this scramble when the first enterprise customer asks for a security contact.
The addresses a product company needs before launch
- founders@ or hello@ — the public front door that outlives any one person's inbox
- support@ — where customers write when something breaks; give it one clear owner
- billing@ — invoices, failed payments and refund requests, kept apart from support threads
- security@ — where researchers report vulnerabilities; list it in a /.well-known/security.txt file on your site
- abuse@ and postmaster@ — role addresses RFC 2142 expects every mail domain to accept; mailbox providers and hosting companies use them to reach you
Keep product mail and human mail on one domain, with separate identities
Receipts, password resets and sign-up confirmations should come from your own domain so they carry your DKIM signature. Send them from a dedicated address such as notifications@ through an API key, and let people reply to support@. On OquMail each mailbox can have its own API keys, so the key your app uses can be revoked without touching anyone’s login.
Launch-week checklist
- Verify MX, SPF, DKIM and DMARC for the domain and send a test to a Gmail and an Outlook address
- Create the role mailboxes above and decide who reads each one
- Put the API key in your secrets manager, never in client-side code
- Send your first receipts and resets to your own team before real users see them
- Read the delivery log for the first day of production sends — bounces there usually mean a typo in a template or a bad address list