Domains & deliverability

Sending from your own authenticated domain is what separates the inbox from the spam folder. When you add a domain, Sendara registers it with the email provider, enables DKIM signing, sets up a custom MAIL FROM, and hands back every DNS record you need to publish. From there it manages reputation, bounces, and suppressions on top.

Add a domain

Register the domain (or subdomain) you want to send from. The response is the full domain object, including the DNS records to publish and a per-record pending status. Requires a key with the admin scope.

The response carries everything you need to configure DNS:

{
  "id": "dom_1f8c0a2b3d4e5f60718293a4b5c6d7e8",
  "domain": "mail.acme.com",
  "dkim_status": "pending",
  "spf_status": "pending",
  "dmarc_status": "pending",
  "txt_status": "pending",
  "mail_from_domain": "mail.mail.acme.com",
  "dns_records": [
    { "type": "CNAME", "name": "abc123._domainkey.mail.acme.com", "value": "abc123.dkim.amazonses.com" },
    { "type": "CNAME", "name": "def456._domainkey.mail.acme.com", "value": "def456.dkim.amazonses.com" },
    { "type": "CNAME", "name": "ghi789._domainkey.mail.acme.com", "value": "ghi789.dkim.amazonses.com" },
    { "type": "MX",    "name": "mail.mail.acme.com",        "value": "10 feedback-smtp.us-east-1.amazonses.com" },
    { "type": "TXT",   "name": "mail.mail.acme.com",        "value": "v=spf1 include:amazonses.com ~all" },
    { "type": "TXT",   "name": "_dmarc.mail.acme.com",      "value": "v=DMARC1; p=none; rua=mailto:dmarc@mail.acme.com" }
  ],
  "created_at": "2026-06-14T09:00:00Z",
  "updated_at": "2026-06-14T09:00:00Z"
}

DNS records

A custom domain returns six records: three DKIM CNAMEs for signing, an MX and a TXT for the custom MAIL FROM, and a TXT for DMARC. Publish all of them exactly as returned — the names and values below are illustrative (your DKIM tokens and region will differ), but the shape is exactly what the API gives you.

What each record does:

• DKIM— three CNAMEs that delegate signing to the provider. They let receivers cryptographically verify your mail wasn't altered in transit and confirm it came from you. All three must resolve for DKIM to pass.
• MAIL FROM (MX + SPF) — a custom return-path subdomain (mail.<your-domain>). The MX routes bounce and feedback notifications back to the provider; the SPF TXT authorizes the provider to send for that subdomain. Together they make SPF align with your domain, which strengthens DMARC.
• DMARC — a policy TXT at _dmarc.<your-domain> telling receivers what to do with mail that fails authentication, and where to send aggregate reports.

Each record object in the API response has this shape:

Provider quirks

• Some DNS UIs append the zone automatically. If your provider already shows .acme.com next to the input, enter only the host part (e.g. abc123._domainkey.mail), not the fully qualified name.
• For the MX record, the value 10 feedback-smtp... is priority 10 plus the target. If your provider has a separate priority field, put 10 there and the hostname in the value.
• CNAME values must point to the provider host exactly — don't add a trailing comment or wrap them in quotes. TXT values may be quoted by your provider; that's fine.

Verify & re-verify

After publishing, trigger a check. Sendara re-reads DNS and the provider identity status and returns a per-record result. Each record carries a status of pending, verified, or failed; fully_verified is true only when DKIM, SPF, the MAIL FROM, and DMARC all pass.

A partial result is normal while DNS propagates — DKIM often verifies within minutes while DMARC lags:

{
  "domain": "mail.acme.com",
  "fully_verified": false,
  "results": [
    { "field": "dkim_status",  "type": "CNAME", "name": "abc123._domainkey.mail.acme.com", "status": "verified" },
    { "field": "dkim_status",  "type": "CNAME", "name": "def456._domainkey.mail.acme.com", "status": "verified" },
    { "field": "dkim_status",  "type": "CNAME", "name": "ghi789._domainkey.mail.acme.com", "status": "verified" },
    { "field": "txt_status",   "type": "MX",    "name": "mail.mail.acme.com",   "status": "verified" },
    { "field": "spf_status",   "type": "TXT",   "name": "mail.mail.acme.com",   "status": "verified" },
    { "field": "dmarc_status", "type": "TXT",   "name": "_dmarc.mail.acme.com", "status": "pending",
      "detail": "no _dmarc TXT record found yet" }
  ]
}

Verification is idempotent and safe to repeat — call it as often as you like. Propagation usually completes within minutes but can take a few hours depending on your provider and TTLs. We also re-check verified domains periodically in the background, so if a record is later removed the status flips back to failed and we notify you.

Shared sender vs. your own domain

You can start sending before you own a verified domain, but with guardrails. The two modes:

• Shared onboarding sender — omit from_email and Sendara sends from a platform-owned address on an already-verified domain. To protect that shared reputation, an unverified account may only send to its own account emailthis way. It's meant for wiring up your integration and seeing your first delivery — not for sending to customers.
• Your own verified domain — once a domain is fully verified, set from_email to any address on it and send to anyone. This is the only mode for production traffic: your reputation, your inbox placement, your DMARC alignment.

To send real mail to your own verified test addresses before going fully live — useful for UAT — register and verify up to three of your own recipients and use test_send: true. See Sending for the test-send flow.

Reputation & warmup

Authentication gets you to the inbox; reputationkeeps you there. A brand-new domain and IP have no sending history, so mailbox providers throttle and scrutinize you until you've proven you send wanted mail. Ramp up gradually rather than blasting your full list on day one.

• Warm up over ~2–4 weeks.Start with a few hundred of your most engaged recipients per day and roughly double the daily volume as long as bounce and complaint rates stay low. Sudden 10× jumps from a cold domain are the fastest way to land in spam.
• Send your best mail first. Early on, prioritize transactional and recently-active recipients — high opens and low complaints early build a reputation you can spend later on broader sends.
• Authenticate everything. DKIM, SPF, and DMARC must all be in place and aligned before you scale. Unauthenticated mail from a new domain is treated with maximum suspicion.
• Keep bounces and complaints low. Mailbox providers watch your hard-bounce rate (aim well under 2%) and complaint rate (keep under 0.1%). Clean your list and never send to addresses that already bounced.
• Make unsubscribing easy.A visible unsubscribe link beats a spam complaint every time — a complaint hurts your reputation, an unsubscribe doesn't.

Once you've published a permissive DMARC policy (p=none) and confirmed your legitimate mail passes, tighten it over time — move to p=quarantine and eventually p=reject — to stop others from spoofing your domain.

Suppressions

Hard bounces and complaints are added to your suppression list automatically, and future sends to those recipients are blocked with 409 recipient_suppressed. This protects your reputation without any work on your part — a suppressed address can crater your standing fast if you keep mailing it.

You can also manage the list directly:

curl https://api.sendara.dev/v1/suppressions \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "channel": "email", "recipient": "bounce@acme.com", "reason": "hard_bounce" }'

Deliverability checklist

• Authenticate every sending domain with DKIM, SPF, and DMARC, and confirm alignment.
• Send from a dedicated subdomain; keep transactional and marketing streams separate.
• Warm up new domains gradually — engaged recipients first, volume ramped over weeks.
• Send only to recipients who expect your mail; honor unsubscribes promptly.
• Never re-send to a suppressed address.
• Watch your events — rising bounce or complaint rates are an early warning. Pull DMARC aggregate reports (the rua mailbox) to catch authentication failures and spoofing.