You run twelve to forty client domains at any moment. Some you bought on their behalf, some they handed you the registrar login for, and a few you inherited with nobody left who remembers the setup.
What breaks todayClient work starts with a domain and ends with a handover, and mail is awkward at both ends. Buying a seat per client turns a $6 line item into a margin conversation, so most agencies default to forwarding hello@client.com into someone's personal inbox — which works right up until someone has to reply, and the answer arrives from becky@youragency.com.
The version that really hurts is the shared login: one free forwarding account whose password is in a pinned Slack message, still working four staff departures later.
The setupOnboard each client domain as a Microsoft shared mailbox or a Google Group inbox — free either way. Add the account manager as a manager of the Group (or grant Full Access on the Microsoft side) and they get the mail plus the ability to reply as the client's address.
Handover becomes a two-minute job: remove your staff's access, hand the client the domain, and the mailbox goes with it. Nothing to migrate, no password to rotate.
Every client gets a real inbox on their own domain, and offboarding is a permission change rather than a migration.
You have four things live and eleven domains registered. Two make money, one might, and the rest are ideas with a landing page and a Stripe key.
What breaks todayA product needs working email before it has revenue: a support address people can reach, and transactional mail that reaches them. Gmail's free forwarding gets the first half and quietly wrecks the second — send a receipt through a personal account and you inherit its sending limits, its reputation and its From address.
So the receipts go out through whatever the framework does by default, land in spam, and you find out three weeks later from a churned customer.
The setupAdd each product domain as a Google Group inbox (or shared mailbox) for support@, which costs nothing per product. In the same pass, inboxroot creates the domain's Postmark sender signature and its DKIM and Return-Path records, so transactional mail is properly signed from the first send.
A domain that dies gets deleted; one that takes off already has an inbox, DKIM, and a broadcast stream ready for the launch email.
Launch-quality email on an idea that hasn't earned anything, without a per-product bill.
A portfolio between fifty and several hundred names, mostly parked, each with a for-sale page and an enquiry form nobody trusts.
What breaks todayAn enquiry on a five-figure domain arrives once a quarter and is worth answering within the hour. Registrar catch-alls dump every one of them into a single unread pile alongside the renewal notices, and a reply from me@gmail.com about kibipay.com reads exactly like the scam the buyer was worried about.
Worse, a parked domain with no SPF or DKIM is a free ride for anyone spoofing it — and the reputation damage lands on the asset you're trying to sell.
The setupGive the names you're actively selling a real Group inbox or shared mailbox, so enquiries arrive attributed to the domain and you reply as it. For the long tail, use send-only mode: two records, no MX change, a signed sending identity and an SPF policy that tells receivers nobody else may send as it.
The console's merged inbox is the point here — one list across the whole portfolio, with each message labelled by the domain it arrived at.
Enquiries land attributed and get answered as the domain, and parked names stop being free to spoof.
One legal entity, three to eight customer-facing brands. Separate sites, separate audiences, sometimes deliberately no visible link between them.
What breaks todayThe brand boundary is the product of a lot of deliberate work, and email is where it leaks. Aliases pointing at one mailbox mean a reply goes out from the parent company, or from whichever brand your client happens to default to.
Then someone sends a campaign for the newest brand, complaints tick up, and the shared sending reputation drags down transactional mail for all of them.
The setupOne inbox per brand, on the brand's own domain — free on either host. Each gets its own DKIM key, and inboxroot can pin a brand to its own Postmark server so its sending reputation is genuinely separate rather than nominally so.
Staff keep one login. The mailboxes appear alongside their own, and the From selector picks the right identity.
Each brand answers as itself, and one brand's bad week can't touch another's deliverability.
You work with three or four organisations at once. Two gave you an account on their tenant; the others want you reachable at their domain without an onboarding ticket.
What breaks todayBeing reachable at the client's domain matters more than it should — it decides whether your mail to their suppliers gets answered. But asking for a seat means IT involvement, a licence cost, and a fresh mailbox to check separately from your own.
The alternative, forwarding into your own address, gives you the inbound half and leaves you replying from a domain the recipient has never heard of.
The setupIf you administer the domain, a Group inbox or shared mailbox with you as the only member costs nothing and appears in your existing client. If you don't administer it, the client adds you to the one you provision for them.
When the engagement ends, your access is revoked and the address keeps working for whoever takes over.
You answer from the client's domain in your own inbox, and leaving doesn't break the address.
Several storefronts, some seasonal, each with its own domain and its own stream of order confirmations, shipping notices and returns.
What breaks todayStore mail is the highest-stakes transactional mail there is — a confirmation that lands in spam becomes a support ticket, a chargeback, or a lost customer. Running it out of a platform's shared sending domain means your deliverability is the average of everyone else's on that platform.
Meanwhile returns@ needs a human, and standing up a mailbox for a store you might close in March is hard to justify.
The setupEach store domain gets a free inbox for orders@ or returns@ and its own Postmark sender signature with a DKIM key nobody else shares. Aliases are free and instant, so a seasonal blackfriday@ costs nothing and needs no DNS.
The sent-mail view searches across every store and every Postmark server at once, which is how you answer “did that confirmation actually go out?” in one query.
Order mail signed by your own domain, and a store you close costs nothing to have run properly.
One domain, a rotating set of volunteers, and addresses like treasurer@, membership@ and safeguarding@ that need to outlive whoever currently holds the role.
What breaks todayRole email run from personal accounts is a governance problem in waiting. When the treasurer steps down, two years of correspondence leaves with them, and the handover is a forwarded folder if you're lucky.
Paid seats for volunteers are rarely affordable, so groups end up on free forwarding with shared credentials — which fails an audit and fails safeguarding.
The setupEach role becomes a Group inbox or shared mailbox: free, owned by the organisation, and with history that stays put. Handover is adding the new holder and removing the old one — the archive never moves.
The audit trail records who was granted what and when, which is exactly what a trustee report needs.
Role addresses belong to the organisation, and a handover is a permission change with no lost history.
You run mail for one large tenant with many acquired domains, or for a book of small clients whose setups you inherited in whatever state they were left in.
What breaks todayDomain onboarding is a runbook that never survives contact with a Friday afternoon. Ten steps across two consoles and a registrar, and the failure mode is silence: a missing DKIM record, an SPF line with two v=spf1 entries, a Send As grant that landed on the wrong identity.
Six months later something bounces and nobody can say what the intended configuration was, let alone what changed.
The setupOne flow per domain, in a fixed order, with each step verified against the provider rather than assumed. Permissions are read back after they're granted — that is how you catch a Full Access grant that silently didn't stick.
Every action is written to a per-tenant audit log, and the DNS view keeps showing the intended record set alongside what public DNS actually returns.
The runbook executes itself, verifies its own work, and leaves a record of what it did.