/ Fork 01 — Self-serve SaaS
Self-serve email that grows into managed infrastructure when you outgrow it.
Sign up, verify a domain, get an API key or SMTP credentials, and send today. No sales call, no contract. And the part most providers leave out: an honest map of where self-serve stops working — and how you move to managed dedicated IPs on the same account when you get there.
/ Quick answer
Self-serve email SaaS lets you create an account, verify your sending domain, generate an API key or SMTP credentials, and send — in minutes, without a sales call. You manage the integration and watch placement yourself; you pay monthly by volume. It fits when you have a technical owner and your volume suits a shared or light dedicated pool. Its ceiling arrives when deliverability becomes something you cannot afford to watch yourself or your volume justifies dedicated IPs. At Email Delivery Platform the difference is that you can move to managed dedicated-IP infrastructure on the same account, without re-integrating or switching providers.
-
Minutes
Signup to first send: account, domain verification, credentials, integrate. No sales call or contract.
-
API + SMTP
Both on one account. API for templates and tracking; SMTP for universal compatibility.
-
By volume
Monthly pricing that steps down as you grow. No per-seat licensing, no long-term contract.
-
One account
Move to managed dedicated IPs without re-integrating or switching providers when you outgrow self-serve.
/ 01 — The model
What does self-serve actually mean, and who is it for?
Self-serve is a model, not a feature. It means the path from deciding to send email to actually sending it runs entirely through a dashboard and a set of credentials, with no human in the loop on our side. You sign up, you prove you own your domain, you generate a key, you integrate, you send. The entire arc is designed to be measured in minutes, because the teams who choose self-serve are usually integrating today and do not want to wait on a sales process to ship.
The model fits a specific shape of team. There is a technical owner — an engineer, a founder who codes, a small platform team — who can wire up the sending endpoint and read a deliverability dashboard. The volume is in the range where a shared pool, or a lightly dedicated one, carries the reputation well. And the stakes, while real, are not yet at the point where a single missed send justifies paying someone to operate the sending around the clock. For that team, self-serve is not a compromise; it is exactly the right tool, and forcing a heavier, more expensive model on them would only add real cost and friction they do not need yet.
What self-serve is not is a permanent destination for every sender. The same autonomy that makes it fast — you integrate, you monitor, you decide — becomes a liability when deliverability grows into a full-time concern. The honest framing, which most providers avoid because it complicates the signup funnel, is that self-serve has a ceiling. Knowing where that ceiling sits is the difference between using self-serve well and clinging to it past the point where it serves you.
It helps to think of self-serve as a stage rather than a category. Almost every large sender started small, on exactly this kind of model, integrating quickly and watching their own numbers. The ones who scaled well are the ones who recognized the transition point and moved deliberately, rather than waking up to a reputation problem they could have seen coming. Treating self-serve as the first chapter of a longer story, rather than the whole book, is the mindset that makes it pay off.
/ 02 — Onboarding
From signup to first send, step by step.
Five steps, each designed to take minutes. The longest part is usually waiting for DNS to propagate after you add the authentication records, and even that is typically fast. None of the steps requires talking to anyone on our side, because the whole point of self-serve is that you are never blocked waiting on a sales process or a provisioning queue. If you can edit your domain's DNS and write a few lines of configuration, you can be sending before a meeting would have even been scheduled.
01
Sign up
Create an account in seconds. No sales call, no contract, no provisioning wait.
02
Verify your domain
Add the SPF, DKIM, and DMARC records we generate. Authentication is done before your first send.
03
Get credentials
Generate an API key, SMTP credentials, or both. Scope multiple credentials per application.
04
Integrate
Point your framework's mailer at our endpoint, or call the REST API. Minutes, not days.
05
Send & watch
Send, then watch placement through logs, events, and the dashboard. Scale as volume grows.
/ 03 — Two send paths
API and SMTP — the two send paths, side by side.
Both run against the same account and reach the same inbox. The API gives you a higher feature ceiling; SMTP gives you universal compatibility. Most teams use both — SMTP for the bulk, the API for the flows that need its extras. The choice is not permanent and not exclusive: you can start with whichever is faster to wire up today and add the other later for the specific cases that benefit. Here is the shape of an API send, with the SMTP equivalent noted underneath.
# A transactional send over the REST API
curl https://api.emaildeliveryplatform.com/v1/send \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "receipts@yourdomain.com",
"to": "customer@example.com",
"subject": "Your receipt",
"html": "<p>Thanks for your order</p>"
}'
# Same account, over SMTP instead:
# host smtp.emaildeliveryplatform.com · port 587 · STARTTLSReach for the API when
- You want server-side templates with variables
- You need per-message tracking and tagging
- You send batches with per-recipient substitutions
- You want webhooks wired into your own systems
Reach for SMTP when
- You want the fastest possible integration
- Your framework already has a mailer
- You are migrating from a self-hosted server
- You want one config that works in any language
/ 04 — The ceiling
When does self-serve stop being the right tool?
This is the section the signup-funnel providers leave out. Self-serve has a ceiling, and pretending otherwise costs you inbox placement. Here is how to read the signals — and which way each one points.
| Signal | Self-serve fits | Outgrown it |
|---|---|---|
| A clear technical owner who can integrate and monitor | Self-serve fits | |
| Volume served well by a shared or light dedicated pool | Self-serve fits | |
| Deliverability you cannot afford to watch yourself | Move to managed | |
| Volume that justifies dedicated IPs and warming | Move to managed | |
| A missed send costs more than operating the sending | Move to managed | |
| Placement slipping on a shared pool | Move to managed |
None of these signals means self-serve failed. They mean your sending grew up. The mistake is not outgrowing self-serve; the mistake is staying on it after the signals appear, paying in degraded placement for a model that no longer fits. The cost of that mistake is rarely a single dramatic failure. It is a slow erosion — a few more messages to spam each week, a sender score that drifts down, a campaign that underperforms for reasons nobody quite pins down — until one day the numbers are bad enough that someone asks what changed. The answer, usually, is that nothing changed except the volume, and the model quietly stopped being able to carry it.
The reason to map the ceiling in advance is that the signals are easier to act on early than late. Moving to dedicated IPs while your shared-pool reputation is still healthy means the warming starts from a position of strength. Waiting until placement has already slipped means warming new IPs while also repairing a reputation problem, which is harder and slower. The teams who transition well are the ones who treated the ceiling as a planning input from the start, not a surprise they ran into.
/ 05 — The transition
How do you move to managed without the migration everyone dreads?
The usual story of outgrowing a self-serve email provider is grim. You hit the ceiling, you shop for a managed service or decide to run your own infrastructure, and then you face a provider migration: new endpoints, new credentials, new integration code, new IPs that need warming from cold, all while your volume is at its highest and your tolerance for delivery risk is at its lowest. It is the worst possible time to change anything, and yet the model forces it.
Running both tracks on one platform removes that cliff. When you outgrow self-serve here, the move to managed is an upgrade on the same account rather than a migration to a new one. Your application keeps sending to the same endpoints with the same credentials. What changes is underneath: dedicated IPs get provisioned and warmed on a schedule matched to your existing send curve, and a named team takes over the deliverability operations that used to be your job. There is no re-integration because there is nothing to re-integrate.
That continuity is the entire argument for starting self-serve here rather than with a provider that only does one thing. You get the fast, autonomous, integrate-today experience while it fits, and when your sending grows past it, the path forward is a configuration change and a conversation — not a project. The dual-track model means the decision to start small never becomes a tax you pay later when you grow.
There is a quieter benefit too. Because the managed tier is run by the same people who built the self-serve platform, the knowledge of your sending does not reset at the transition. The team that warms your dedicated IPs can see the history of how you sent on the shared pool, which receivers you reach, and where your placement has been strong or weak. A provider migration throws all of that context away and starts cold; an in-place upgrade carries it forward. The warming is faster and the early operational decisions are better because nobody is learning your sending from zero. In practice this can shave the riskiest weeks off a dedicated-IP ramp, because the warming schedule is informed by real history rather than guesswork about what your sending looks like.
/ 06 — Pricing
How the self-serve pricing model works.
Self-serve pricing is built around volume, because that is the thing that actually drives cost on a sending platform. You pay monthly for the volume you send, and the per-message rate steps down as your volume climbs. There is no per-seat licensing, so adding teammates to the dashboard costs nothing, and there is no annual contract locking you in — you scale up or down month to month as your real sending changes.
The dashboard shows your usage against the current pricing tier in real time, so you always know where you stand and there are no end-of-month surprises. If a campaign spikes your volume, you see the effect immediately rather than discovering it on an invoice. This transparency is deliberate: the self-serve model only works if you can reason about your own costs without talking to anyone.
When your volume reaches the point where dedicated infrastructure makes economic sense, the managed tier shifts to a different model — one built around the dedicated IPs and the operations team rather than raw message count. That is a conversation rather than a checkout, because at that scale the right structure depends on your specific sending. But the self-serve tier stays simple by design: send, see your usage, pay for what you sent.
Volume is the right basis for self-serve pricing precisely because it tracks the thing that actually costs money to deliver. Seats do not consume sending capacity; messages do. A team of two that sends ten million messages a month puts more load on the infrastructure than a team of fifty that sends ten thousand, and a pricing model built on volume reflects that honestly. It also means the model never penalizes you for collaboration — you can give the whole engineering team dashboard access without watching a per-seat meter, because the only meter that matters is the one counting what you actually sent.
/ 07 — Responsibilities
What self-serve handles, and what it leaves on you.
The honest division of labor matters, because the gap between what a platform handles and what you own is exactly where deliverability problems are born. On self-serve, the split looks like this.
The platform handles
The sending machinery
Connections to receivers, retry and backoff on temporary failures, bounce suppression, complaint processing, and the queue management that keeps mail moving under load. You never operate an MTA.
Authentication signing
Every message is DKIM-signed and SPF and DMARC aligned once your domain is verified. The cryptographic side of being trusted by receivers is automatic.
Pool reputation
On a shared pool, the aggregate reputation is maintained for you. You benefit from the standing of the pool without building it from scratch.
You stay responsible for
List quality
No platform can fix a bad list. Sending to addresses that bounce or to people who did not ask to hear from you damages reputation faster than any infrastructure can repair. Keeping the list clean is yours.
Watching placement
On self-serve, reading the dashboard and acting on the bounce and complaint events is your job. The instruments are provided; the attention is yours to give. This is the responsibility that managed lifts off you.
Content and consent
What you send and whether the recipient agreed to receive it sit entirely with you. The platform delivers; the judgment about what is worth delivering, and to whom, stays on your side of the line.
The pattern across that division is consistent: the platform owns the mechanics, you own the judgment. Self-serve works precisely when you are equipped to carry the judgment half — list hygiene, attention to placement, consent. The managed tier exists for when that half grows into more attention than you can spare, and it shifts the watching, though never the consent, onto a team. Even on managed, the questions of who you send to and whether they agreed to hear from you remain yours, because those are decisions about your business that no infrastructure provider can or should make for you. What changes is only how much of the day-to-day vigilance you personally have to supply.
/ Common questions
What teams ask about self-serve.
What does self-serve email SaaS actually mean?
Self-serve means you create an account, verify your sending domain, generate an API key or SMTP credentials, and start sending — without a sales call, a contract negotiation, or a provisioning wait. The whole onboarding is designed to take minutes. You manage your own integration, watch your own deliverability through the dashboard, and pay monthly based on the volume you send. It is the right model when you have a clear technical owner who can integrate the sending endpoint and keep an eye on placement, and when your volume is in the range where a shared or lightly-dedicated pool serves you well.
Should I send over the API or over SMTP?
Both reach the same inbox, and the account supports both at once. Use the API when you want richer features — templates, per-message tracking, batch sends with per-recipient data — and can write a small amount of integration code. Use SMTP when you want universal compatibility, when your framework already speaks SMTP, or when you are migrating from a self-hosted server and want to change as little as possible. Most teams use SMTP for the bulk of their sending and reach for the API on the specific flows that need its extra features. You do not have to choose one forever.
Where is the ceiling of self-serve, and how do I know I have hit it?
You have hit the ceiling when deliverability becomes something you cannot afford to watch yourself, when your volume grows past the point where a shared pool serves you, or when a missed campaign costs more than the price of having someone operate your sending. The signals are concrete: placement slipping on a shared pool, a deliverability incident you could not diagnose quickly, or a volume curve that now justifies dedicated IPs and the warming discipline they require. At that point self-serve is no longer the cheapest path — it is the one quietly costing you inbox placement.
Can I move from self-serve to managed without changing providers?
Yes, and that is the point of running both tracks on one platform. When you outgrow self-serve, you move to dedicated IPs we provision, warm, and operate — on the same account, with the same sending endpoints, without re-integrating. Your application keeps sending to the same place; what changes underneath is that a named team now operates the deliverability side. The migration most senders dread — switching email providers at exactly the moment their volume is growing fastest — is the one you do not have to make here.
How does volume-based pricing work on the self-serve tier?
You pay monthly for the volume you send, with the rate stepping down as your volume grows. There is no per-seat licensing and no long-term contract on the self-serve tier; you can scale up or down month to month as your sending changes. The dashboard shows your usage against the current tier so there are no billing surprises. When your volume reaches the point where dedicated infrastructure makes economic sense, the managed tier moves to a different model built around the IPs and operations rather than raw message count.
Do I still get deliverability tooling on self-serve, or only on managed?
Self-serve includes the tooling you need to watch your own placement: delivery logs, bounce and complaint events via webhook, authentication setup for SPF, DKIM, and DMARC, and a dashboard that surfaces the metrics that matter. What managed adds is people — a team that watches those metrics daily, holds postmaster contacts, and responds to incidents — rather than different data. On self-serve you have the instruments; on managed someone is reading them for you around the clock.
Start self-serve today. Grow into managed when you need it.
Create an account and send within the hour, or talk to engineering about where your sending is headed and whether to start on self-serve or go straight to managed. Either way, you only make the provider decision once.
Book infrastructure reviewRelated capabilities