The Amazon SES alternative, fully assembled

What arrives assembled

Amazon sells sending. Everything around it is yours to build on AWS.

Per-message logs are the sharpest line in that table. Your plan keeps 7 days on Free and 90 days on Volume, so a support question from last month still has an answer. The Amazon console shows four charts of hourly counts over 14 days. Anything finer needs a configuration set, an event destination and a store you run yourself.

Amazon also holds a new account in a sandbox. That account sends 200 messages a day, to verified recipients only, until Amazon reviews the production-access request.

Feature by feature

The rows below hold what each platform documents today. A docs link opens the mailkube page behind that row.

Dedicated IPs are included from the Elite plan. Elite carries one at 100,000 emails a month, and Volume carries six at 750,000. Each new one warms on a six-stage ladder, from 50 messages a day to 10,000. Amazon sells a standard dedicated IP at $24.95 a month and warms it on a 45-day schedule.

Where your data lives

Customer data is stored in the European Union. Our infrastructure runs in European data centres, in the French OVHcloud group.

Amazon runs SES in 29 regions, seven of them European, and quotas, identities and suppression lists belong to the region you pick. mailkube runs one region, and every account is in it.

The detail is in the data processing agreement.

Two transports, headers included

POST to the REST API, or point the SMTP client you already run at smtp.mailkube.com. Everything the API takes as a JSON field, SMTP takes as a header. Those headers are stripped before the message reaches the recipient.

• X-Mailkube-Tags carries the same tag list as the REST tags field
• X-Mailkube-Topic attributes the send to a topic, so recipients who opted out are filtered
• X-Mailkube-Template-Id and X-Mailkube-Template-Version render a saved template server-side

An SMTP send is the same message as an API send. It lands in the same logs, counts against the same quota and fires the same webhook events. The SMTP reference(opens in a new tab) lists every header, reply code and rate limit.

Amazon relays SMTP on email-smtp.<region>.amazonaws.com and documents a message-tag header and a list-management header. Its list management runs on one contact list per AWS account, holding up to 20 topics. No header there renders a stored template.

Two more differences sit on the send itself. Every mailkube send takes an idempotency key(opens in a new tab) , and a retried call returns the first result instead of sending twice. Every webhook arrives signed with an HMAC your SDK verifies for you. Amazon documents neither: its send API has no idempotency parameter, and delivery events reach you through an Amazon SNS topic whose signatures you verify yourself.

Your stack, already covered

Official SDKs cover Node, Python, Go, Java, PHP and Ruby. Django, Laravel, Rails and Spring Boot each have a package of their own. It plugs into the framework’s mail layer, and every client verifies your webhook signatures for you.

Amazon ships clients for more languages than that, and an aws command for its whole cloud. It publishes no framework package, so a Django or Laravel project wires the transport itself.

The CLI is a single binary. It sends over either transport and manages scheduled sends. While you develop, it runs a local webhook receiver. It carries a skill file, and a coding assistant reads the real command surface. Start from the SDK documentation(opens in a new tab) or the CLI guide(opens in a new tab) .

Migrating from Amazon SES

Install your language’s client, then replace the constructor and the key. The send call keeps its shape, with lowercase field names and no region to choose.

import {
  SESv2Client,
  SendEmailCommand,
} from "@aws-sdk/client-sesv2";

const client = new SESv2Client({ region: "eu-west-1" });

const email = await client.send(
  new SendEmailCommand({
    FromEmailAddress: "hello@example.com",
    Destination: { ToAddresses: ["customer@example.com"] },
    Content: {
      Simple: {
        Subject: { Data: "Hello world" },
        Body: { Html: { Data: "<p>It works!</p>" } },
      },
    },
  }),
);

import { Mailkube } from "@mailkube/mailkube-node";

const client = new Mailkube({ apiKey: process.env.MAILKUBE_API_KEY });

const email = await client.emails.send({
  from: "Acme <hello@example.com>",
  to: "customer@example.com",
  subject: "Hello world",
  html: "<p>It works!</p>",
});

SMTP is just as short. Change the host, the port and the credential in your mailer, and leave everything else alone. The messages you already send go out unchanged, and tags, topics and templates arrive as headers when you want them. Nothing forces a cutover date: run both platforms side by side and move one service at a time. The quickstart(opens in a new tab) covers the REST path and the SMTP guide(opens in a new tab) covers the relay.

When Amazon SES is the better fit

Amazon sells sending at infrastructure prices. A team that has already built the logging, the dashboards and the webhook plumbing pays less for the sending itself.

SES also sits inside AWS. IAM permissions, CloudTrail audit trails, KMS keys and private VPC endpoints come with the account, and a buyer already cleared on AWS inherits all of them. Messages there run to 40 MB, against 15 MB on a paid plan here.

The pricing page details every plan. The REST API and SMTP relay pages go deeper on the two transports.