Introduction

adbtd is bare-metal email infrastructure. You sign up, order mailboxes, and we provision your own SMTP/IMAP stack on a virgin dedicated IP, under your domain, with no trace of us in the headers. This guide walks you from zero to first send.

Quick start

Five minutes from “create account” to “first message in inbox”:

1. Create an account at adbtd.com. Email + password, no card.
2. Order mailboxes: pick a count (10, 100, 1000), point a domain you own at us, pick how many dedicated IPs to attach.
3. Confirm checkout. Provisioning runs in parallel. Typical batch is around a minute when DNS is published right away.
4. Hit the inbox via the dashboard, or read it through the API. Mailbox passwords are shown once at provisioning in the dashboard — copy them into your client then.

# once a domain is added, bulk-create mailboxes from your terminal
curl -X POST https://adbtd.com/api/v1/mailboxes \
  -H "Authorization: Bearer adbtd_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "emails": ["lena@acme.com", "max@acme.com", "rita@acme.com"] }'

Core concepts

Five primitives. Everything in adbtd composes from these:

workspace

Top-level container. Holds domains, mailboxes, IPs, teammates, and one billing currency. Auto-created on signup; spin up additional ones from the dashboard if you run multiple brands or clients.

domain

An RFC-compliant DNS zone you already own at any registrar. After ordering, SPF / DKIM / DMARC / MTA-STS records are surfaced for you to publish.

mailbox

local@domain. Provisioned with IMAP + SMTP credentials. Lives inside your workspace’s dovecot container.

dedicated IP

An IPv4 address allocated only to your workspace. Assigned to one or more domains for outbound relay.

tenant

The set of containers (postfix, dovecot, rspamd) running on bare metal that serve your workspace. Spun up on first order, scaled with usage.

Order mailboxes

The order flow is the centerpiece. Three input modes for naming, optional bulk provisioning, transparent pricing.

Naming modes

• CSV import. Drop a file with one local-part per line. We dedupe, validate against RFC 5322, and report rejects before charging.
• Manual. A textarea. Same validation, useful for <50 mailboxes.
• Generate. Pick a pattern. {first}.{last}, {first}{n}, {role}-{n}, {first}@. We expand from a seeded name pool. Reproducible per order.

Distribution across domains

If you order 240 mailboxes across 8 domains, we distribute round-robin (30/domain). To override, set distribution: { "acme.com": 50, "acme-hq.co": 30, … } when calling the API directly.

Use your own domain

adbtd runs your stack against a domain you already own at any registrar. After ordering, the dashboard surfaces the records to add at your DNS host:

All records are workspace-scoped. The adbtd-mta.net hostnames you publish are aliases, but recipients only ever see acme.com in the From, Return-Path, and DKIM signature.

Dedicated IPs

Every workspace ships with at least one dedicated IPv4. Order more from the dashboard or via POST /v1/ips.

Allocation & checks

When you order an IP we:

1. Pull a fresh /32 from our upstream allocator.
2. Sweep ~30 RBLs (Spamhaus, SORBS, Barracuda, etc.). If any hit, we discard and retry.
3. Reverse-DNS to mta-{n}.acme.adbtd-mta.net aligned to your domain.
4. Hand off to your tenant container as a relay outbound interface.

Per-domain assignment

By default, all IPs in your workspace serve all domains in your workspace. Pin specific IPs to specific domains in the IP detail panel. Useful if you want to isolate transactional mail from outreach mail on separate IPs.

Warmup & reputation

Cold IPs need warming. We don’t gate your sending, but we do recommend a curve and surface health metrics in the dashboard.

Recommended curve

SMTP & IMAP access

Every mailbox ships with full ESMTP submit and IMAPS access. Connection details:

SMTP host

smtp.{workspace}.adbtd-mta.net · port 465 (TLS) or 587 (STARTTLS)

IMAP host

imap.{workspace}.adbtd-mta.net · port 993 (TLS)

username

full email address. lena@acme.com

password

per-mailbox; rotate from the dashboard.

Passwords are surfaced exactly once — in the dashboard at the moment a mailbox is provisioned. Copy them then; the API returns the SMTP / IMAP host and port via Mailboxes › Get a mailbox but never the password.

Inbound webhooks

Every inbound message can be mirrored to an HTTP endpoint of your choice. Register a webhook against one or more verified domains and we fire a POST the moment a message lands in any user mailbox on those domains. Useful for support routing, CRM updates, agent triggers, Slack / Discord pings — anything that wants to react in real time to mail you receive.

Three flavors

HTTPS

Raw JSON POST with the canonical event payload. Signed with an HMAC-SHA256 header (X-Adbtd-Signature) you verify with the per-webhook secret. The integration mode for anyone building their own backend.

Slack

Paste a Slack incoming-webhook URL. We POST a formatted text + blocks message with the sender, subject, and the first 500 chars of the body. No backend required.

Discord

Paste a Discord channel webhook URL. We POST a one-embed message with title, sender, recipients, and body preview. Drops straight into the channel.

Slack and Discord URLs carry their own per-channel token so we don’t sign those requests. For the HTTPS transport, verify like this:

const sig = req.headers["x-adbtd-signature"]; 
const { t, v1 } = Object.fromEntries(sig.split(",").map(p => p.split("="))); 
const expected = crypto.createHmac("sha256", secret)
  .update(`${t}.${rawBody}`)
  .digest("hex");
const ok = Math.abs(Date.now() / 1000 - Number(t)) < 300 &&
  crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(v1));

What fires

One event per webhook per inbound message. Multi-recipient mail to two of your domains doesn’t double-fire — we dedupe on (webhook_id, message_id). The full envelope-To list is in data.to[]; the recipient that triggered the match is in data.triggered_by.

Each webhook scopes to one of three audiences:

• User mailboxes — default. Fires on every inbound to customer-created mailboxes (the ones you ordered).
• System (roles@) — fires on inbound to the workspace’s consolidated role inbox (roles@ / dmarc@ / abuse@ / postmaster@ / tls-reports@). Useful for piping DMARC reports + feedback-loop traffic into your own systems.
• All — both.

Payload

The canonical (HTTPS) event:

{
  "id": "evt_01HE…",
  "type": "email.received",
  "created": "2026-05-12T08:14:22.103Z",
  "workspace_id": "ws_…",
  "webhook_id": "wh_…",
  "data": {
    "message_id": "<CAJ…@mail.example.com>",
    "from": { "address": "alice@example.com", "name": "Alice" },
    "to": [{ "address": "bob@acme.com" }],
    "subject": "Re: invoice",
    "date": "2026-05-12T08:14:20Z",
    "headers": { /* dkim-signature, authentication-results, … */ },
    "text": "Hey Bob — quick thought…",
    "html": "<div>…</div>",
    "attachments": [{ "filename": "invoice.pdf", "content_type": "application/pdf",
      "size": 84211, "content_base64": "JVBERi0…" }],
    "triggered_by": "bob@acme.com"
  }
}

Attachments are inlined as base64. Payloads over 5 MB ship without attachments and carry attachments_omitted: true so your endpoint can branch.

Retries & delivery log

Delivery is at-least-once. Each event carries a stable id — dedupe on that. Failed POSTs (5xx, network) retry on a jittered 60s · 5m · 30m schedule; after 4 attempts the delivery is marked failed. 4xx responses are terminal (we don’t retry past a misconfigured endpoint). Every attempt — success, retry, fail — is visible in the dashboard with the response code, latency, and a snippet of the response body. A resend button re-fires the event with the same metadata (we don’t retain bodies past first-delivery success; for full-body recovery, fetch from the mailbox via IMAP or the API).

Setup

1. Dashboard → API · Webhooks → new webhook.
2. Pick a name, transport, URL, mailbox scope, and the domain(s) you want to fire on. Only verified domains can be selected.
3. For HTTPS, copy the signing secret — it’s shown once. Store it somewhere safe; you’ll use it to verify the HMAC.
4. Send yourself a test mail and watch the delivery land in the log.

See API reference › Webhook payload for the full schema and signature format.

Architecture

adbtd runs on bare-metal servers. Each workspace gets a dedicated set of containers (postfix, dovecot, rspamd) wired to its own outbound IPs. Nothing is multiplexed across customers at the mail-server layer.

Deliverability

10/10 across mail-tester, GlockApps, MXToolbox, ISNotSpam, and DKIMValidator on every workspace, day one. We test newly-provisioned tenants automatically before handing them over to you.

What’s configured for you

• SPF, DKIM (2048-bit), DMARC (p=quarantine default)
• MTA-STS policy + TLS-RPT reporting
• BIMI ready (you supply the SVG and VMC)
• Reverse-DNS aligned to your domain on every IP
• FBL (feedback loops) registered with Microsoft, Yahoo, AOL

Security & tenancy

Single-tenant by design. Other customers can’t reach your data and can’t reach your IPs.

• Per-workspace container isolation (no shared postfix instance)
• API tokens scoped to a workspace + role; rotate at any time
• Encryption at rest (LUKS) + in transit (TLS 1.2+)

Status

Live operational state at /status. We aim for high availability and post incident timelines there, but we do not currently publish a contractual service-level agreement supported by financial credits — see the terms of use for the authoritative position. A paid-tier SLA with credits will land before we lift the early-access gate.

Authentication

All API requests authenticate with a workspace-scoped bearer token. Generate from Settings → API keys in the dashboard.

curl https://adbtd.com/api/v1/mailboxes \
  -H "Authorization: Bearer adbtd_live_4f8c…"

Tokens come in two flavors with the same surface and permissions: adbtd_live_ for keys you mint from the dashboard, and adbtd_mcp_ for keys auto-issued via the OAuth flow at mcp.adbtd.com.

Errors & rate limits

The API uses conventional HTTP status codes. Errors are returned as JSON with code and message:

{
  "error": {
    "code": "conflict",
    "message": "no dedicated IP on this workspace yet — place your first order via the dashboard"
  }
}

Rate limits run as token-bucket per API key, scoped per endpoint group: 60/min for general reads & writes, 30/min for IMAP fetches, and 30/min (burst 10) for outbound sends. 429 responses carry Retry-After (seconds).

Pricing model

Two line items, billed monthly:

• $1.99 / mailbox / month
• $19 / dedicated IP / month (minimum 1 per workspace)

Currency is locked at first checkout. Choose USD, EUR, or GBP. Same number, different symbol.

Invoicing & refunds

Invoices issued on the workspace’s billing day each month. Cancellation prorates: cancel mid-cycle and we refund the unused days. Cancel an entire workspace and we keep the data (read-only) for 30 days before deletion.

Glossary

Plain-language definitions for the email-infrastructure terms used elsewhere in these docs. Each entry is self-contained so it can be cited in isolation.

What is a dedicated sending IP?

A dedicated sending IP is an IPv4 address that one — and only one — sender uses to relay outbound email. The opposite is a shared sending pool, where dozens or thousands of unrelated tenants on the same email service provider take turns transmitting through the same address. Because mailbox providers (Gmail, Outlook, Yahoo, corporate anti-spam) score reputation per IP, a dedicated IP isolates the sender from every other customer’s mistakes: a sloppy campaign on the next desk can no longer poison the reputation that decides whether your messages land in the inbox or the spam folder. Dedicated IPs are most useful past roughly 50,000 messages per month — below that, providers have too little volume to learn a per-IP reputation, and a shared pool with a healthy baseline reputation usually delivers better.

What is email whitelabeling?

Email whitelabeling — sometimes called whitemarking — is the practice of configuring outbound mail so that every header a recipient’s mail server inspects points to the sender’s own domain rather than to the email service provider behind it. Concretely, the SPF authentication record, the DKIM signing domain, the envelope return-path, the bounce-handling hostname, and (for inbound replies) the MX records all resolve under the customer’s own domain. Done correctly, a Gmail recipient opening the message’s technical headers sees only the sender’s domain authenticated, with no “via mailgun.org” or “sent through resend” line appended. Whitelabeling matters for agencies sending on behalf of clients, white-label SaaS reselling email features, and any operator who wants reputation attributed to their brand rather than to the underlying infrastructure provider.

What is IP warming?

IP warming is the deliberate, gradual ramp of outbound email volume on a freshly allocated dedicated IP so that mailbox providers can build a reputation profile for the address before it starts sending production traffic. A fresh IP has no history, and the major receivers (Gmail, Outlook, Yahoo) treat unknown-but-suddenly-noisy senders as statistically indistinguishable from spammers cycling through cheap IPs. A standard warmup schedule starts at roughly 10 messages per mailbox per day, doubles every few days, and reaches typical operating volume after two to three weeks. The mail sent during warmup should go to engaged recipients — opens and replies build positive signal; bounces and spam complaints poison the IP before its reputation has stabilised. Without warming, even a technically perfect SPF / DKIM / DMARC configuration will deliver to spam for the first several weeks.

What is a feedback loop (FBL)?

A feedback loop, or FBL, is a programmatic channel set up between a mailbox provider (Microsoft, Yahoo, Comcast, AOL, and so on) and a sender, through which the provider forwards a copy of every message that one of its users marks as spam. The sender ingests these reports, parses the original Message-ID and recipient address, and suppresses the complaining recipient from future sends — both to remove the immediate irritation and to prevent the rising complaint-rate from triggering an inbox-provider block. FBLs are provider-specific: each one requires a separate enrolment, usually tied to a specific authenticated DKIM domain or IP. Gmail famously does not offer a true FBL — instead, it surfaces aggregate complaint rates through Postmaster Tools, which sophisticated senders monitor as a leading indicator of inbox placement problems.