Newsletter infrastructure
that holds at scale

Your own. Carrier Crow is not an email service provider — you connect an SMTP account you already have, and every message goes out through it. Host, port, username, password, SSL/TLS: standard SMTP, so SendGrid, Mailgun, Postmark, Amazon SES, Google Workspace and self-hosted relays all work the same way. You can hold several send configurations and point different projects at different ones.

Because deliverability is a relationship between your domain and the mailbox providers, and it should not be hostage to a marketing tool. Bringing your own SMTP means your sending reputation is yours, your provider’s rates are whatever you negotiated, and switching tools never means warming up a new IP.

Any that can use a remote MCP server. Carrier Crow speaks the standard Model Context Protocol over HTTPS: clients that support OAuth sign in with your Carrier Crow account (it handles dynamic client registration, so there is nothing to set up first), and clients that prefer a header can use an API key from your settings instead.

No. Through the MCP server, an assistant can look up subscribers and saved segments, import subscribers, write and edit templates, and create campaigns — and every campaign it creates is a draft. None of the fifteen tools can send, schedule or resume a campaign; that stays a click in the app, by someone with permission to send.

Instead of a fixed interval, every message gets its own randomly drawn gap, sized so the whole list lands inside the window you set, with room to spare. You can bend the rate to a business-day curve. Start it outside the window and it waits, marked Scheduled, and takes its audience snapshot when the window opens rather than when you clicked.

Every open and click is scored for automation as it arrives. Scanners and self-declared bots are kept out of your rates by default; Apple Mail Privacy Protection opens are flagged, and can be excluded on a stricter per-project setting. Nothing is thrown away — the raw events are kept, so changing the rule recalculates your history instead of only what comes next.

Yes, through Twilio, switched on per project on request. Consent is tracked per channel: a STOP reply revokes it, START restores only what STOP removed, and a fresh signup can’t quietly undo a STOP. Sends past five thousand recipients ask you to confirm the estimated cost first.

Past a million. The template is prepared once per campaign and each recipient’s copy is produced by string substitution rather than a full re-render — that is what keeps a seven-figure send from crawling. Delivery is queued and workers scale out behind it, so the list size sets the duration, not whether it finishes.

Variant assignment is a deterministic function of the reader and the ad slot, so the same person sees the same creative on the original send, on a resend, and when the analytics side works out what they saw. Nothing is left to a coin flip that could disagree with itself later.

Only when that is a defensible thing to say. Below a floor of impressions per variant no rate is shown at all, and a winner is declared only when the difference clears a two-proportion significance test. Most of the time the honest answer is “keep running”, and the report says that instead.

They are not quietly added back. They get a page explaining they previously unsubscribed and have to confirm before anything changes. Consent that was withdrawn should have to be given again.

Yes. A list report exports as CSV, streamed row by row rather than assembled in memory, so exporting the whole list is a download rather than an outage. There is a REST and websocket API behind the same permissions as the app, and the MCP server reads the same data under the same rules.

You pick a monthly or annual plan and enter a card at signup — there is no free tier. What you pay your SMTP provider for the actual sending is separate, and stays between you and them.