The scorecard
Gmail "Send mail as" Alternatives, Scored: Five Options, and the Two That Actually Pass
Five routes claim to replace Gmail's "Send mail as." Put them all on one scorecard against the jobs the feature really did, and only two survive contact with the criteria. Here is the table, the ranking, and exactly why the other three fall short.
The reason it is worth scoring rather than just picking is that a Gmail "Send mail as" alternative has to clear a surprisingly specific bar. Most write-ups hand you a list and let you guess. This one defines the pass/fail tests first, runs every option through them, and ranks the results — so you can jump to the row that fits how many domains you run and how much effort you have to spend.
The five tests any alternative has to pass
Before the table, the yardstick. A real replacement is judged on five things, and the last one is the one the whole "Send mail as" saga is teaching:
- Sends as your custom address — outgoing mail carries
you@yourdomain.comin the From line, natively, not as a borrowed toggle. - Clean deliverability — SPF, DKIM, and DMARC all align to your domain, so mail lands in the inbox with no "via" tag.
- Revoke-proof — the capability is yours to keep, not a feature a provider can withdraw the way Gmail just did.
- Scales without per-domain rent — adding a second or fifth domain doesn't mean a second or fifth monthly bill.
- Migration effort — how much work the move actually is, rated relative to the others.
Why "revoke-proof" carries the most weight
All five tests matter, but weight them unevenly. Deliverability you can fix; effort you can spend once; cost you can budget for. A capability that lives in someone else's account, though, can disappear on their schedule no matter how well you set it up — and that is the exact failure playing out with "Send mail as" right now. So when two options tie on the surface, the tiebreaker is always: who can switch this off? If the answer isn't "only me," you are buying a future repeat of the problem you're solving today.
The scorecard
Options are listed best to worst by how many tests they pass. ✓ = passes, ✗ = fails, ~ = partial or conditional.
| Option (ranked) | Sends as you | Clean auth | Revoke-proof | Scales free | Effort |
|---|---|---|---|---|---|
| 1. Self-hosted inbox you own | ✓ | ✓ | ✓ | ✓ | Medium |
| 2. Paid mailbox on a mainstream provider | ✓ | ✓ | ✓ | ✗ (per seat / per domain) | Low |
| 3. Sending API + separate inbox | ✓ (outbound only) | ✓ | ~ | ~ | High |
| 4. Third-party SMTP relay bolt-on | ✓ | ~ | ✗ | ~ | Medium |
| 5. Forwarding only | ✗ | n/a | ✗ | ✓ | Low |
"Scales free" means adding more domains without a new recurring charge, not that the option itself is free. Effort is rated in concrete terms: Low = under an hour, mostly clicking through a provider's setup wizard and pasting the DNS records it hands you; Medium = an afternoon, publishing your own SPF, DKIM, and DMARC records and running a send-test per domain; High = a day or more, wiring and then maintaining two separate systems — a sending service and an inbox — that never share one screen.
The key takeaway: the binding test is revoke-proof. Any option that leaves the capability in someone else's hands — a relay, a toggle, a consumer-account feature — can be taken away exactly the way "Send mail as" is being taken away now. Only the top two pass every test, and they split cleanly on one axis: cost at scale.
Reading the ranking
Every mark in the table traces to one concrete reason — the thing that would actually make or break the option in daily use:
- 1. Self-hosted inbox — passes all five. You hold the DNS and run the inbox, so the From line, the DKIM signature, and the on/off switch are all yours; no provider can revoke custom sending the way Gmail is. Adding a tenth domain is one more DNS entry, not a tenth invoice. It's Medium effort, not Low, precisely because you publish the auth records and stand the inbox up yourself.
- 2. Paid mailbox — fails only "scales free." A mainstream provider sends and authenticates natively and can't single out your custom sending to kill it, so it clears revoke-proof — but it bills per seat and usually per domain, so a second domain is a second recurring charge, rebuilding the very cost the free trick existed to dodge. Low effort, because setup is a guided wizard.
- 3. Sending API + separate inbox — two partials. Outbound authenticates cleanly and is yours, but revoke-proof and scales-free are only ~: the paired inbox is still someone else's account, and API pricing climbs with volume. It's High effort because you run two systems — a send service and an inbox — that never share a screen.
- 4. Third-party SMTP relay — fails revoke-proof. Here's the concrete failure: the relay is a feature inside another provider's account, so the day they move it behind a paid tier, tighten the free limits, or retire it, your From line breaks overnight — the identical shape of failure you're fleeing. Clean auth is only ~ because the relay signs with its own domain, so alignment holds only if you configure it exactly right.
- 5. Forwarding only — fails the core job. Forwarding delivers incoming mail and never sends, so there's no outgoing From line to authenticate (that's the n/a) and nothing anyone can revoke — but it can't reply as your address at all, which is the one job the scorecard exists to measure.
Rows 1 and 2 are the only clean passes, and they split on a single axis: a paid mailbox is lowest-effort for one address, while an inbox you own stops charging you the moment you run a second domain.
Which row is yours?
Match the scorecard to your situation and the choice mostly makes itself:
- One address, want it done today: row 2. A paid mailbox is the fastest clean move, and at a single seat the per-domain cost is a non-issue.
- Two or more domains, or more coming: row 1. The moment you'd be buying a second seat or a second domain fee, an inbox you own stops the meter — same bill whether you run two domains or twenty.
- You only need to read mail, not reply as the address: row 5 buys time, but be honest that it isn't sending at all.
- You already push app notifications through a sending API: row 3 can stretch to personal mail, but you'll feel the two-system seams daily — most people decide it isn't worth it for a human inbox.
Notice that no situation lands on row 4: a patch that recreates the original risk — a relay another provider can withdraw out from under you — is not an alternative, it's a rerun.
Where Blue Folder Mail lands on the scorecard
Blue Folder Mail is a row-1 option — a self-hosted, encrypted inbox for unlimited custom domains that runs on your own Cloudflare account. Replies go out as the exact address each message arrived at, SPF and DKIM align to your domain so DMARC passes, and there is no "send as" switch for anyone to flip, because you run the inbox. Adding domains costs nothing extra, which is what tips rows 1 past row 2 once you own more than one.
It also clears a bar none of the mainstream options do: privacy. Mail is encrypted at rest with a key derived from your passkey — zero-access, in the Proton sense — so the server holds only ciphertext and the operators cannot read it. That is a strong, specific guarantee about who can see your mail, not a promise that anything is unhackable; your passkey remains the thing you protect.
- Can I keep using Gmail as my interface?
- You can keep forwarding into Gmail to read mail, but the reliable fix for sending as your custom address is an inbox that supports it natively, rather than a Gmail feature that is being withdrawn.
- What is the cheapest Gmail "Send mail as" alternative?
- For a single address, a paid mailbox is simplest. For several domains, a self-hosted inbox with unlimited addresses avoids paying per domain, which is usually the lower long-run cost.
- Will my old emails disappear?
- No. Mail already in your Gmail stays there. Migration changes where new mail arrives and how you send — your archive is untouched.
- Do I have to tell contacts my address changed?
- No — that is the point. You keep the same custom address; only the machinery behind it changes, so contacts write to and receive replies from the exact same address as before.