Deliverability · Email
This page maps the shared deliverability model onto email: which records prove your identity, how dedicated IPs isolate your reputation, and where to watch for trouble. Each section links to the page that covers the mechanics in full — go there for the record shapes, API payloads, and edge cases.
Prove your identity: domain authentication
Email authentication on Bird is per organization, even on a shared domain: Bird generates a DKIM signing key for your organization and publishes its public half under a selector unique to you, so your authentication proof is yours alone no matter who else sends from the same domain. Alongside DKIM, you publish a return-path (envelope-from) CNAME that routes bounces through Bird and gives you SPF alignment without touching your apex, and a DMARC record that states your policy for mail failing those checks.
The send gate is DKIM + return-path + DMARC. A domain sends only once all three verify. The fourth record — the tracking CNAME for branded open and click tracking — is separate and optional: it gates branded tracking, never sending.
- Sending domains — adding a domain and the verification lifecycle
- DKIM, SPF & DMARC — what each record proves, exact shapes, and why apex SPF is not required
- Knowledge base: DNS setup at your registrar — step-by-step instructions per DNS provider
Isolate your reputation: dedicated IPs and pools
By default your mail rides the Shared Bird.com Pool — Bird's shared sending infrastructure, present in every organization's pool list as a protected pool, and your default until you explicitly flip it. Dedicated IPs are the opt-in alternative: addresses only your organization sends from, organized into organization-scoped pools that every workspace can use.
Two rules keep a cold IP from hurting you:
- New IPs warm automatically over roughly 30 days. Each purchased IP starts in warming status with a warmup_progress of 0–100; while it ramps, traffic beyond what it can safely carry overflows through the shared pool, so your volume never drops.
- Your default pool can never be backed only by still-warming IPs. A dedicated pool needs at least one active IP before it can become the default — Bird never routes your unspecified traffic onto infrastructure that cannot carry it.
Per send, choose a pool with the optional ip_pool field on the send request; omit it to use your default.
- Dedicated IPs & pools — purchasing, pool management, default-pool rules, and ip_pool routing
- IP warmup — the warmup schedule, monitoring warmup_progress, and when to flip your default
Watch your reputation: bounces, complaints, suppressions
Your reputation signal arrives as events: bounce and complaint events tell you which addresses are failing and who is reporting you, and Bird's suppression list automatically stops repeat sends to hard bounces, complainers, and unsubscribes before they leave the platform. Aggregate delivery, open, and click rates are on the Metrics page in the dashboard — a falling delivery rate or rising complaint rate is your earliest warning.
Two adjacent things to know: BIMI (your logo in supporting inboxes) is a DNS standard you publish yourself — there is no BIMI API in v1 — and there is no blocklist-status API in v1 either.
- Suppressions — what lands on the list automatically and how to manage it
- Tracking & metrics — open/click instrumentation and the aggregate view