Skip to main content
Delivery in SenderKit has two layers. A channel is the kind of message — email, SMS, push, or web push. A provider is the service that actually delivers it — Postmark, Twilio, APNs, and so on. You build templates against channels; SenderKit routes each send to the right provider behind a single interface.

​
Channels

SenderKit supports four channels:
  • email
  • sms
  • push — mobile push (APNs / FCM / Expo)
  • web-push — browser notifications via the Web Push Protocol + VAPID
push and web-push are distinct channels. They differ in recipient format, credentials, and payload shape, so each has its own provider connection. Both can be active in a workspace simultaneously. A template targets exactly one channel, fixed when it’s created. A send goes out on that channel; for raw sends you name the channel explicitly.

​
Providers

You connect your own provider accounts in the dashboard. SenderKit supports:
ChannelProviders
emailPostmark, SendGrid, Amazon SES, Mailgun, SparkPost
smsTwilio, Amazon SNS, Vonage, MessageBird
pushAPNs, FCM, Expo
web-pushVAPID (Web Push Protocol — no third-party service needed)
For web-push, connect a VAPID keypair in the dashboard (public key + private key + contact email). The recipient of each send is the JSON-encoded browser PushSubscription object (endpoint + p256dh/auth keys) — your application stores these after the user grants permission, then passes the JSON string as to on each send. Credentials are encrypted at rest. Each channel has one default connection, and a template can override that default to use a specific connection.

​
Built-in email sender

Every workspace comes with a built-in email connection that works immediately — no provider account or credentials required. Email sends from @tx.senderkit.email (a dedicated sending domain), so you can start sending in live mode on day one and connect your own provider later when you’re ready to use a custom from-address. The built-in sender enforces caps per plan to protect the shared domain’s reputation. The caps depend on whether you’re using the shared @tx.senderkit.email sender or a verified custom sending domain: Shared sender (@tx.senderkit.email)
PlanMonthly capDaily cap
Free50050
Starter1,500150
Pro15,0001,500
The shared sender is capped below the plan’s message quota because heavy volume on tx.senderkit.email would affect every workspace’s deliverability. Verifying a custom sending domain moves you to the higher tier below, isolating your reputation to your own domain. Verified custom sending domain (Starter and Pro only)
PlanMonthly capDaily cap
Starter5,000500
Pro50,0005,000
Sends that exceed the cap return HTTP 402 with code managed_send_limit_reached. Once you connect your own provider and set it as the workspace default, it replaces the built-in sender and the caps no longer apply.

​
Custom sending domains

Starter and Pro workspaces can connect their own sending domains and send from any address on a verified domain — without the shared @tx.senderkit.email address appearing to recipients. Adding a domain creates a dedicated managed connection in the Channels page. The built-in shared sender remains as the implicit fallback; your domain connection can be set as the workspace default or targeted per template.

​
DNS records to publish

After clicking Add domain in Dashboard → Channels, you’ll see the required and recommended DNS records:
RecordTypePurposeRequired?
senderkit._domainkey.{domain}TXTDKIM public key (white-label)Yes
send.{domain}MXCustom MAIL FROM subdomainYes
send.{domain}TXTMAIL FROM SPFYes
_dmarc.{domain}TXTDMARC policyRecommended
{domain}TXTRoot domain SPFRecommended
The dashboard probes DNS live and shows a green Set indicator once each record is detected. Recommended records improve deliverability reputation (e.g. third-party checkers like MXToolbox test the root domain) but don’t gate verification. The dashboard shows the exact record values to copy — if you already have a root SPF record, merge the SenderKit SPF mechanism into it rather than publishing a second v=spf1 record.

​
Verification

SenderKit polls DNS every 5 minutes. You can also click Check now at any time. Verification typically completes within minutes once records propagate. Claims expire after 72 hours — if the domain isn’t verified in time, you can resubmit.

​
From-address override on raw sends

Once a domain is verified, sendRaw accepts a from address whose domain exactly matches the verified domain: 
await senderkit.sendRaw({
  channel: "email",
  to: "customer@example.com",
  from: "billing@acme.com",   // acme.com must be a verified custom sending domain
  content: { subject: "Your invoice", html: "…" },
});
The from override is only honored on raw sends — template sends route through the template’s configured connection.

​
Caps

Connections on a verified custom domain use the verified custom sending domain cap tier shown in the table above — higher than the shared @tx.senderkit.email caps because your domain’s reputation is isolated from other workspaces. The caps are still enforced as a guard on the shared SES account’s overall AWS quota.
Custom sending domains require a Starter or Pro plan. Free workspaces see an upgrade prompt in the Channels page.

​
How a send picks a provider

You don’t choose a provider per send — SenderKit resolves one for you:
  1. The template’s provider override, if it has one.
  2. Otherwise, the workspace default for the channel.
  3. For email, if no custom provider is configured the built-in sender is used (subject to the caps above).
  4. For other channels without a configured provider (in live mode), the send fails with provider_not_configured.
Provider failover is not available yet — it’s planned. Today, if the chosen provider rejects a message, SenderKit retries the same connection a few times and then marks the message failed. It does not automatically fall back to a different provider.
In test mode, no provider is called at all — SenderKit short-circuits delivery, so an unconfigured channel still “sends” fine while you’re developing.

Sending

How a send is dispatched to a provider.

Messages

Which provider handled a message, and what happened.