Platform

Your own sending account

Send through your own Amazon SES or Mailgun instead of rootmail's.

rootmail can deliver your mail, or you can keep the provider you already use. Connect your own account and messages send on your credentials, your IPs and your reputation — rootmail stays the layer above it: per-client domains, per-client reputation scoring, suppression, threading and proof.

This is usually the right choice if you already send email at any scale. Your deliverability history is an asset; there is no reason to start a new one.

GET/v1/sending-providerWhat's connected, if anything.

POST/v1/sending-providerConnect an account. Credentials are checked before they're stored.

DELETE/v1/sending-providerDisconnect. Sending returns to rootmail's account.

sending-provider.ts

// Amazon SES — the key needs ses:SendEmail and ses:GetAccount.
await mail.sendingProvider.connect({
  provider: "ses",
  access_key_id: "AKIA…",
  secret_access_key: "…",
  region: "us-east-1",
});

// Or Mailgun — the domain must already be verified there.
await mail.sendingProvider.connect({
  provider: "mailgun",
  api_key: "…",
  domain: "mg.yourcompany.com",
  region: "us",
});

noteCredentials are encrypted at rest and never returned by the API — reads tell you whether they work, not what they are.

CarefulA connected SES account that is still in its own sandbox can only reach addresses it has verified. We check for that when you connect and say so, rather than letting you find out on a campaign.

What stays on rootmail

Sandbox sends never leave, whoever is connected, and our reserved test addresses always take the real path so a bounce test is a real bounce. If a connected account's credentials stop working we fall back to rootmail's own sending rather than failing your messages, and report it on the settings page.