Thanks for signing up.
", }), }); const { status, data } = await res.json(); // status is "success" or "error"; data.messages maps each recipient to an id ``` **Reloop** ```typescript const reloop = new Reloop({ apiKey: process.env.RELOOP_API_KEY!, // Self-hosted? Point it at your own instance: // baseUrl: "https://mail.example.com", }); const { response, emailError } = await reloop.mail.send({ from: "AcmeThanks for signing up.
", }); ``` A few differences: | | Reloop | Postal | |---|---|---| | Official SDKs | Node, Python, Go, PHP, Ruby, Rust, Java, .NET, Elixir | HTTP API, plus community clients | | Error format | `message`, `why` and `fix` | `status: "error"` with a code and message | | Stored templates | Yes, sent by ID with `{{{variables}}}` | No, send the rendered body | | React Email | Pass a component or rendered HTML | Pass rendered HTML | | Same API hosted and self-hosted | Yes | Self-hosted only | That last row is the practical one. With Reloop you can start on the hosted free tier, then move to your own server by changing `baseUrl`. Nothing else in your code changes. --- ## Deliverability controls This is where Postal has a lot of depth for a pure MTA. Its [feature list](https://docs.postalserver.io/welcome/feature-list) includes: - **Multiple IP pools**, with rules that route specific senders or recipients to specific IPs - **Per-server send rate limits** - DKIM signing, a built-in suppression list, and automated DNS checks - **Development mode**, which holds messages instead of delivering them while you test - Click and open tracking, message tagging, and full message and queue history with search Reloop sends through KumoMTA with per-destination throttling and automatic pauses when bounce or complaint rates spike. It handles bounces and complaints, keeps one suppression list across transactional mail and campaigns, and includes a dedicated IP on the hosted Growth plan. Read [how bounce processing works](/blog/email-bounce-processing-automation). If fine-grained IP pool routing is your main requirement, for example you run mail for many separate brands or clients and need to isolate their reputations, Postal's model is built for exactly that. --- ## Receiving email Both receive mail on your domain. What happens next is very different. **Postal** routes inbound mail. A message can be forwarded to an **HTTP endpoint** (as form data or JSON, raw or parsed, with replies and signatures optionally split out of the body), to another **SMTP server**, or to an **email address**. It runs spam and virus checks with SpamAssassin, rspamd and ClamAV. Storing, threading and replying is up to your application. **Reloop** receives mail into **mailboxes**. Messages are stored, threaded, spam-scored with Rspamd, and readable over the API, the [MCP server](/docs/integrations/ai-tools/mcp-server) or IMAP. You can reply in-thread with one call, and there's an `email.received` webhook if you also want push notifications. | | Reloop | Postal | |---|---|---| | Receive on your domain | Yes | Yes | | Forward to your app over HTTP | Yes (`email.received` webhook) | Yes | | Stored mailboxes with threads | Yes | No | | Reply in thread via API | Yes | Build it yourself | | IMAP access | Yes | No | | MCP access for AI agents | Yes | No | If you're building an AI agent that handles email, a support inbox, or "reply to this email" features, Reloop saves you from building the storage and threading layer. See [build an AI agent that reads and replies to email](/blog/build-ai-agent-sends-emails). --- ## Webhooks Both send webhooks for delivery events. - **Postal** sends events such as `MessageSent`, `MessageDelayed`, `MessageDeliveryFailed`, `MessageHeld`, `MessageBounced`, `MessageLinkClicked`, `MessageLoaded` and `DomainDNSError`, and keeps 7 days of webhook request history in the UI ([webhook docs](https://docs.postalserver.io/developer/webhooks)). - **Reloop** sends `email.delivered`, `email.bounced`, `email.complained`, `email.opened`, `email.clicked`, `email.received` and more, signed with HMAC-SHA256 in the `Reloop-Signature` header and retried with backoff. See [how we built webhook delivery](/blog/building-webhook-delivery-system). --- ## Beyond sending: contacts, campaigns and automations Postal deliberately stops at mail delivery. For newsletters, onboarding sequences or product announcements, you'd pair it with another tool and keep the two suppression lists in sync yourself. Reloop includes: - **Contacts** with custom properties, groups and subscription channels - **Broadcast campaigns** with scheduling - **Event-triggered automations**: delays, conditions and email steps that start when your app tracks an event like `user.signed_up` - **Stored templates** with `{{{variables}}}` All of it shares one suppression list with your transactional mail. See [welcome sequences that convert](/blog/welcome-email-sequences-that-convert) for a worked example. --- ## Where Postal is the better choice Being honest about it: - **You want a pure MTA and nothing more.** Postal is mature, does one job, and has a smaller footprint to run and secure. - **You run mail for many tenants** and need multiple IP pools with per-sender or per-recipient routing rules. - **You prefer MIT** over Apache 2.0, or your team already runs Ruby and MariaDB and is comfortable operating them. - **You already run Postal** and it's working. Migrating a stable mail server for features you don't need isn't worth the warm-up. ## Where Reloop is the better choice - **You want a hosted option** today, with the freedom to self-host later on the same API. - **You need inbound mail as real inboxes**, especially for AI agents, with IMAP and MCP access. - **You want transactional mail, campaigns and automations** in one product with one suppression list. - **You want official SDKs** in your language instead of calling a raw HTTP API. --- ## Switching from Postal to Reloop 1. **Install or sign up.** Run the [self-host installer](/self-host) on a new server, or create a hosted account. Keep Postal running for now. 2. **Add your domain** and publish Reloop's DKIM record (`reloop._domainkey`). Merge `include:reloop.sh` into your SPF record if you send hosted. Don't add a second SPF record. 3. **Swap the send call.** Replace `POST /api/v1/messages/message` with `reloop.mail.send`, and rename `html_body` → `html` and `plain_body` → `text`. SMTP senders only need new host and credentials. 4. **Move inbound routes.** For each Postal route, create a Reloop mailbox, or keep your HTTP handler and subscribe it to `email.received`. 5. **Port webhooks.** Map `MessageSent` → `email.delivered`, `MessageBounced` and `MessageDeliveryFailed` → `email.bounced`, `MessageLinkClicked` → `email.clicked` and `MessageLoaded` → `email.opened`, and verify the `Reloop-Signature` header. 6. **Import suppressions** so you don't re-mail addresses that bounced on Postal. 7. **Ramp traffic** from 10% to 100% over one to two weeks while the new IP warms up, then retire Postal's DNS records and server. Our [SendGrid migration guide](/blog/migrating-from-sendgrid) walks through the traffic split and suppression import in more detail. --- ## FAQ