How to set up support@ for your SaaS without Google Workspace

A branded support address is one of the cheapest ways to make a small product look established. “Write to support@yourproduct.com” reads very differently from a personal Gmail address. But if you run more than one product, paying for a full mailbox on every domain just so support@ exists adds up, and most of those mailboxes would only ever hold support mail.

You don’t need Google Workspace, or any paid mailbox, to run support@ well. You do need to get three things right, and each option below handles them differently.

The three jobs a support address has to do

1. Receive. When a customer writes to support@, their mail server looks up your domain’s MX records to find where to deliver. Something has to be listening there.
2. Reply as the address. Your answer should come from support@yourproduct.com, not from you@gmail.com. That needs a server that’s allowed to send mail as your domain.
3. Prove the reply is genuine. Gmail, Yahoo and Outlook check SPF, DKIM and DMARC on incoming mail. Since February 2024, Gmail has required every sender to use at least SPF or DKIM (Gmail email sender guidelines). A reply that fails these checks is much more likely to land in spam.

Most setups that go wrong handle the first job and forget the other two.

Option 1: Forward support@ to an inbox you already have

Many registrars and DNS hosts offer free email forwarding. Cloudflare’s version, Email Routing, is available on its free plan and forwards incoming mail for your domain to a verified destination address (Cloudflare Email Routing docs). You create a rule for support@, point it at your personal inbox, and mail starts arriving within minutes.

Good for: receiving, at no cost.

The catch: forwarding only covers receiving. When you hit reply, the answer comes from your personal address, which exposes it to customers and splits the conversation between two addresses. Forwarding also changes how SPF looks to the final inbox, because the forwarding server isn’t on your domain’s list of senders. That’s one reason DKIM, which survives forwarding, matters so much.

Option 2: Forwarding plus Gmail’s “Send mail as”

Gmail can send from addresses other than your Gmail one. You add the address in settings, confirm it from a link Google sends there (which works because your forwarding rule delivers it), and then choose it in the From line. One Gmail account can send from up to 99 addresses (Gmail Help: send from a different address).

Good for: a free setup inside an app you already know.

The catches:

• To send through your domain properly, Gmail needs the SMTP server, username and password of a provider that hosts the address. Forwarding services usually don’t give you one, so you may still end up needing a mail provider per domain.
• Google notes that some recipients, for example on Outlook, may see the message as sent from your Gmail address “on behalf of” the other address.
• Most importantly, Google’s help page says that starting January 2027, Gmail will no longer support “Send as” for third-party email addresses. Google Workspace aliases aren’t affected. If you’re setting up support today, this route has a known end date.

Option 3: A mailbox at another email provider

Plenty of providers sell mailboxes on your own domain. You get real IMAP and SMTP, proper DKIM signing, and an app to read it in. For one product that’s a solid choice. For several, you either pay for a mailbox per domain or add every domain to one account and juggle identities, and support mail still sits next to everything else you receive.

Option 4: A help desk

Help desk tools are built for support teams: assignment, macros, reporting, SLAs. If you have agents, they’re worth it. For a founder answering a few dozen messages a week, they’re often more setup and process than the job needs.

Option 5: A shared support inbox for every domain

This is the gap InboxNest fills. You connect each product’s domain and create as many addresses on it as you like. If the domain already has email you want to keep, you forward just the support addresses. If it has none, you point its MX records at InboxNest (Direct MX or forwarding?). Either way, replies go out from the address the customer wrote to, and every connected domain is set up with its own DKIM key and a custom Return-Path. There are no SMTP passwords, and support stays out of your personal inbox.

The DNS checklist, whichever option you choose

Whatever handles your mail, the same four records decide whether it works. Check each domain once it’s set up:

• MX: points at whoever receives your mail (your forwarding service, mail provider or InboxNest). Check it with the MX checker.
• SPF: one TXT record listing every service that sends as your domain. Two SPF records, or more than 10 DNS lookups, make SPF fail outright (RFC 7208). Check it with the SPF checker.
• DKIM: the public key for each service that signs your mail. Google recommends 2048-bit keys. Check it with the DKIM checker.
• DMARC: one record at _dmarc.yourdomain that ties SPF and DKIM to your From address. Start with p=none and a reporting address, then tighten. Check it with the DMARC checker.

The support email checker runs all four at once and tells you whether the domain is ready.

Test it like a customer would

1. From a personal account at a different provider (a Gmail or Outlook.com address works well), send a message to your new support address.
2. Confirm it arrives where you expect, and nowhere else.
3. Reply. Check that the reply arrives from the branded address, not your personal one.
4. In the receiving account, open the message’s original headers. Look for spf=pass, dkim=pass and dmarc=pass. If any of them fails, fix it before you publish the address.
5. Reply once more from the customer side to make sure the thread holds together.

Which one should you pick?

For one product and very light volume, forwarding plus “Send mail as” works today, but plan for the January 2027 change. If you want a real mailbox and only have one domain, a mail provider is simple. If you have a team of agents, use a help desk. If you’re one person or a small team answering support for several products, a shared inbox that handles receiving, sending and authentication for every domain saves the most time, and that’s the job InboxNest was built for.