Runbook
The "Send mail as" Migration Runbook: Parallel-Run, Cutover, Rollback
Gmail's "Send mail as" is a borrowed side door: your custom-domain mail leaves through Google's SMTP, wearing your address but authenticated as gmail.com. Replacing it cleanly isn't a question of courage or timing — it's a question of proof. You change nothing Gmail can't instantly show you, and you move nothing real until a test message's header has passed every check in front of you. This runbook is two concrete things: the exact clicks inside Gmail's own settings, and the one pair of mail headers — one passing, one failing — that tells you it is safe to switch.
The trouble with "Send mail as" is that it was never really yours. It relays through gmail.com, stamps outgoing mail "via gmail.com," and can be tightened or withdrawn on Google's schedule rather than yours. The replacement is sending you own — SPF, DKIM and DMARC all aligned to your own domain — stood up beside the Gmail setup rather than in place of it. Everything you do here happens in one Gmail screen (Settings → See all settings → Accounts and Import → the "Send mail as" section) until the very last step, and because both sending paths stay listed through the move, nothing your contacts can see ever goes dark. Work the table below from the top, and don't leave a row until its verify column passes.
The cutover, screen by screen
Five stages, each written as the literal path through Gmail's settings, what Gmail shows you once you've done it, and the one-line way back. Nothing here is a leap: every row before the cutover reverts by deleting an entry you just added, and the cutover itself leaves the old "Send mail as" entry sitting in the list, unused but ready.
| Stage | What you do in Gmail | What Gmail shows | Verify / revert |
|---|---|---|---|
| 0 · Pre-flight | Gear → See all settings → Accounts and Import → find the "Send mail as:" block. Click edit info on each entry to read the SMTP host behind it. (Still choosing where sending will live? The options scorecard covers it.) | Every custom address you send from, which one carries the (default) tag, and the SMTP host each relays through. | Verify: a written list of each address, its SMTP host, and the default. Revert: nothing changed yet. |
| 1 · Add the new route | In that same block, Add another email address → enter your name and the custom address → point it at the inbox you own (its SMTP host, port, username, app password) → Add Account → paste the confirmation code Gmail mails to that address. | The new address now sits in the "Send mail as" list beside the old one; the old entry still holds (default). | Verify: both addresses listed, the new one confirmed. Revert: click delete on the new entry — the old default is untouched. |
| 2 · Prove outbound | Compose a message; on the From line open the dropdown and pick the new address; send it to an inbox on another provider and open the result the way their server wrote it. | The From selector now offers both identities, and your test leaves as the new one. | Verify: the header reads the aligned block below — dmarc=pass, header.d matching header.from, no "via gmail.com". Revert: none needed; live mail is untouched. |
| 3 · Cut over | Next to the new address in the "Send mail as" list, click make default. Then re-point inbound (MX or your forwarding rule) at the inbox you own. Leave the OLD entry listed, unused. | The new address now wears (default); fresh replies go out as it. | Verify: a new inbound message lands in the owned inbox and your reply leaves with clean auth. Revert: click make default on the old entry and re-point MX back. |
| 4 · Remove the old entry | After a quiet few days, return to Accounts and Import → "Send mail as" → click delete next to the OLD entry, the one that relayed via Google. | Only the self-owned route remains in the list; there is no "via gmail.com" path left to use. | Verify: no bounces or spam reports, every send-test passing across the window. Revert: the one step with no clean undo — re-adding means re-running Stage 1, so do it only after the quiet window. |
The one stage you don't skip: prove it sends
Stages 0, 1, 3 and 4 are clicks. Stage 2 is the one that earns the whole move, and it's the one people skip because mail headers look like noise. They aren't. Send a single real message from your custom address to an inbox on another provider, open it, and read the Authentication-Results block near the top. Put the two possible outcomes side by side and the difference is one word in one line.
Aligned — clear to cut over. The domain that signed the mail and the domain in the address your recipient sees are one and the same:
Authentication-Results: mx.recipient.example; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com header.s=blf1; dmarc=pass header.from=yourdomain.com
Misaligned — still relaying "via gmail.com." This is what "Send mail as" produces, and it is a trap, because spf and dkim still say pass:
Authentication-Results: mx.recipient.example; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.s=gmd1; dmarc=fail header.from=yourdomain.com
The trap is the top two lines of that second block. spf=pass and dkim=pass only say the message was authenticated by some domain — and here that domain is gmail.com, which is exactly why the broken setup still looks fine at a glance. The line that decides it is dmarc, and DMARC passes only on alignment: header.d (who signed) has to match header.from (the address shown). In the failing block header.d=gmail.com does not match header.from=yourdomain.com, so DMARC fails and the recipient's client prints "via gmail.com" under your name. In the passing block both are yourdomain.com, DMARC passes, and the "via" tag is gone. That alignment is the thing "Send mail as" can never give you, and the arrival of the aligned header is the signal — the only signal — that you're clear for Stage 3. See the failing block instead and you're still relaying through Google; confirm the records with our email authentication checker and DNS tools, then resend before you go near the cutover. For a line-by-line read of these same headers, there's the annotated version here.
dmarc=pass with header.d matching header.from — rather than the "via gmail.com" failure. Prove outbound before you touch inbound, and the Gmail cutoff becomes a day you don't notice.After the cutover: does it keep landing?
This runbook gets you switched; it doesn't tell you whether the new setup will keep landing in inboxes next month. That's a different question — deliverability and reliability rather than clicks — and it has its own answer in self-hosted email that actually works: the reliability checklist, the dig that proves your MX really points where you think, and why there's no sending IP for you to warm or babysit once a provider carries the last hop. Cut over here; confirm it stays healthy there.
Why moving off "Send mail as" is boring
A migration is only frightening when one irreversible step sits in the middle of it. This one has none: the early stages change nothing your contacts can see, the cutover leaves the old Gmail entry sitting in the list, and you click delete on it only after the new path has quietly carried real mail. Blue Folder Mail is built to keep each stage short — a self-hosted, encrypted inbox for every domain you own, on your own Cloudflare account, where replies leave as the address each message arrived at and no third-party relay can go stale after you switch. Mail is stored with zero-access encryption — encrypted at rest with a key derived from your passkey — a strong, specific protection, not a promise that anything is unhackable: inbound mail is plaintext for the instant before it's sealed, and sending still rides a mail provider for the last hop. Run the stages ahead of the cutoff and the day Gmail flips the switch is a day you don't notice.
- How do I migrate off "Send mail as" without downtime?
- Stand up the new sending in parallel while Gmail's forwarding still runs, verify a test message passes SPF, DKIM and DMARC, then switch inbound routing only after the send-test passes. Because old and new overlap, nothing goes dark during the move.
- Can I roll back if the new setup misbehaves?
- Yes. Until you delete the old "Send mail as" entry and re-point DNS for good, the previous path still exists. Each stage of the runbook has a revert step, so you can fall back to the old setup at any point before decommissioning.
- What do I verify before cutting over?
- A real send-test from the custom address that arrives in the inbox with SPF and DKIM passing, DMARC aligned to your From domain, no "via gmail.com" tag, and a reply that threads back to the right address.
- Will contacts notice the migration?
- No. The address they write to never changes; only the machinery behind it does. Run in parallel and cut over after verification and there is no visible gap.