Bird

View saved version →

---
name: bird-cli
description: Use when operating Bird through the bird CLI to preview or send messages, inspect or manage API resources, register or inspect Inbox Insights seed tests, or onboard an account; excludes client development.
---

# Bird CLI

`bird` is a single binary for the Bird API and local tools such as WhatsApp message previews. Account operations need credentials; local previews do not.

This skill requires the `bird` CLI. If `command -v bird` finds nothing, install it with `brew install messagebird/tap/bird`, or follow the [CLI installation instructions](https://bird.com/docs/cli#install) for other platforms.

## The path

**Step 0 — Authenticate for account operations.** For a WhatsApp preview, go directly to [Preview](references/whatsapp.md#preview); for public documentation questions, use [docs](references/docs.md). For account operations, confirm credentials first: [authenticate](references/authenticate.md). It is a no-op when `bird auth status` already reports `valid: true`. No account yet? Create one through [onboarding](references/onboarding.md); it ends by storing the same credential a login would.

**Step 1 — Run the operation the user asked for:**

- Send or inspect email messages (`bird email`, including `send-batch`) → [email](references/email.md)
- Author reusable email templates, submit a draft, or roll one back (`bird email templates`) → [email-templates](references/email-templates.md)
- Prepare, send, or inspect a marketing broadcast (`bird email broadcasts`) → [email-broadcasts](references/email-broadcasts.md)
- Send or inspect SMS messages, or browse SMS templates (`bird sms`) → [sms](references/sms.md)
- Draft the carrier verification a US toll-free number needs before it can send, read what the carrier asks for, or see why one was declined (`bird sms tfn verifications`) → [tfn-verifications](references/tfn-verifications.md)
- Claim an alphanumeric SMS sender, find out what a country requires of it, or register it for a country (`bird sms senders`) → [sms-senders](references/sms-senders.md)
- Reply to Apple Messages conversations or manage businesses and statistics (`bird amb`) → [Apple Messages](references/amb.md)
- Preview a WhatsApp message (`bird whatsapp preview`) → [Preview](references/whatsapp.md#preview) (local — skips Step 0)
- Send or inspect WhatsApp messages, receipts, reactions, senders, suppressions, keyword rules or statistics (`bird whatsapp`) → [WhatsApp operations](references/whatsapp.md)
- Browse WhatsApp templates, their versions, and each version's per-language content (`bird whatsapp templates`) → [whatsapp-templates](references/whatsapp-templates.md)
- Create and administer WhatsApp groups, hand out or rotate an invite link, decide join requests, pin messages, or remove a participant (`bird whatsapp groups`) → [whatsapp-groups](references/whatsapp-groups.md)
- Set up the WhatsApp Business Agent on a number — onboard it, give it FAQs, websites, files and skills, test it, then turn it on (`bird whatsapp agents`) → [whatsapp-agents](references/whatsapp-agents.md)
- Inspect voice calls, find out why one was refused, configure a SIP trunk or an inbound number, register or verify an outbound caller ID, enable or disable calling to a country, or place a test call (`bird voice`) → [voice](references/voice.md)
- Buy an eSIM, add data, deliver installation details, or manage recurring packages (`bird esim`) → [eSIM](references/esim.md)
- Provision Realtime apps and rotate the keys their clients connect with (`bird realtime`) → [realtime](references/realtime.md)
- Verify a recipient with a one-time passcode — send a code, then check what they submit (`bird verify verifications`) → [verify](references/verify.md)
- Find out about a recipient before you use it — grade an email address, or identify a phone number and its network (`bird lookup`) → [lookup](references/lookup.md)
- Manage contacts, audiences, and contact properties (`bird contacts`, `bird audiences`, `bird contact-properties`) → [contacts](references/contacts.md)
- Record and look up messaging consent grants and opt-outs (`bird preferences`) → [preferences](references/preferences.md)
- Manage sending domains (`bird email domains`), or find a verified `from` to send from → [domains](references/domains.md)
- Count how much mail the workspace received, by period, day or hour (`bird email stats inbound`) → [received-mail-stats](references/received-mail-stats.md)
- Inspect owned-domain placement and authentication, or configure, register and read seed tests (`bird email inbox-insights`) → [inbox-insights](references/inbox-insights.md)
- Inspect competitive email intelligence (`bird email competitive`) → [competitive](references/competitive.md)
- Style the hosted page a marketing recipient lands on when they unsubscribe (`bird email unsubscribe-page`) → [unsubscribe-page](references/unsubscribe-page.md)
- Manage dedicated IPs (`bird email dedicated-ips`) and IP pools (`bird email ip-pools`) (sending reputation) → [ip-pools](references/ip-pools.md)
- Receive email at inbound forward addresses (`bird email inbound-addresses`), or read the mail received there (`bird email inbound-messages`) → [inbound](references/inbound.md)
- Manage outbound webhook endpoints, or send events to Zapier, Make, n8n or your own endpoint and prove one arrives → [webhooks](references/webhooks.md)
- Issue or rotate a workspace API key (`bird api-keys create`, `bird api-keys rotate`) → [api-keys](references/api-keys.md) (needs a login carrying `api_keys:write`; an API key cannot run it)
- Find out why acquiring a number or registering a sender was refused for a reason about the organization rather than the country, and settle the requirement behind it (`bird trust`) → [trust](references/trust.md)
- Find the business a 10DLC brand is registered for, so `brands create` can name it (`bird compliance identities list`) → [compliance-identities](references/compliance-identities.md)
- Register a 10DLC brand for US A2P traffic, or file a submission against one (`bird sms 10dlc brands create`, `bird sms 10dlc brands submissions create`) → sibling operations; node not yet authored, `--help` on each carries the field list
- Open a support ticket, reply to it, or wait for a support agent reply → [support](references/support.md)
- Answer a how-to or reference question about Bird from the documentation → [docs](references/docs.md) (public — skips Step 0)
- Inspect resolved CLI configuration → `bird config show` (sibling operation; node not yet authored)

Pick the operation that matches the request. Complete Step 0 only for operations that require an account.

## Conventions every command shares

These hold across operations, so the nodes rely on them instead of repeating them:

- **Output is JSON by default** (`--format json`). Single-record commands (`get`, `status`, `show`) also take `--format text` for a human-readable card. List commands ignore `--format text` and always emit JSON, so a script can pipe them through `jq` without a per-command branch.
- **Exit codes carry the failure category** so a caller can branch without parsing prose: `2` invalid usage or input, `3` not found, `4` auth or permission denied, `5` conflict, `6` transient (rate limit or server error, retry after `retry_after`), `7` a check ran and found a problem (`check_failed`), `1` anything else. Errors print to stderr; data to stdout.
- **Every error explains itself.** The envelope always carries a readable `message`, and most errors carry a stable `code`. An error from the Bird API also carries a `doc_url` to that code's page, which says what went wrong and what to do; every code is listed at https://bird.com/docs/api/errors. Read `details`, when present, for each failing field.
- **Transient failures are retried for you.** A rate limit, a 5xx, or a network blip is retried twice with backoff before the command fails, so an error marked `retryable` has already been through that — re-running it immediately rarely helps. `--max-retries 0` turns it off when you drive your own retry loop.
- **Retry progress goes to stderr.** The CLI reports the retry reason and remaining wait there; JSON result data stays on stdout.
- **The login sets the region.** The token from `bird auth login` is bound to one workspace and its region, which picks the API host; override with `--base-url`/`BIRD_API_URL`. Details and the state check live in [authenticate](references/authenticate.md).

Referenced files: 73

View saved version →

---
name: email-audit
description: Use when auditing a live domain's email authentication or spam-delivery problems involving DMARC, SPF, DKIM, BIMI, or MX; single-record drafts use bird validators.
---

# Email authentication audit

`bird email tools audit <domain>` resolves a domain's live email-authentication records — DMARC, SPF, DKIM, BIMI, MX — validates each, checks how they work _together_, and returns a graded report. Your job with this skill is to run it and then act as the consultant: read the findings, explain what each means in plain terms, and give the user a prioritized plan.

It is DNS-only and needs no auth. It sends no mail and inspects no message; it reads what the domain publishes.

```
bird email tools audit acme.com
bird email tools audit acme.com --selector s1   # also check a DKIM selector (see DKIM below)
```

MCP: `email_tools_audit` with `{ "domain": "acme.com", "selector": "s1" }`.

## When to use this vs the per-record validators

- **`audit <domain>`** — "how is _my domain_ set up?" Resolves live records and grades the whole posture. This is the one to reach for when someone describes a _symptom_ ("going to spam", "failing DMARC", "can people spoof us?").
- **`validate-dmarc` / `validate-bimi <record>`** — "is _this record I wrote_ correct?" Offline, parses a pasted string. Use when drafting a record before publishing, not when diagnosing a live domain.

If they give you a domain, audit it. If they paste a record, validate it.

## Reading the report

```jsonc
{
  "domain": "acme.com",
  "valid": false,                      // true only when there are NO problem-severity findings
  "records": [                         // what was found, per area
    { "area": "dmarc", "found": true,  "value": "v=DMARC1; p=none; rua=..." },
    { "area": "spf",   "found": true,  "value": "v=spf1 include:... ~all" },
    { "area": "dkim",  "found": false, "value": null },
    ...
  ],
  "findings": [                        // graded observations, most-severe first
    { "severity": "problem", "area": "spf", "message": "...", "fix": "..." },
    { "severity": "warning", "area": "dmarc", "message": "...", "fix": "..." }
  ],
  "recommendations": [ "...", "..." ]  // the fixes, problems first — the action list
}
```

Three severities, and what each means for the user:

- **`problem`** — delivery or spoofing protection is actually broken right now. Lead with these. (`valid` is `false` whenever any exist.)
- **`warning`** — works, but is weak, incomplete, or risky. Address after the problems.
- **`ok`** — a passing check. Use these to reassure ("DMARC is enforcing, good") so the report isn't only negatives.

The fastest way to advise: read `findings` top-to-bottom (already severity-ordered), then hand back `recommendations` as the to-do list. Don't just dump the JSON — translate it.

## What each area means and how to fix it

**DMARC** (`_dmarc.<domain>`) — the policy that ties SPF and DKIM together and tells receivers what to do with mail that fails. The journey is `p=none` → `p=quarantine` → `p=reject`:

- `p=none` is **monitor-only**: you get reports but spoofed mail still lands. It's the right _first_ step, never the destination. Recommend moving to `quarantine` then `reject` once legitimate mail is passing aligned (see Alignment).
- No record at all is a `problem` — the domain is spoofable and you're blind to abuse. Start at `p=none` with a `rua=` address to collect reports.
- No `rua=` means no visibility — add a reporting address before tightening the policy.
- An invalid record is treated by receivers as no record; fix it (validate-dmarc) before anything else.

**SPF** (`<domain>` TXT, `v=spf1 …`) — the list of servers allowed to send for the domain. Two things bite people:

- **The 10-lookup limit (RFC 7208).** Every `include:`, `redirect=`, `a`, `mx`, `ptr`, `exists` costs a DNS lookup, and `include:` chains recurse. Over 10 total, SPF returns _permerror_ and fails for **all** mail, including legitimate. The audit counts recursively — this is its main value over eyeballing the record. The fix is to flatten or drop includes (remove unused providers, or use a sender that auto-flattens).
- **The `all` qualifier.** `-all` (hard fail) is the goal; `~all` (soft fail) is fine while verifying; `?all` (neutral) and especially `+all` give no protection — `+all` lets anyone send as the domain. Move toward `-all` once every legitimate sender is listed.
- Multiple SPF records is a `problem` (permerror) — merge into one.

**DKIM** (`<selector>._domainkey.<domain>`) — a cryptographic signature on each message; the more durable half of DMARC because, unlike SPF, it **survives forwarding**. The catch: **selectors can't be discovered from DNS.** The audit can only check DKIM if you pass `--selector`. So:

- If DKIM shows as "selector unknown" — that's not a failure, it just wasn't checked. Ask the user for their selector (their sending provider's DKIM setup shows it) and re-run with `--selector <s>`.
- No key at the given selector is a `problem` for mail signed with it — publish the provider's public key, or correct the selector.

**BIMI** (`default._bimi.<domain>`) — optional; shows the brand's logo in supporting inboxes. It only displays once **DMARC is at enforcement** and (for Gmail/Apple Mail) a **Verified Mark Certificate** (`a=`) is published. Absence is not a problem — it's a "nice to have, and only after the basics." Don't recommend BIMI until DMARC is enforcing.

**MX** (`<domain>` MX) — where the domain _receives_ mail. No MX is only a `warning`: it's fine and common for a send-only domain, but worth confirming it's intentional.

## The cross-record insight (the thing a flat checker misses)

DMARC passes only when SPF **or** DKIM passes _and is aligned_ with the From: domain. So the audit's most important synthesized finding is: **is DMARC enforcing while neither SPF nor DKIM can produce an aligned pass?** If so, the domain's own legitimate mail is being quarantined or rejected — the most damaging misconfiguration, and the one to fix first. Conversely, you can't safely advance DMARC past `p=none` until at least one of SPF/DKIM aligns. When you advise on sequencing, this is the spine: **get one of SPF/DKIM aligned → raise DMARC to quarantine → reject → (optionally) BIMI.**

## Honest limits — say these out loud

- **DKIM needs a selector** (not DNS-enumerable). An unchecked DKIM is "unknown", not "absent" — don't report it as missing.
- **DNS records only.** No SMTP probing, no test send, no message/header inspection. (To analyze a specific message's headers, that's `bird email tools analyze-headers`; to read a DMARC aggregate report, `analyze-dmarc-report`.)
- **It reflects this moment's DNS.** Results are briefly cached; a record you just changed may take time to propagate.

## How to deliver the result

Be the consultant, not a linter:

1. One-line verdict — is the domain protected, monitoring, or exposed.
2. The problems, each in plain language with the concrete fix from `recommendations`.
3. The sequencing — what to do first (almost always: fix alignment, then advance DMARC).
4. The reassuring `ok` findings so they know what's already right.
5. If DKIM was unknown, ask for the selector and offer to re-run.