Multi-Domain Sending & Sender Identities for Agencies

An agency running client campaigns from a single MailInApp account used to mean either one shared sending domain for everyone or a separate account per client. Multiple sending domains and named sender identities close that gap: verify each client's own domain once, define a sender identity per brand or per email type on top of it, and pick the right one per project, per schedule, or per contact list — no second account, no shared reputation.

Subject

Your spring collection is here

Verify more than one sending domain on a single MailInApp account and layer named sender identities on top of each, and one account can run campaigns as several distinct client brands — its own domain, its own from-addresses, its own tracking links, its own deliverability reputation — with no second account and no shared identity between clients.

An agency managing several clients from one MailInApp account used to have exactly one sending domain to work with, shared across every client's campaigns. Multiple sending domains and sender identities remove that ceiling: verify each client's own domain once, and everything downstream — from-address, reply-to, tracking links — can be scoped to that specific brand.

Verifying more than one domain

Settings' Sending domain card now lists every domain on the account, not just one — each verified (or in-progress) domain expands into its own detail panel with independent DNS records, verification status, from-address, and native-vs-SMTP toggle. Set default decides which domain a send falls back to when nothing more specific is configured; Disconnect removes one, refused only if an enabled recurring schedule still depends on it as its sole verified domain.

Sender identities: a name and address per brand or purpose

Once a domain is verified, a sender identity is a named {name, email, reply-to} scoped to it — [email protected] for receipts, [email protected] for newsletters, both verified by the same domain but showing recipients a different name and address. This is the same concept Brevo calls "Senders," and it's what makes multiple domains actually usable day to day instead of just theoretically possible.

Picking the right sender without choosing it every time

Four places resolve which identity — and therefore which domain — a send uses, checked in order: a schedule's own sender, a project's own sender, the audience list's default sender, and finally the account's default domain. Setting a contacts list's default sender once means every send to that client's list uses the right identity automatically, without picking it per campaign.

A recipient who hovers a link or forwards an email to a colleague sees the link's domain too. A custom tracking domain, available on Lite and above, points live-view, click, and open-tracking links at a subdomain of the client's own domain instead of mailinapp.com — one CNAME record, automatic TLS provisioning, no certificate files to manage. Every new send from that domain uses it automatically once verified; nothing already delivered changes.

What this doesn't change

Volume metering stays account-wide, not per-domain or per-client — a pricing-axis decision, not a technical limitation, so adding a client's domain doesn't itself change your monthly send cap. Each domain's own reputation, DKIM/SPF/DMARC, and bounce/complaint handling stay fully independent of every other domain on the account, so one client's deliverability issue never touches another's.

Getting started

Verify each client's domain from Settings, create the sender identities you need on top of it, and set the right default at the list, project, or schedule level depending on how much per-send control you want. See Multiple domains & sender identities and custom tracking domain for the full setup reference, and white-label agency workflows for the template and hand-off side of running multiple clients from one account.

A typical build-and-send sequence

  1. 1

    Verify each client's domain

    Add a sending domain per client from Settings — the domain list shows every verified or in-progress one, each with its own DNS records, verification status, and default badge, completely independent of the others.

  2. 2

    Define a sender identity per brand or purpose

    Once a domain is verified, create named sender identities scoped to it — orders@ for receipts, hello@ for newsletters — each showing a different name and reply-to while verified by the same underlying domain.

  3. 3

    Set the right default at the right level

    Pick a sender on the project itself, on a recurring schedule, or as a contacts list's own default sender — so a whole client's sends can use the right identity without picking it per send.

  4. 4

    Add a custom tracking domain for the client's own brand

    On Lite and above, point live-view, click, and open-tracking links at the client's own subdomain instead of mailinapp.com, so every link a recipient sees matches the brand they know.

Frequently asked questions

How many sending domains and sender identities can one account have?

Both are capped per plan and scale with tier — Free supports 1 domain and 1 sender identity, every paid tier raises both, up to unlimited on Business and Enterprise. See pricing for the exact numbers.

If I don't pick a sender for a specific send, what happens?

It falls back through a fixed order — a schedule's own sender first, then the project's, then the audience list's default sender, and finally the account's default sending domain — so an account that's never touched this feature keeps behaving exactly as it did with a single domain.

Does each client's domain need its own SES tenant or reputation setup?

Each verified domain gets its own DKIM/SPF/DMARC records and is authenticated independently — sending reputation is tracked per domain, so one client's bounce or complaint rate doesn't affect another's deliverability.

Can the Send API use a specific client's sender for a transactional call?

Yes — it accepts an explicit senderId the same way a manual send does, or an ad-hoc from address validated against any of the account's verified domains, not just the default one, for full per-call control.

What happens if I delete a sender identity a client's schedule still references?

Nothing breaks — deleting a sender identity is never blocked, and anything still referencing it just falls back to its domain's own default from-address automatically.

Build this in the studio

Start on the free plan — every interactive block and the full fallback engine are included on every tier.