# How to get custom-domain email without an office suite > Set up email on your own domain without buying calendars, documents, meetings, and other office-suite tools you may not need. You do not need an office suite to use email on your own domain. A dedicated email host can receive and send mail for addresses such as `you@company.com` without bundling calendars, documents, meetings, and team chat. You still need a domain, access to its DNS settings, and a provider that handles the type of email you plan to use. The right provider depends on whether people need an inbox, whether software needs an API, and whether replies matter. Choose a dedicated mailbox provider if people need to read and answer mail. Choose forwarding if one person only needs copies in an existing inbox. Choose an email API or raw infrastructure when software owns the workflow. ## What you need for custom-domain email Your domain name and your email service are separate. The company where you registered the domain controls its registration. Your DNS records tell other systems where the website and email live. Changing mail records does not require moving the website or changing registrars. A normal setup includes: - **MX records**, which tell senders where to deliver incoming mail. - **SPF**, which lists systems allowed to send for the domain. - **DKIM**, which adds a verifiable signature to outgoing mail. - **DMARC**, which states what receivers should do when authentication fails and gives the domain owner reporting options. Your provider should supply the exact values. Do not copy DNS values from another customer, an old guide, or a screenshot. ## Four ways to set it up ### 1. Use a dedicated mailbox provider A mailbox provider stores incoming mail and gives people a way to read and reply. This is the most direct alternative to an office suite when you still need normal business email. Look for: - A web or mobile inbox - Custom-domain sending and receiving - Shared and private mailboxes - Spam and malware handling - Forwarding - Search and message history - Clear account recovery - Export and deletion controls Startup Mail is one option in this category. It provides stored mailboxes, a focused web inbox, verified forwarding, and separate permissions for shared and private addresses. It also exposes the same mailbox through an API, SDK, webhooks, and MCP. It does not include a calendar, document editor, meeting service, general SMTP account, or IMAP synchronization. That is the point of the product, but it is also a real limit. ### 2. Use an email forwarding service A forwarding service accepts mail for your domain and sends a copy to an address you already use. This can work well for a solo operator who wants `hello@company.com` to arrive in an existing Gmail or Outlook inbox. It is often simple and inexpensive. Check the outgoing path before choosing it. Receiving a forwarded message does not prove you can reply cleanly from the custom address. You may need a separate sending service, a verified From address, or a relay supplied by the forwarding provider. Also check what the forwarding service stores. If it only passes messages onward, the destination inbox may be the only durable copy. Startup Mail forwarding works differently from forwarding-only services. The original message remains in its Startup Mail mailbox. The forwarded copy uses a signed, expiring Reply-To route so a reply can return to the correct address and conversation. It is still not synchronization. Labels, folders, read state, stars, sent items, and deletions do not move between the two inboxes. ### 3. Build on email infrastructure Services such as Amazon SES provide sending and receiving components rather than a ready-made employee inbox. Amazon SES receipt rules can write incoming messages to S3, publish them through SNS, call Lambda, or send them to Amazon WorkMail. This is useful when engineers need control over the message pipeline. It also means the team may need to build or operate: - MIME parsing - Message and attachment storage - Conversation threading - Search - Spam decisions - User authentication - Mailbox permissions - A reading and reply interface - Retry and duplicate handling - Bounce and complaint processing - Backups and deletion Choose this route when those controls are part of your product or infrastructure work. Do not choose it merely because the per-message price appears low. ### 4. Use a transactional sending API A transactional email provider can send login links, receipts, alerts, and confirmations from your domain. That does not always create a mailbox for `you@company.com`. Some providers now support inbound messages and store them for a period, but their main interface may still be webhooks and APIs rather than a daily human inbox. This is the right tool when an application sends email and replies are unimportant or handled elsewhere. It is not automatically a replacement for staff or founder mail. ## Decide who will use each address Make a list before changing DNS. For each address, record: - Who reads it - Who may send from it - Whether it is private or shared - Whether software needs access - Whether replies are expected - Where the lasting copy should live - How long the mail must be kept - What should happen when a teammate leaves A founder's private mailbox needs different controls from `support@`. An address used by an agent should not share a broad personal credential. A receipt sender may need delivery events but no inbox. This small inventory prevents one provider from being forced into jobs it was not designed to do. ## Choose the right reading surface A focused web inbox is enough for many small teams. Others want to stay in Gmail, Outlook, Apple Mail, or another client. Ask how that access works: - **Native provider inbox:** The provider stores and displays the mailbox. - **Forwarding:** The provider sends copies to another inbox. - **IMAP:** A mail client synchronizes folders and message state with the server. - **Exchange:** Microsoft's account and synchronization model. - **API:** Software reads and changes mailbox data with code. These methods are not interchangeable. Startup Mail has its own web inbox and supports forwarding. It does not offer IMAP, POP, Exchange, or a general SMTP account. If full synchronization with a desktop mail client is required, choose a provider that supports it. ## Plan the DNS change Before replacing an existing mail provider: 1. List the current MX, SPF, DKIM, and DMARC records. 2. Find out which services still send mail for the domain. 3. Export any mail you need from the old provider. 4. Create and test addresses in the new service. 5. Lower DNS time-to-live values before a planned cutover if your provider advises it. 6. Replace the MX records with the new provider's values. 7. Add the new DKIM value. Update the existing SPF policy so it still includes every valid sender. Do not publish a second SPF policy for the same domain. 8. Publish an appropriate DMARC policy. 9. Test incoming mail, outgoing mail, replies, and attachments. 10. Keep the old service available until the change has propagated and tests pass. Do not change the A, AAAA, or website CNAME records unless you also intend to move the website. A domain should not have two unrelated MX destinations by accident. If different systems need to receive mail, use a documented routing design or give one system a subdomain. ## Do not ignore deliverability and abuse controls Owning a domain does not guarantee that its mail will reach an inbox. Use a provider that signs outgoing mail with DKIM, supports SPF and DMARC, reports bounces and complaints, and suppresses addresses that should no longer receive mail. Keep human conversations, product notifications, and marketing campaigns in suitable systems. A newsletter platform needs consent, unsubscribe handling, audience management, and campaign controls. A normal company mailbox does not replace it. Startup Mail allows direct conversations and transactional messages that recipients requested or reasonably expect. It does not allow newsletters, cold outreach, drip sequences, purchased lists, or scraped contacts. ## When an office suite is still the better choice Avoiding a bundle is not a goal by itself. Choose Google Workspace or Microsoft 365 when the team also needs the suite's calendar, documents, meetings, file storage, device management, retention, or compliance tools. One integrated account per employee may be simpler than joining several smaller services. A dedicated email provider makes more sense when: - You already have tools for documents and meetings. - Only a few company addresses need mail. - Software or agents need mailbox access. - You want email costs separated from employee productivity accounts. - You prefer a smaller administration surface. - You do not need IMAP or Exchange, if considering Startup Mail. The best setup is the smallest one that meets the real requirements. Sometimes that is an office suite. Sometimes it is a mailbox provider. Sometimes a company needs separate systems for employee mail, product mail, and marketing. ## A practical Startup Mail setup A new Startup Mail workspace follows a short path: 1. Add a domain you control. 2. Publish the MX, DKIM, SPF, and DMARC records shown for that domain. 3. Verify each record. 4. Create shared or private mailboxes. 5. Add teammates or explicit private-mailbox grants. 6. Add and verify a forwarding address if you want to read mail elsewhere. 7. Create a tenant- or mailbox-scoped API key only if software or an agent needs access. 8. Subscribe a signed webhook if code should react to incoming mail. 9. Test receiving, composing, replying, forwarding, and attachments. The website can stay where it is. Only the mail route changes. That is custom-domain email without an office suite: a domain, a focused mail provider, and no bundle you do not need. Compare [Startup Mail and Google Workspace](https://staging.startupmail.dev/compare/google-workspace-alternative.md) if you are unsure whether the office apps justify a per-user plan. If you are considering raw AWS components, read [Startup Mail vs Amazon SES](https://staging.startupmail.dev/compare/amazon-ses-alternative.md). Developers can continue with [email API vs inbox API](https://staging.startupmail.dev/guides/email-api-vs-inbox-api.md). If you are deciding how each address should work, compare [forwarding with a real mailbox](https://staging.startupmail.dev/guides/email-forwarding-vs-real-mailbox.md) and [aliases with separate and shared mailboxes](https://staging.startupmail.dev/guides/email-alias-vs-mailbox-vs-shared-inbox.md). ## Sources - [Google guide to setting up MX records](https://support.google.com/a/answer/6156494) - [Google guide to setting up SPF](https://support.google.com/a/answer/33786) - [AWS guide to receiving email with Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/receiving-email.html) - [Amazon SES email receiving concepts](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-concepts.html) - [Postmark inbound processing guide](https://postmarkapp.com/developer/user-guide/inbound) - [Resend receiving email documentation](https://resend.com/docs/dashboard/receiving/introduction) - [Startup Mail domain and DNS guide](https://staging.startupmail.dev/docs/domains.md) - [Startup Mail overview](https://staging.startupmail.dev/docs/overview.md) - [Startup Mail mailbox guide](https://staging.startupmail.dev/docs/mailboxes.md) - [Startup Mail forwarding guide](https://staging.startupmail.dev/docs/forwarding.md) - [Startup Mail security guide](https://staging.startupmail.dev/docs/security.md) - [Startup Mail sending guide](https://staging.startupmail.dev/docs/sending.md) ## Related reading - [Startup Mail vs Google Workspace](https://staging.startupmail.dev/compare/google-workspace-alternative.md): Compare Startup Mail and Google Workspace for custom-domain email, shared inboxes, developer access, office apps, and per-user costs. - [Startup Mail vs Amazon SES](https://staging.startupmail.dev/compare/amazon-ses-alternative.md): Compare Startup Mail and Amazon SES for custom-domain email, sending, receiving, AWS setup, inboxes, APIs, scaling, and total cost. - [Compare email services by the job you need done](https://staging.startupmail.dev/compare.md): Compare Startup Mail with mailbox providers, email APIs, agent inbox platforms, and office suites without reducing the choice to a feature count.