Should you run your own MTA or use an email API? A practical comparison of costs, deliverability work, control and vendor lock-in, plus how to stay portable.
Pidgely teamPublished 6 min readMarkdown version
Running your own MTA gives you full control and the lowest per-message cost at high volume, but you take on the whole deliverability job: IP warm-up, bounce and complaint processing, feedback loops, blocklist monitoring, abuse prevention and 24/7 operations. An email API removes that work at a higher per-message price and introduces lock-in risk if your reputation is tied to the vendor's domains and IPs. For most teams the right answer is an API or platform that sends with your own domain identity and lets you export your data, so you get managed operations without losing portability.
Installing Postfix, Exim, Haraka or a commercial MTA takes an afternoon. Operating it as a production sending platform is a different job. The pieces you own:
421 and 4.7.x deferrals.Each item is solvable. Together, they are a product.
The break-even point depends on volume and on how you value engineering time. Low and medium senders almost always pay less in total with a managed service. Very high senders with a team that already understands deliverability can justify their own MTA.
You also own every mistake. If your MTA becomes an open relay or a compromised credential sends spam, there is no vendor safety team to stop it.
The API itself is rarely the hard part to replace. Lock-in in email comes from reputation and data:
d=vendor.example.net, the reputation built from your engagement accrues partly to that domain, and your DMARC alignment depends on it.d=example.com) and a return-path subdomain such as bounces.example.com. Your domain reputation then travels with you.export interface EmailSender {
send(message: {
from: string;
to: string[];
subject: string;
html: string;
text?: string;
headers?: Record<string, string>;
stream: "transactional" | "marketing";
idempotencyKey: string;
}): Promise<{ id: string }>;
}With these in place, switching providers or moving to your own MTA becomes a DNS change, a warm-up period and an adapter, not a rebuild.
The choice is not strictly binary:
Pidgely sits in the middle path: it runs its own MTA, with no third-party sending vendor underneath, while your mail is signed with your domain's DKIM key and uses your own return-path subdomain, so the reputation you build belongs to your domain.
The software is often free and per-message costs are low, but the total cost includes IPs, monitoring, bounce and complaint processing, warm-up, abuse handling and on-call time. For most teams, engineering time dominates the infrastructure bill.
Lock-in happens when your deliverability depends on assets you do not control: the provider's DKIM domain, return-path, IPs, suppression list, templates or proprietary API. Moving away then requires rebuilding reputation and data.
Sign DKIM with your own domain, use a return-path subdomain you own, keep a copy of your suppression list and event history, keep templates in your repository, and wrap the sending API behind a thin internal interface.
Often not by default. Several major cloud providers block or restrict outbound port 25 on new accounts, and their IP ranges can have mixed reputation. Check the provider's policy and get proper reverse DNS before planning on it.
Pidgely team
Published
We build Pidgely, the email API that gets you to the inbox. We write about what we learn delivering email, citing the standards and mailbox provider guidelines behind every claim.
A practical IP warm-up guide: how to ramp volume on a new sending IP, which signals to watch at each mailbox provider, and the mistakes that reset reputation.
5 min read
Shared vs dedicated sending IPs explained: how reputation works on each, the volume you need for a dedicated IP, costs, risks and a simple decision framework.
5 min read
Why separating transactional and marketing email protects deliverability, and how to split streams by subdomain, IP pool, suppression scope and sending policy.
5 min read