Workflow & focus
One Inbox for Multiple Domains: Who Are You When You Reply?
Someone writes to support@yourstudio.com. The same person — you — also answers as you@yourband.net and hello@that-side-project.com. The real question a unified inbox solves is not where the mail lands. It is which of those people you are when you hit reply, and whether your software gets that right without you thinking about it.
Plenty of "one inbox for multiple domains" advice stops at reading: pour everything into one place and feel calmer. That is the easy half, and forwarding already does it. The half that decides whether consolidation actually works is identity — and identity turns out to be a concrete, technical thing you can point at in the message itself.
Two kinds of consolidation, and only one that counts
Collapsing several inboxes into one combines two jobs that people treat as the same. They are not.
Consolidating where mail lands is just routing. Forward every domain into one place and your reading is unified. But the instant you answer, the mask slips: the reply leaves from your personal address, not the brand it came to, and the recipient sees a stranger.
Consolidating who you are means the inbox can also answer as any domain — and, better, answers as the right one on its own. That is the half forwarding cannot do and aliases only half-do, because the provider caps how many identities you may bolt on and has been shrinking that allowance for custom domains.
Forwarding consolidates where mail lands. A true unified inbox consolidates who you are when you answer. Only the second one actually ends the juggling.
The address it was for survives — here is where
The fear is that one inbox becomes a swamp where every brand blurs together. It does not, and the reason is specific: the address a message was delivered to is preserved in the message, whatever the visible "To" line says. That single fact is the hinge the whole system turns on, so it is worth seeing the actual headers.
WHAT ACTUALLY ARRIVES — the headers that remember who it was for
==================================================================
Mail sent to support@yourstudio.com carries more than the visible
"To". The address it was DELIVERED to is preserved in the SMTP
envelope and stamped into headers you can filter on:
Return-Path: <sender@wherever.com>
Received: from mx.wherever.com by mail.yourstudio.com
for <support@yourstudio.com>; <- envelope recipient
Delivered-To: support@yourstudio.com <- what it was FOR
X-Original-To: support@yourstudio.com <- same, pre-rewrite
To: "Studio" <hello@yourstudio.com> <- cosmetic; can differ
Subject: Can you take a commission?
The visible To: can say anything — a mailing list, a different
alias, or nothing at all on a blind-carbon (BCC). The ENVELOPE
recipient (the SMTP "RCPT TO"), captured as Delivered-To /
X-Original-To and the "for" clause of Received, is the ground truth
of which identity was addressed. Label and auto-reply on THAT.
==================================================================
This is the detail most guides assert and never show. The To: header is cosmetic — a sender can forge it, a list can rewrite it, a BCC omits you from it entirely — so sorting on it is unreliable. The envelope recipient is not cosmetic: it is the address the sending server literally handed over in the SMTP RCPT TO command, and your receiving server records it as Delivered-To, X-Original-To, or the for clause of the top Received: line. Even a catch-all message to whatever-typo@yourstudio.com preserves the real address it was sent to, because the envelope carried it. That is why a well-built catch-all does not lose context: the context was never in the To: line to begin with.
Filtering and replying on the real recipient
Once you know which header holds the truth, the inbox organizes itself by keying on it rather than on the visible To::
# Sieve: file by the REAL recipient, not the cosmetic To: if envelope :domain "to" "yourstudio.com" -> fileinto "Studio" # Gmail filter, in "Has the words": deliveredto:(*@yourstudio.com) -> label "Studio"
Both rules match the envelope address, so they hold up against forged To: lines and BCCs that a naive to: filter would miss. (The full recipe set — per-domain folders, catch-all quarantine, kill switches — lives in the management guide.) The same header drives the reply: a client that reads Delivered-To can default your From to that exact address, so support@yourstudio.com answers as support@yourstudio.com without you choosing it on every message. Identity stops being a thing you remember and becomes a thing the headers decide.
See it on your own mail
You do not have to take this on faith — every message you have already proves it. Open any mail and view its original source: in Gmail, the overflow menu offers Show original; in Apple Mail, View → Message → All Headers (or Raw Source); in most webmail, a "view source" or "show headers" option. Scroll to the Delivered-To line. On a message sent to a mailing list, or one you received as a BCC, you will often find that line naming your address while the visible To: names someone else entirely. That gap is the whole argument: the field your eye reads is not the field your rules should trust.
Why this is calmer, not just tidier
The payoff is attention, not aesthetics. Because the recipient address is visible before you open a message, you know which role you are in — client work, band, side project — a beat before you read a word. Because the reply identity is automatic, the small dread of "did I just answer a client from my personal address?" disappears. One window, as many clearly labeled lanes as you have brands, and no second place a message could be hiding. That is what makes "done" actually mean done.
Setting it up, honestly
With Blue Folder Mail the unified inbox runs on your own Cloudflare account: inbound mail for each domain routes through your account and is encrypted at rest with a key only you hold, so stored messages are ciphertext the host cannot read. The honest footnotes stay attached: a message arrives as plaintext at the receiving edge and is sealed once it lands, so there is a brief window before encryption; and outbound replies ride a sending provider, so that leg is not zero-access the way storage is. It is a strong model — no key to your inbox in anyone else's hands — not a claim of being unhackable.
- Won't one inbox for everything get overwhelming?
- Not if you sort by the address mail was sent to. One inbox with per-domain labels is far calmer than several separate inboxes, because you see everything in one glance and nothing hides in an app you forgot to open.
- Can I still reply as the correct brand?
- Yes, and that is the key difference from simple forwarding. A true unified inbox sends as any of your domains and can default each reply to the address the message arrived on, so the right brand always answers.
- Is this just forwarding with extra steps?
- No. Forwarding only consolidates incoming mail and leaves your replies coming from the wrong place. A unified inbox receives and sends for every domain natively, so your identity is consolidated too.
- Who hosts and can read the consolidated mail?
- In a self-hosted, zero-access design, it runs on your own account and is encrypted at rest with a key only you hold. The host stores ciphertext it cannot read. No system is magic, but you are not handing the keys to a third party.