Campaign sending for people who own the domain
Bring your own relay, or send through ours. You buy the postage, so the sending reputation is yours. Everything that would quietly ruin it is refused before the send leaves, and told to you in a sentence you can act on.
Sign-ups are unavailable just now.
Postage is the cheap part, and we do not sell it anyway -- the relay you connect prices that, in fractions of a penny a message, and bills you for it directly. What this is for is that six months from now the domain you have spent years building is still one that inboxes let through. That is why the product is allowed to be inconvenient in exactly the places where convenience costs reputation.
Paste your own relay credentials, or use the sending infrastructure that comes with the account. Credentials are encrypted at rest, masked on every read path, and never returned by the API -- not even truncated. The account you build the reputation on is your account, and it leaves with you.
Every major transactional relay, plus any host that speaks SMTP.
A new IP has no reputation, and a sudden fifty-thousand-message day from an address nobody has seen looks exactly like what it looks like. While a connector is warming up, its effective daily limit is the smaller of its own quota and the ramp: 50 messages on day one, roughly doubling each week, 100,000 by day 28.
The ramp counts calendar days since the first send, not days you happened to send on. A fortnight of silence cools the IP off again, because that is a reputation signal too.
An empty audience, no from-address at all, an empty subject, a template that fails to render, a merge tag nobody filled in that would go out as a literal: each one stops the send rather than warning about it. A stale-looking list, a from-domain the relay is not configured to sign, a message with no visible unsubscribe link: each warns loudly and does not block, because those are your call to make.
Every finding carries one line saying what to do about it.
SPF, DKIM, DMARC and reverse DNS each show a tick only once the app has looked them up and agreed. You will be told that your SPF ends in +all and authorises the whole internet, that it needs about eleven DNS lookups when the limit is ten, that there are two records where there must be exactly one, or that it does not authorise the relay you are about to send through.
"Unknown" looks different from "failed". We have not looked yet is not the same claim as we looked and it is wrong.
A flag that was flipped cannot answer "when did they opt out, and from what". So it is not a flag.
Each consent record holds the contact, the consent group, the state, when it changed, the source, which sending identity they were reacting to, which send it came from, and the IP and user agent. The history is auditable because one day you may have to evidence it.
Opt-in and opt-out are declared per consent group, not as one global setting that silently relabels every existing record the day it changes.
A consent group is a set of sending identities people opt in and out of together. Somebody who unsubscribes from one newsletter did not mean "please keep mailing me from the other three addresses on the same domain". Other groups are untouched, because they genuinely are a different conversation.
RFC 8058 List-Unsubscribe and List-Unsubscribe-Post headers go on every message, not only when somebody remembers to tick a box. Without them, unsubscribe requests arrive as spam complaints instead -- worse for you and worse for the recipient.
Deliverability state moves one way: active, soft bounced, unsubscribed, complained, hard bounced. A nightly CRM pull may raise a contact's state and may never lower it, so a Salesforce lead whose "Email Opt Out" is false does not resurrect last week's hard bounce.
Loosening one is an explicit, audited act taken by a person, with a reason.
We are the processor. Your contacts, your consent records and your templates are yours, and several decisions that would otherwise look odd follow from that.
Every list page has an Export CSV button that downloads what it is showing -- the rows on screen, in the columns that list shows -- with no ceremony and nobody to ask. A whole-account extract is not a button yet; that one is a ticket, answered by a person, and we would rather say so than let a button imply it.
It does not lock the account. The data is yours, and a customer who cannot log in cannot pay. Non-payment is a billing problem, not grounds for holding records hostage.
Relay credentials are encrypted at rest and masked on every read path. Anything we only need to check rather than replay -- a password, a webhook signature -- is hashed instead, so we could not replay it if we wanted to.
For developers
The schema is the application: the database, the REST API, the OpenAPI document and every page of the UI come from one set of entity definitions. The practical consequence is that there are no endpoints that exist for one object and not another -- list, filter, search, sort, paginate, create, read, update and delete work the same way on contacts as they do on templates, sends and suppressions.
Read the API referenceGET /api/v1/contacts?email_status=active&sort=-created_at&limit=50
X-API-Key: ...
{
"items": [ ... ],
"total": 1842,
"limit": 50,
"offset": 0,
"has_more": true
}A feature that makes bad sending easier is not one we are behind on. It is one we declined.
Sign-ups are unavailable just now. The plans below are what an account includes when sign-ups reopen.