Gmail aliases vs. true multi-domain email.

Gmail's Send as feature has been around since 2009. It lets one Gmail account present and reply from up to roughly thirty other addresses, making it the most common workaround for operators who have more than one identity but only want to pay for one inbox. It is, by far, the cheapest way to handle multi-identity email.

It is also not multi-identity email in any deep sense — and the places it diverges from what that phrase actually implies are precisely the places it breaks for portfolio operators. This is the detailed version of the comparison we publish on /compare/gmail-aliases, with more narrative and less table.

§ What Send as actually does.

Under the hood, Send as is a server-side substitution. When you compose a letter in Gmail and choose an alternate From address, Gmail either (a) sends the letter via Google's SMTP infrastructure with a modified From: header, or (b) routes it through an external SMTP server you've configured for that alias.

In mode (a) — the default — the envelope sender (what SPF checks) is still Google's infrastructure, but the visible From reads as your alias. This works in the sense that the letter arrives with the From you chose, but it has two problems:

• ·SPF authenticates the wrong domain. The recipient sees the letter came from gmail.com's infrastructure, but the visible From is yourdomain.com. These don't align. DMARC-strict recipients reject; the rest see the via line.
• ·DKIM signs with gmail.com's key. Same alignment problem — your domain is in the visible From, but the DKIM signature is over gmail.com, not yourdomain.com. DMARC alignment fails.

In mode (b) — external SMTP relay — you configure Send as with the credentials of a separate SMTP server, usually your own. This fixes the alignment problems because the letter is now actually being sent through a server authorised for your domain. But at that point, you're running (or renting) an SMTP server anyway, and the question becomes: why was Gmail the abstraction?

§ The reply-From fragility.

Gmail's Send as also has a feature where replies to mail that arrived at a configured alias are sent from that alias. When it works, this is what most operators want. When it doesn't work — which is often enough to matter — replies go out from your canonical Gmail address, and the recipient receives a letter from your personal Gmail account responding to a letter they'd sent to your business address.

The cases where it doesn't work, enumerated:

1. 01The original letter has a Reply-To: header that disagrees with the To: header (common with transactional mail and some CRMs). Gmail picks reply-from based on the To, and loses the alias.
2. 02The letter was forwarded from another mailbox (common if you're migrating addresses). The envelope-To is the forwarder, not your alias; Gmail doesn't recognise the alias pattern.
3. 03You replied to a thread initiated by you. The alias context is lost on outbound threads.
4. 04Gmail updated something. (This is half-joking. The heuristic changes meaningfully every 12-18 months.)

Each failure case is individually rare. In aggregate, over a year of running a consultancy on an alias, several replies will go out from the wrong From. Each one is an unforced error — a careful procurement email answered by what looks like a personal address.

§ Threading collapses when the From is wrong.

A reply that goes out with the wrong From breaks threading downstream. The recipient's client (Gmail, Outlook, Apple Mail) all use the From + Message-ID + References headers to decide whether an incoming letter belongs to an existing thread or starts a new one. When the From is the wrong one, the algorithm says: new thread.

The practical effect is that your counterpart sees two emails from you where there should have been a continuous exchange. They have to mentally stitch the conversation back together. Some percentage of the time, they don't — and the follow-up happens on the wrong thread, or not at all.

Threading is a UX feature built on authentication metadata. Break the authentication, lose the thread.

§ What 'multi-identity' actually means.

Contrast this with an inbox built around multi-identity as a first-class premise. Each identity is a bound domain — separate DKIM key, separate SPF authorisation, separate DMARC policy, separate reputation pool. The envelope-to of each incoming letter is recorded at ingest; the reply's From is derived from that, not from a client-side setting. The authentication aligns. Threading holds. The via line never appears.

This is what Folio does by default, and it's also what Google Workspace does — a single tenant can host many domains as secondary domains, each with its own DKIM and SPF, so per-domain authentication doesn't require a tenant per domain. (Operators who want each entity legally and operationally separate may still choose a tenant per entity, and then pay per user for each.) The difference between Folio and Workspace is pricing model and where the separation boundary sits, not authentication architecture. The difference between either and Gmail aliases is architectural — aliases are a surface trick over a single-identity substrate.

Side by side, on the dimensions that decide whether a setup survives contact with real correspondence:

Reply-From

Gmail Send as: heuristic, derived client-side from the incoming To/Reply-To; silently falls back to your canonical Gmail address in several cases.  Folio multi-domain: derived from the recorded envelope-recipient at ingest, so the reply leaves from the address the letter arrived at.

Threading

Send as: breaks when the From flips to the wrong address — the recipient's client starts a new thread.  Folio: holds, because From, References, and Message-ID stay consistent per identity.

Per-domain DKIM

Send as: outbound is signed with gmail.com's key (default mode), not your domain's.  Folio: each bound domain has its own DKIM key pair, signed with the sending domain's key.

Sending reputation

Send as: shared across every alias on the account; one bad run can taint the rest.  Folio: a separate reputation pool per domain, so one domain's trouble doesn't bleed onto the others.

Custom-domain hosting

Send as: a surface label over a single gmail.com mailbox; the domain isn't truly hosted.  Folio: each domain is genuinely bound and hosted — its own MX, SPF, DKIM, and DMARC.

§ When Send as is still the right answer.

This essay shouldn't read as an argument that Send as is always wrong. It's specifically wrong for operators whose business depends on the identities being treated as truly separate. If you're running one business and occasionally need to send from a vanity alias — yourname@yourcollege.edu for alumni correspondence, say — Send as is perfect. It costs nothing, it works nine times out of ten, and the failure mode (a reply goes out from your Gmail address) is usually harmless.

The question is whether your usage matches that profile or the portfolio-operator profile. The tell: are you sending business-critical correspondence from an alias? If yes — if a reply going out from the wrong From would harm a client relationship, burn a lead, or confuse a press contact — you've outgrown Send as. Switch to something that treats the identity as first-class. Your week will read shorter.