Business email got simpler once I separated receiving from sending
I’ve been looking closely at how small businesses and solo founders handle custom-domain email. One thing became clear pretty quickly. When someone says, “I want email on my domain,” they may mean one of two very different things.
The first problem is receiving email. For example, [email protected] forwards to your existing Gmail inbox. That is mostly a routing problem: where should mail for this domain land?
The second problem is sending email. You need to reply or send as [email protected]. That brings in SPF, DKIM, DMARC, SMTP, reputation, and deliverability.
A lot of people jump straight into a full workspace product because the whole thing feels bundled together. Sometimes that is the right choice. But sometimes the actual need is much smaller: “I just need customers to email me at my domain and land in the inbox I already use.”
I’m starting to think the useful question is not
“Which email provider should I use?”
but
“Do I need to receive, send, or both?”
That small distinction can simplify the decision quite a bit.
Curious how others think about this. When you first set up custom-domain email, did you actually need sending from the domain right away, or was receiving enough at the beginning?
the split maps to a risk asymmetry nobody bundles for: receiving is stateless routing — get it wrong and you repoint the MX record and forget about it. sending builds a reputation asset thats slow to earn and easy to torch, and it follows the domain for months. bundling them hides that one half is disposable config and the other is a fragile long-lived asset you cant just re-provision when it breaks.
This maps to how I set mine up, and I'd frame the sending split less as a deliverability thing and more as blast-radius control.
Receiving I solved first with plain forwarding into an inbox I already used, the routing problem you described. On sending, my volume is still low, so I'm honestly not fighting reputation or deliverability at scale yet. The reason I still keep outreach on its own dedicated sending mailbox, separate from my primary inbox, is what can happen to the account itself.
Concrete example from a few days ago: the provider auto-suspended that outreach mailbox after an automated login check flagged it as suspicious. Because it was a separate identity, my real inbox and domain never even noticed. If I'd sent outreach from my main address to "keep things simple", that one automated suspension would have locked me out of my actual business & transactional email account. That's the catastrophic version, and honestly a better reason to split than deliverability is at my stage.
To answer your actual question: receiving was genuinely enough at the very start, forwarding covered it for a while. Sending got its own isolated mailbox the moment outreach started, and I'm glad it was split by default before I found out the hard way why.
yeah this is underrated, especially if you do any cold/bulk sending - keeping your main domain for receiving and a separate one (or subdomain) for sending saves your primary reputation if a campaign goes sideways. one thing i'd add though: warm the sending one up slowly before pushing volume, otherwise the separation doesn't save you, you just torch the new domain instead. how are you handling warm-up?
I like the distinction because it separates what people think they need from what they're actually trying to accomplish.
A lot of products become unnecessarily complex by bundling related problems together. Splitting receiving from sending changes the buying decision before it changes the technical solution.
Exactly. “buying decision” is a good way to put it.
A lot of people say “I need email on my domain,” but the actual job may be much smaller. They want to receive mail at a branded address, reply from Gmail, send transactional email, or manage a team inbox. Those shouldn’t all imply the same product or setup.
My main takeaway so far is that bundling receiving and sending too early makes the problem feel more expensive and more technical than it needs to be.
I think that's where it gets really interesting.
Reading your reply made me notice a consequence of unbundling the problem that isn't obvious at first, but it has a much bigger impact on the business than the technical implementation itself.
It needs a bit more room than a thread allows.
If you're interested, what's the best email to reach you on?