Sending providers
Mimeo owns your email operation. A sending provider owns delivery. Keeping those separate is why you can change who delivers your mail without changing anything about how you run it.
The split
| Your instance | The provider |
|---|---|
| People, custom fields, tags | Accepting a message and delivering it |
| Events, timelines, attribution | Reputation and deliverability infrastructure |
| Money history and lifetime spend | Bounce and complaint handling at the transport level |
| Emails, templates, components, buttons | Its own suppression list |
| Open and click tracking, and the stats built on it | — |
| Unsubscribe records, with source and reason | — |
| The send log | — |
Everything in the left column is in your database. If you move providers, it all stays exactly as it is.
Duties
A connected provider doesn't automatically do everything. You assign it duties — named jobs it's responsible for. Today the duty that matters is one-off sending: the provider that handles individual sends and test sends.
Duties exist so that a future install can route different kinds of mail through different providers as more sending types arrive. For now, connect one provider and give it the one-off sending duty.
What stays authoritative in core
Providers vary in what they can report back, so Mimeo deliberately doesn't depend on them for anything it can determine itself.
- Engagement is ours. Mimeo injects its own open pixel and wraps its own links, so opens and clicks are measured consistently no matter who delivers. See Tracking.
- Unsubscribes are ours first. An opt-out is recorded locally with its source and reason, then pushed to the provider where the provider supports it. The local record is the one that governs whether you send.
- Acceptance is not delivery. The send log records that the provider accepted the message. Whether it reached the inbox is separate, and reconciles later through suppression sync.
Available providers
- Bento A native bulk pipeline, polled suppression, and its own unsubscribe headers.
- Postmark Message streams, webhooks, and a suppression list Mimeo reads and writes both ways.
- Resend A bare pipe: suppression by webhook, no bulk API, and the unsubscribe headers are ours.
Three providers ship, and they were chosen because they are shaped differently in every way that matters. Bento has a native bulk broadcast pipeline, no webhooks, polled suppression, and injects its own List-Unsubscribe headers. Resend is a bare pipe that fans out through Mimeo's own paced sender, pushes suppression by webhook, has no suppression read API at all, and leaves the headers to us. Postmark splits mail across message streams, reports by webhook, and keeps a per-stream suppression list Mimeo both reads and writes.
Anything the provider layer got wrong would show up as one of those three needing a special case above the seam. None does — which is what makes a fourth straightforward. Anyone who needs one writes it against the conformance suite, and a green run is what certifies it.
Switching providers
A Settings change: enter the credentials, press Verify connection, reassign the duties. Your people, suppression list, flows, sequences, emails, tracking and history all stay exactly where they are — none of it was ever the provider's.
The one thing to know is that duties are validated against what each adapter actually declares. An adapter with no bulk pipeline can't be made the broadcast sender, and the Settings page says so at the point of choosing rather than at the point of sending.