KoltrixEmail hosting vs email sending: why most companies need both
A mailbox provider and a sending service solve different problems. What each does, where they overlap and how to use both on one domain without surprises.
On this page(8 sections)
"We already pay for email" is a sentence that hides a mix-up. For a lot of companies it means they pay for mailboxes: the place where people read and write mail. It does not mean the product can send a password reset to ten thousand users on a Monday morning.
Email hosting and email sending are different jobs, and they are sold, built and judged differently. Understanding the split explains why a company often uses one service for people and another for software, and how to set up both on the same domain without breaking either.
This is a plain explanation, not a ranking of vendors.
Two jobs, in one sentence each
- Email hosting gives people mailboxes. It receives mail for
[email protected], stores it, lets you read and send it from a web app or a client, and often adds calendars, contacts and search. - Email sending lets software send mail at scale. It accepts messages from your application, delivers them, handles retries and bounces, and reports what happened.
One is about conversations between humans. The other is about messages that a system produces.
What a mailbox provider is built for
A hosting product is designed around a person at a desk or on a phone.
- Storage and search across years of mail.
- Clients and sync. Web, mobile and desktop apps, over protocols such as IMAP. See IMAP, POP or Exchange.
- Collaboration. Shared mailboxes, delegation, calendars and sometimes chat or documents.
- Admin controls such as accounts, passwords, two-step sign-in and retention.
- Spam and phishing filtering for incoming mail.
Its limits are about volume and automation. Hosting plans usually cap how many messages a person can send per day, and they are not meant to carry thousands of automated messages with delivery tracking.
What a sending service is built for
A sending service is designed around a program.
- An API or SMTP relay that your application calls.
- Throughput and queueing, so bursts do not fail.
- Delivery handling: retries, bounce processing and complaint feedback. See hard vs soft bounces.
- Events and webhooks, so your system learns what happened to each message.
- Reputation management, including dedicated or shared sending addresses and warm-up. See shared vs dedicated IP.
- Templates, tagging and logs to support debugging.
Its limits are the reverse. A sending service does not give you a place to read replies, and it does not replace the mailbox your support team works in, unless it also provides inbound and shared inbox features.
Where the two overlap
The line blurs in a few places.
- Replies. A message sent by software often gets a reply from a human. That reply needs to land in a mailbox someone reads. See replies to transactional email.
- Small volumes. A tiny product can send a few messages through a mailbox account, but it will hit limits and deliverability problems quickly.
- All-in-one products. Some services combine mailboxes and sending. That can be simpler, but check whether the sending side has the controls you need.
- Marketing. Newsletters and campaigns are a third category, with their own tools and rules. See campaign builder or email API.
Why most companies end up with both
A growing company has two kinds of mail traffic:
| Traffic | Who writes it | What it needs |
|---|---|---|
| Conversations: sales, support, internal, hiring | People | Mailboxes, search, shared access, calendars |
| System messages: receipts, resets, alerts, notifications | Your application | API or relay, tracking, retries, templates, logs |
Forcing both through one tool tends to fail in one direction. Sending reset emails through a person's mailbox risks limits and spam flags. Using a bulk sender as a team mailbox leaves people with no inbox to work in.
Making both work on one domain
Using one domain with two providers is common and works well if you follow the rules.
- MX records point to the mailbox provider, because that is where incoming mail should land. See how MX records work.
- SPF lists both, combined into one record. Two separate SPF records break authentication. Watch the limit of ten DNS lookups; see the SPF lookup limit.
- Each provider signs with its own DKIM key, using its own selector, so both pass DKIM for your domain.
- DMARC covers the whole domain, and both providers' mail must align with it. Start with a monitoring policy and tighten it.
- Consider a sending subdomain for software, such as
mail.company.com, so its reputation and records stay separate. See a sending subdomain strategy. - Document it, with a table of who sends what and from which address.
A detailed walk-through is in two email providers on one domain without breaking auth.
Questions to ask when choosing
For hosting:
- How many people, and what do they need: shared mailboxes, calendars, retention?
- What are the sending limits per user?
- Can you export your mail if you leave?
For sending:
- How much volume, and how bursty is it?
- Do you need an API, an SMTP relay or both?
- What does it tell you about delivery, bounces and complaints?
- How does it handle replies and inbound mail?
The business email provider scorecard gives a weighted way to compare, and the hidden costs of a multi-vendor email stack is worth reading before you add more tools than you need.
Key takeaways
- Hosting is for people reading and writing mail; sending is for software delivering messages at scale.
- Mailbox plans have sending limits and are not built for automation; sending services do not give people an inbox.
- Most growing companies use both, or one product that does both well.
- On one domain, point MX at the mailbox provider, merge SPF, give each provider its own DKIM key and cover everything with DMARC.
- Document who sends what, and keep software mail on its own subdomain where you can.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
