Beginner guide

How Sendix fits together

Sendix is an email platform for applications. Your app calls the API, Sendix checks plan limits and domain authentication, then a worker signs and delivers the message. The dashboard is where you create keys, verify DNS, inspect logs, and receive inbound mail.

• PlanYour plan decides monthly sends, domain count, webhooks, templates, retention, and rate limits.
• DomainA verified domain proves that Sendix is allowed to send mail using your brand.
• API keyAPI keys authenticate your app. Scopes decide which resources the key can access.
• EmailSendix queues the message, signs it with DKIM, routes by recipient provider, and records events.
• InboundMX records let Sendix receive mail for the same domain and store it in your workspace.
• EventsLogs and webhooks show queued, accepted, opened, clicked, bounced, complained, and received events.

Plans and limits

Free workspaces are intentionally small. They are useful for testing, but production teams usually need Pro because it raises domain, send, webhook, template, and rate limits.

After a successful upgrade, Sendix updates the subscription and mirrors the plan into the account record. Quota checks use the active subscription first, so domain limits should change immediately after the payment is completed.

Sending domains

A sending domain is the domain in the From address, such as [email protected]. Receivers trust it only after SPF and DKIM pass.

1. 1

   Add the domain

   Open Domains - Add domain, enter the root domain, and keep sending enabled.

2. 2

   Copy DNS records

   Sendix generates records for SPF, DKIM, DMARC, Return-Path, and tracking. Copy the exact values shown in the dashboard; DKIM selectors are unique per domain.

3. 3

   Wait for propagation

   Some DNS providers publish immediately, others take 10-30 minutes. During that window, the dashboard can show a pending state even when the record was entered correctly.

4. 4

   Verify before sending

   SPF and DKIM must pass before production sending is accepted. DMARC and Return-Path are shown separately because they affect reporting, bounce handling, and deliverability.

Inbound receiving

Inbound receiving lets Sendix accept mail for addresses on your domain. Use it for reply handling, support aliases, product workflows, or automation triggers.

1. 1

   Enable receiving on the domain

   In the domain detail page, turn on receiving. Sendix first checks that the inbound SMTP receiver is healthy.

2. 2

   Publish MX records

   Add the MX records shown by the dashboard. If receiving is enabled but MX does not point to Sendix, incoming mail will still go to your old mail provider.

3. 3

   Create forwarding rules

   Use exact rules like [email protected] for one mailbox, or catch-all rules like *@example.com when every address should be accepted.

4. 4

   Read received mail

   Incoming messages appear in Inbox with sender, recipient, subject, received time, attachments, and forwarding events.

Send with the API

The API is REST + JSON. Create an API key with email:send, keep it secret, and send messages to https://sendix.dev/api/v1/emails.

curl -X POST https://sendix.dev/api/v1/emails \
  -H "Authorization: Bearer $SENDIX_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: welcome-user-123" \
  -d '{
    "from": "Acme <[email protected]>",
    "to": ["[email protected]"],
    "subject": "Welcome to Acme",
    "html": "<p>Your account is ready.</p>",
    "text": "Your account is ready.",
    "tags": [{ "name": "campaign", "value": "welcome" }]
  }'

• Use idempotencySet one stable key for retries so network failures do not create duplicate emails.
• Send from a verified domainThe domain in the From address must belong to your workspace and pass SPF/DKIM.
• Watch logsThe dashboard shows queued, accepted by MX, opened, clicked, bounced, and failed events.
• Respect rate limitsUse Retry-After or retry_after_sec when Sendix returns a rate limit response instead of retrying immediately.

Node SDK

The SDK is a small wrapper around the same API. It keeps your code cleaner, but every request still maps to a documented endpoint.

npm install sendix-node

import { Sendix } from 'sendix-node';

const sendix = new Sendix({ apiKey: process.env.SENDIX_API_KEY! });

const email = await sendix.emails.send({
  from: 'Acme <[email protected]>',
  to: ['[email protected]'],
  subject: 'Welcome to Acme',
  html: '<p>Your account is ready.</p>',
  text: 'Your account is ready.',
  tags: [{ name: 'campaign', value: 'welcome' }],
  idempotency_key: 'welcome-user-123',
});

console.log(email.id);

Common errors

Sendix errors are JSON objects with a machine-readable code. Treat the code as stable and show the message to operators when it helps explain the fix.

{
  "error": {
    "code": "domain_quota_exceeded",
    "message": "Domain limit of 1 reached for plan free",
    "details": {
      "plan": "free",
      "limit": 1,
      "used": 1
    }
  }
}

Launch checklist

Use this before pointing real production traffic at Sendix.

• The workspace is on the correct plan for expected domains and volume.
• SPF and DKIM are verified for every sending domain.
• Return-Path and tracking records are published for deliverability and analytics.
• API keys are scoped and stored outside source control.
• The first test email is visible in Logs and shows the expected final status.
• Webhooks are signed, verified by your app, and replayed successfully in a test.
• Inbound MX records are published only for domains or subdomains that should receive mail at Sendix.
• Forwarding rules are tested with a real inbound message.