Quickstart

MillionSend runs the same on MillionSend Cloud and on your own infrastructure — same dashboard, same API, same SDKs. Pick your deployment below; the tabs remember your choice across the docs.

1. Get MillionSendCopy Anchor Link

2. Verify a sending domainCopy Anchor Link

MillionSend only sends from domains you have verified.

1. In the dashboard, go to Domains and add a domain you control (e.g. acme.dev).
2. Add the DNS records it shows you — a DKIM TXT record plus MAIL FROM records — at your DNS provider.
3. Click Verify DNS records. MillionSend also resolves the records live, so you can see immediately which ones are still missing.

3. Create an API keyCopy Anchor Link

Go to API keys and create one. The ms_ token is shown once — copy it now. Keys can be scoped to full access or sending-only, and optionally pinned to a single domain.

4. Send an emailCopy Anchor Link

Your API base URL:

With curl:

curl -X POST https://api.millionsend.com/emails \
  -H "Authorization: Bearer ms_..." \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <onboarding@acme.dev>",
    "to": ["success@simulator.amazonses.com"],
    "subject": "Hello from MillionSend",
    "html": "<strong>It works!</strong>"
  }'

Or with the Node SDK (npm install millionsend):

import { MillionSend } from "millionsend";

const ms = new MillionSend("ms_...", { baseUrl: "https://api.millionsend.com" });

const { data, error } = await ms.emails.send({
  from: "Acme <onboarding@acme.dev>",
  to: "success@simulator.amazonses.com",
  subject: "Hello from MillionSend",
  html: "<strong>It works!</strong>",
});

if (error) console.error(error.name, error.message);
else console.log("sent", data.id);

Both return { "id": "..." }. Watch the email move from queued to delivered on the Emails page.

Already on Resend? Point the official Resend SDK at MillionSend instead — set RESEND_BASE_URL to your base URL and use your ms_ key. The wire format is identical.

TestingCopy Anchor Link

• To test end to end without emailing anyone, send to success@simulator.amazonses.com, as the examples above do: SES simulates the delivery, and the email shows as delivered, with the email.sent and email.delivered webhooks (no opens or clicks: nobody reads it). Labels work too: success+signup@simulator.amazonses.com.
• SES doesn't count simulator mail toward its own sending quota or bounce and complaint rates, but on Cloud each send still counts toward your plan's quota like any other email. On a self-hosted instance, the simulator works even while your AWS account is in the SES sandbox, and AWS still bills each message.
• The simulator's bounce@, complaint@ and suppressionlist@ addresses produce bounces and complaints that put the address on your team's suppression list and fire your webhooks as real ones do, but never count toward your bounce or complaint rate or pause sending. Each address is suppressed after its first use, so add a label for a fresh one: bounce+2@simulator.amazonses.com.
• Addresses at example.com, or under .test or .invalid, can't receive mail, so a send to one is refused with a 422 (see Errors).

Next stepsCopy Anchor Link

• Concepts for contacts, segments, topics, and broadcasts.
• SDKs for the nine official client libraries.
• API reference for every endpoint.
• Self-hosting for production deployment, the environment reference, and the SMTP relay.