The appeal of one inbox
Anyone managing more than two or three domain email addresses eventually wants them in one place. The alternative — logging into multiple accounts, monitoring multiple inboxes, keeping context across multiple sessions — adds friction that compounds every day.
The goal is straightforward: one place to read, search, and reply, regardless of which address a customer actually wrote to.
Getting there is less straightforward. Most approaches work for a while, then develop specific failure modes as the address count grows or the reply requirements get stricter.
Approach 1: forwarding everything to one inbox
The simplest approach is to forward all your domain addresses to a single inbox — usually a personal Gmail or a main company address. Support@, billing@, hello@, and any other addresses all forward to the same destination.
Receiving works well. All messages arrive in one place, they are searchable together, and you get notified in one app. For reading and triaging, this is genuinely good.
The reply problem is immediate and consistent. When you hit reply, your email client sends from the inbox that received the forwarded message — not from the address the customer originally wrote to. Your support@ customers get replies from yourname@gmail.com unless you intervene manually on every message.
- Easy to set up with any forwarding service or mail server
- Receiving and searching work well in one place
- Replying from the correct address requires manual sender selection every time
- Easy to mis-send; no automatic context for which sender was intended
Approach 2: adding multiple accounts to one mail client
Gmail and most mail clients support adding multiple accounts so you can switch between them without logging out. Apple Mail, Outlook, and Thunderbird all support this model. You can read from multiple accounts in one interface, with inboxes listed side by side.
This is not the same as one inbox. Each account still has its own inbox, sent folder, and search scope. You are managing multiple accounts from one application, not consolidating them into a single stream.
Replies default to the account the message is in. For accounts with properly routed domain mail, the sender is usually correct. But you are still triaging across multiple inboxes, and moving between them adds context switching back in a different form.
Approach 3: Gmail aliases and Send As
Gmail's Send As feature lets you add custom domain addresses as additional senders in a single Gmail account. Combine this with forwarding rules, and you can receive mail from multiple addresses in one inbox and select the correct sender when replying.
This is closer to true consolidation. Everything lands in one inbox and you have the option to reply from the right address. The limitation is that the selection is still manual — Gmail does not automatically match the reply sender to the address the customer originally wrote to.
As the address count grows, Send As also requires a separate SMTP configuration for each address. Three addresses means three SMTP credentials, three verification flows, and three more entries in Gmail settings. The maintenance overhead grows with every new address.
- All addresses visible in one Gmail inbox
- Sender address selected manually from a dropdown on each reply
- Each address requires its own SMTP setup and verification
- Works acceptably up to two or three addresses; becomes fragile beyond that
What one inbox actually requires
True consolidation has three requirements, not one. You need to receive all addresses in one place, reply from the correct address automatically, and keep the sent archive searchable by the customer's real email.
Forwarding solves the first. Some combination of Send As and memory solves the second imperfectly. The third is where most setups quietly fail — when you search Gmail for a customer's real email address, you find the messages they sent you but not your replies, because the reply was addressed to an encoded alias or went through a proxy that changed the recipient field.
A setup that handles all three cleanly requires something to preserve the routing context — specifically, which address the customer originally wrote to — and carry that context into the outbound reply path.
When a routing layer handles it cleanly
A routing layer sits between your domain addresses and your inbox. Inbound mail from any of your addresses arrives in one Gmail inbox, with the original recipient address preserved as routing context. When you reply, the routing layer reads that context and sends the message back from the correct domain address — without you selecting anything.
The result is: one inbox, automatic sender matching, and a sent folder where replies are addressed to the customer's real email. Searching for a client's email address in Gmail returns both their messages and your replies, in the same thread.
OhRelay works this way. One SMTP credential configured in Gmail covers all your domain addresses. Each reply automatically goes out from the address that received the original message.
- One inbox for all domain addresses
- Sender matched automatically on every reply — no dropdown, no memory required
- Sent copies addressed to the customer's real email, not a proxy address
- Adding a new domain address does not require another SMTP setup
What to watch for as address count grows
Manual approaches — forwarding plus Send As — tend to work until they suddenly do not. The failure is usually a wrong-sender reply that reaches a client, or a search that returns incomplete history, or a new address that requires half an hour of setup to add.
The address count at which manual approaches feel unsustainable varies. For some operators it is three or four addresses. For others, especially those managing multiple domains or client brands, the threshold arrives sooner.
The practical question is not whether a manual setup can technically work — it usually can. The question is whether the daily overhead of managing it fits the size of the team and the volume of customer contact. At some point the setup cost of each new address, and the reply risk of the manual sender selection, outweigh the benefit of avoiding a more systematic solution.