Thanks for signing up.
" } }, }, }, ConfigurationSetName: "transactional", }), ); ``` **Reloop** ```typescript const reloop = new Reloop({ apiKey: process.env.RELOOP_API_KEY! }); const { response, emailError } = await reloop.mail.send({ from: "AcmeThanks for signing up.
", }); ``` The SES call needs IAM credentials with `ses:SendEmail` permission and a region. Reloop needs an API key. SES throws exceptions such as `MessageRejected`; Reloop returns errors as values, with a `message`, a `why` and a `fix`: ```json { "message": "Domain not found", "why": "The domain mail.acme.com was not found or is not authorized for your organization", "fix": "Ensure the domain is registered and verified in your dashboard" } ``` --- ## Bounces, complaints and suppression This is where most of the SES glue code lives. **On SES**, delivery events are published through a configuration set to SNS, EventBridge, Kinesis Firehose or CloudWatch. You then: 1. Create the topic or rule and subscribe a Lambda, queue or HTTPS endpoint. 2. Parse each event and store it against the message. 3. Decide which bounces are permanent and add those addresses to a suppression list (SES has an account-level list, but your app usually needs its own view too). 4. Alert someone when bounce or complaint rates climb, because AWS reviews and can pause accounts that stay too high. **On Reloop**, the same events arrive as webhooks (`email.delivered`, `email.bounced`, `email.complained` and so on), signed with HMAC-SHA256 in the `Reloop-Signature` header. Hard bounces and complaints are suppressed automatically, every message has a searchable log, and sending pauses itself when bounce or complaint rates spike. See [how bounce processing works](/blog/email-bounce-processing-automation). | | Reloop | Amazon SES | |---|---|---| | Delivery events | Signed webhooks | SNS / EventBridge / Firehose | | Per-message log | Built in, searchable | Build it (e.g. events to S3 or a database) | | Automatic suppression | Yes | Account-level list; app view is DIY | | Dashboard | Built in | CloudWatch | | Templates | Editor, sent by ID with `{{{variables}}}` | API-managed templates | --- ## Receiving email and agent inboxes **SES** can receive mail on your domain. Receipt rules hand each message to S3, SNS or Lambda, and from there storage, threading, spam handling and replies are yours to build. **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 for push notifications. That's the difference between "a raw MIME file landed in a bucket" and "an AI agent can read the conversation and answer it." If you're building agents, support inboxes or reply-by-email features, see [build an AI agent that reads and replies to email](/blog/build-ai-agent-sends-emails). --- ## Campaigns and automations SES is a sending service. Newsletters, contact lists, unsubscribe handling and lifecycle sequences need another tool or your own code. Reloop includes contacts with custom properties, groups, subscription channels, scheduled broadcasts, and **event-triggered automations** with delays, conditions and email steps. Transactional and marketing mail share one suppression list, so an address that bounced on a receipt doesn't get your next newsletter. See [welcome sequences that convert](/blog/welcome-email-sequences-that-convert) for an example. --- ## Deliverability Both handle the fundamentals: SPF, DKIM, DMARC, bounce and complaint processing. Deliverability mostly depends on your domain setup and list hygiene, not the provider's logo. - **Sending path.** SES uses AWS's shared pools, with dedicated IPs as an add-on. Reloop runs its own MTA (KumoMTA) with per-domain throttling, and includes a dedicated IP on Growth ($20/mo). - **Reputation guardrails.** AWS watches your bounce and complaint rates and can put your account under review. Reloop pauses sending automatically when rates spike, before a mailbox provider has to. - **Tools.** Reloop ships free [domain reputation](/tools/domain-reputation-checker), [blocklist](/tools/blocklist-checker) and [auth](/tools/auth-checker) checkers you can run before you send. --- ## Self-hosting and lock-in SES is AWS-managed only, and the glue you build around it (SNS topics, Lambdas, IAM policies) is AWS-specific too. Reloop is Apache 2.0. You can start on Reloop Cloud, then move to your own server, including inside your AWS account, with the [one-command installer](/self-host). Point the SDK's `baseUrl` at your instance and nothing else in your code changes. That keeps data in your VPC without assembling the product yourself. Read [self-hosted email infrastructure](/blog/self-hosted-email-infrastructure) for what running it really involves. --- ## Where Amazon SES is the better choice Being honest about it: - **You send millions of emails a month** and already have a platform team. At that scale the per-email savings can pay for the glue code. - **You only need a pipe.** Password resets from one service, no dashboard, no campaigns, no inbound, and an engineer who's happy to own the SNS wiring. - **You're all-in on AWS** and your compliance setup requires everything to be an AWS-managed service. ## Where Reloop is the better choice - **You want logs, webhooks, suppression and templates on day one** instead of building them. - **You need inbound mail as real inboxes**, especially for AI agents. - **You want transactional mail, campaigns and automations** in one product with one suppression list. - **You want open source or self-hosting** without being tied to one cloud. --- ## Switching from SES to Reloop 1. **Add your domain in Reloop** and publish the DKIM record (`reloop._domainkey`). Merge `include:reloop.sh` into your existing SPF record. Don't add a second SPF record. 2. **Swap the client.** Replace `SendEmailCommand` calls with `reloop.mail.send`. If you send through SES's SMTP interface, point it at `smtp.reloop.sh` and use your Reloop API key as both username and password. 3. **Move templates.** Change SES's `{{variable}}` placeholders to triple braces: `{{{variable}}}`. 4. **Replace the event pipeline.** Point a webhook at a new handler, verify the `Reloop-Signature` header, and retire the SNS topics and Lambdas once traffic has moved. 5. **Import suppressions** from SES's account-level suppression list so you don't re-mail addresses that already bounced. 6. **Ramp traffic** from 10% to 100% over a week or two, then remove SES's DNS records. Our [SendGrid migration guide](/blog/migrating-from-sendgrid) covers the traffic-split flag and suppression import in more detail; the same approach works when coming from SES. --- ## FAQ