Key takeaways
- Running an MTA is the easy part. Acquiring clean IPs, warming them, and defending their reputation permanently is the hard part.
- Cloud providers block outbound port 25 by default on most compute, and IP ranges with a history of abuse are effectively unusable for sending.
- The work does not end at launch. Reputation defence, blocklist monitoring, feedback loop processing, and standards changes are permanent operational load.
- Buying a shared service removes the burden but hands your reputation to a pool you do not control.
- Managed dedicated infrastructure is the middle path: isolation without the operational ownership.
Every few years a team looks at their email bill, notices that an SMTP server is free and well-documented software, and asks the obvious question: why are we paying for this? It is a reasonable question, and the answer is not "because email is hard to send." Email is trivial to send. A working MTA is an afternoon.
The answer is that the value in an email provider is almost entirely in the layer beneath the software — the IP addresses, their reputation, the relationships and feedback loops with receiving providers, and the permanent operational work of keeping all of it healthy. That layer takes months to establish and never stops needing attention, and it is invisible until you try to build it.
This guide sets out what the full stack actually contains, what building it involves, and how to decide honestly between building, buying, and the option in between.
What "email infrastructure" actually contains
The word covers a stack of six fairly distinct layers. Teams considering a build usually price the first two and discover the other four afterwards.
| Layer | What it involves | Difficulty |
|---|---|---|
| The MTA | Software that speaks SMTP, queues, retries, and handles DSNs | Low — mature open-source options exist |
| Message composition | MIME assembly, DKIM signing, return-path rewriting, header hygiene | Low to moderate — fiddly but bounded |
| IP addresses and network identity | Acquiring clean IPs, PTR records, forward-confirmed reverse DNS, port 25 egress | High — and largely outside your control |
| Reputation establishment | Warmup ramps per IP, per-provider pacing, engagement sequencing | High — weeks of careful, attentive work |
| Feedback and monitoring | Feedback loop enrolment, Postmaster Tools, SNDS, blocklist monitoring, DMARC report parsing | Moderate — many integrations, all necessary |
| Ongoing operations | Queue health, deferral handling, reputation defence, standards changes, on-call | High — and permanent |
Why sending IPs are the hard part
The single biggest surprise in a self-hosting project is that you cannot simply spin up a server and start sending. Outbound port 25 is blocked by default on most cloud compute — a deliberate anti-abuse measure — and getting it opened involves a review process that many accounts do not pass.
The deeper problem is that IP addresses carry history. Cloud provider ranges have been used for spam for years, and receiving providers know exactly which ranges those are. An address recycled from a previous tenant can arrive already carrying reputation damage that has nothing to do with you and no clear remediation path. Checking an IP against major blocklists before you commit to it is table stakes, and finding a genuinely clean address is harder than it sounds.
- Port 25 egress is blocked by default across most cloud platforms and requires a justification process to unblock.
- Reverse DNS must be set to a hostname that forward-resolves back to the same IP. Many hosting providers will not delegate PTR at all, and generic PTR records are treated as a negative signal in their own right.
- IP history is inherited. A recycled address may already be on blocklists, and delisting something you did not cause is slow and sometimes impossible.
- Consistency requirements mean each IP needs sustained near-daily volume to stay warm, which constrains how many you can usefully run. The volume floor applies.
- Redundancy multiplies all of the above: one IP is a single point of failure, and several means several warmups and several reputations to defend.
The work that never finishes
Build projects are usually scoped as a project: some weeks of engineering, a launch, then maintenance. Email infrastructure does not have that shape. The launch is the beginning of the actual commitment.
| Ongoing responsibility | Cadence | What happens if you skip it |
|---|---|---|
| Blocklist monitoring | Daily | You discover a listing from a customer complaint, days late |
| Feedback loop processing | Continuous | Complainers keep receiving mail, and complaints compound |
| Per-provider deliverability review | Weekly | A Microsoft-specific problem hides behind healthy Gmail numbers |
| Queue and deferral management | Continuous | Retry storms against a throttling receiver make the throttling worse |
| Reputation defence | Continuous | A single bad sending day becomes months of degraded placement |
| Standards and policy changes | Ongoing | You find out about a new enforced requirement when mail starts bouncing |
| On-call for mail delivery | Always | Password resets stop at 3am and nobody is paged |
That last row is worth taking seriously. If your product’s password resets depend on infrastructure you operate, then mail delivery is now a tier-one service with the same on-call expectations as your database. Most teams that build do not staff for that, and the gap shows up during an incident rather than during planning.
The policy row matters more than it used to. The February 2024 Google and Yahoo requirements and the May 2025 Microsoft requirements each arrived with a few months of notice and hard enforcement afterwards. A provider absorbs those changes for its customers. A self-hosted sender has to notice, interpret, and implement them.
When building genuinely makes sense
None of the above means building is wrong. It means the reasons have to be real, and cost is usually the weakest of them once you account for the engineering time.
- Volume where unit economics dominate. At hundreds of millions of messages a month, per-message pricing becomes a genuine line item and an in-house platform can pay for itself.
- Email is the product. If you are building an email service, a mailbox provider, or a deliverability tool, the infrastructure is your core competence rather than a distraction from it.
- Regulatory requirements that no vendor will meet. Specific data residency, sovereignty, or physical isolation requirements sometimes leave no purchasable option.
- You already have the expertise. If a deliverability specialist is already on staff, the marginal cost of building is much lower than it is for a team learning as they go.
What you give up by buying
Buying is the right answer for most teams, but it is not free of trade-offs and it is worth being clear-eyed about them.
| What you give up | Why it matters | Mitigation |
|---|---|---|
| Control over IP reputation | Other tenants on a shared pool affect your delivery | Choose a provider that controls who is on the pool — or take dedicated infrastructure |
| Direct escalation to receivers | You cannot open the conversation yourself | Choose a provider that operates its own infrastructure and can |
| Named, stable sending IPs | Customer allowlisting and security reviews need them | Dedicated infrastructure with IPs listed in the dashboard |
| Unit cost at very high volume | Per-message pricing eventually exceeds infrastructure cost | Negotiate volume tiers; revisit the build case only at genuine scale |
| Full control of the sending path | Some compliance regimes ask for it explicitly | Dedicated servers with documented isolation |
Every mitigation in that table points the same direction: the trade-offs of buying shrink substantially when the provider owns its infrastructure rather than reselling someone else’s. A provider layered over a hyperscaler cannot give you named stable IPs, cannot escalate directly, and cannot tell you who else is on the pool — because they do not control any of it either.
The middle path: managed dedicated infrastructure
The build-versus-buy framing implies two options. There is a third, and for teams whose actual requirement is isolation rather than ownership, it is usually the right one.
Managed dedicated infrastructure means mail servers and IP addresses provisioned for your traffic alone, operated by a provider who already has the IP relationships, the warmup process, the feedback loop enrolments, and the monitoring in place. You get the isolation properties of building — no other tenants, nameable IPs, a sending path you can describe in a security review — without acquiring the operational burden.
| Build it yourself | Shared service | Managed dedicated | |
|---|---|---|---|
| Time to first production send | Months | Minutes | Days to weeks |
| IP acquisition and PTR | Yours | Not applicable | Handled |
| Warmup | Yours | Not needed — pool is warm | Handled before cutover |
| Other tenants on your IPs | None | Yes | None |
| Nameable IPs for allowlists | Yes | No | Yes |
| Blocklist and reputation monitoring | Yours | Provider’s | Provider’s |
| On-call for mail delivery | Yours | Provider’s | Provider’s |
| Ongoing engineering load | Permanent | None | None |
Where SuperSend TX sits
We built the layer described in this guide, and we operate it. That is the product — not a wrapper over someone else’s pipe, which is why we can answer questions about pool composition and IP identity precisely rather than approximately.
Production mail runs on a transactional-only network carrying paying customers exclusively: no free tier on production infrastructure, no marketing campaigns, no cold outbound anywhere on it. Dedicated provisions mail servers and IP addresses for your workspace alone — we acquire and configure them, run the full warmup ramp before you depend on them, monitor reputation per receiving provider, and stay on call for delivery. Your IPs are listed in the dashboard so you can hand them to a customer’s security team.
The same POST /emails contract runs from Sandbox through Pool to Dedicated, so the decision about infrastructure is not a decision about your codebase.
- Mail servers and IPs we own and operate, not rented capacity
- Transactional-only production network — no marketing, no cold outbound
- Dedicated servers and IPs, warmed before cutover
- Sending IPs listed in the dashboard for customer allowlists
- Reputation, blocklist, and feedback-loop monitoring handled
- Identical API contract across every tier
We already built the hard part
Mail servers, clean IPs, warmup, feedback loops, and monitoring — owned and operated by us. Start on the transactional-only Pool, or take dedicated servers and IPs of your own.
Related reading