You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When setting up Google Workspace, if the admin is signed into a personal @gmail.com account, Google may convert that personal account into the Workspace account rather than creating a fresh mailbox.
Symptoms
New Workspace user (e.g., user@yourdomain.com) shows years of old mail
Storage is already full (inherited from personal account)
"Contact information" during setup showed the personal Gmail address
What Happened
Google "upgraded" the personal account to become a managed Workspace account:
Personal account was renamed to the Workspace address
All mail, contacts, Drive files came with it
The original @gmail.com address may no longer exist
How to Verify
Check 1: Try Signing Into the Original Gmail
Open incognito window
Go to gmail.com
Try signing in with the original @gmail.com address
If it fails or redirects → conversion happened
Check 2: Admin Console User Details
Go to admin.google.com
Directory → Users → Click the user
Look at "Account created" date
If it's years old (not recent) → conversion happened
DO NOT Delete the User
If conversion happened, deleting the user in Admin console will delete years of personal email. Do not do this.
Safe Path Forward
Leave the converted account alone for now
Create a fresh test user (e.g., test@yourdomain.com) for mail forwarding experiments
Research before acting on the converted account
Options for the Converted Account
Option A: Create Second User, Ignore the Problem
Use a fresh user for your actual needs
Converted account sits there, maybe used for admin only
Low risk, easy
Option B: Unmanage the Account
Google may allow "releasing" a converted account back to personal
Check Admin console for this option
Research current Google documentation first
Option C: Cancel Workspace Trial
RISKY - behavior unclear
Might convert account back to personal
Might delete everything
Contact Google support before trying this
Option D: Contact Google Support
Workspace trials include support
They can clarify exactly what will happen
Recommended before any destructive action
Lessons Learned
When setting up Google Workspace:
Use an incognito window or sign out of all Google accounts first
Don't use a personal Gmail as the initial admin if you want to keep it separate
Create the admin account fresh with the new domain address
Google Workspace Day 1 Warning: What We Learned the Hard Way
Date: January 2026
TL;DR
Setting up a Google Workspace trial nearly destroyed a personal Gmail account with 211,736 emails. Everything was recoverable, but the experience was terrifying and poorly documented.
What Went Wrong
The Account Conversion Trap
When setting up Google Workspace while signed into a personal Gmail account, Google may silently convert that personal account into a Workspace-managed account. This happens without clear warning.
Symptoms:
Personal Gmail suddenly shows "Managed by yourdomain.com"
Years of personal email appears under a new Workspace address
Storage shows as full (inherited from personal account)
"Important changes to your account" message on login
The Documentation Problem
Google's docs say things like:
"After you cancel your Google Workspace subscription, your users' Google Workspace data will be deleted and can't be restored."
This is terrifying and wrong for converted personal accounts. The actual behavior:
Personal account data is preserved
Account converts back to personal/consumer status
Everything works fine
But you won't know that from reading the docs.
The Support Experience
Chatbot: Gave contradictory answers, didn't understand the scenario
First support agent: Suggested deleting the user (would have deleted all data!)
Specialist team: Finally gave correct instructions
Ticket number: Essential for documentation - get one
How to Avoid This
Before Starting a Workspace Trial
Use an incognito/private window
Sign out of ALL Google accounts first
Never set up Workspace while signed into a personal Gmail
Create only fresh users - never convert existing accounts
If You Already Converted an Account
See: google-workspace-unmerge-confirmed-process.md in this gist
Short version:
Do a Google Takeout backup first
Create a new Super Admin user
Remove the converted account from Workspace (choose "Do not Transfer Data")
Account reverts to personal with all data intact
The "Activate Gmail" Mystery
After recovery, Gmail may show an "Activate Gmail" or "Set up Gmail to receive emails" banner.
What it does: Nothing useful. Clicking it tries to open the Workspace Admin console (which doesn't apply to a personal account).
What to do: Click it to make the banner go away, then close any admin.google.com tabs it opens. Or just click Dismiss.
Email already works - the banner is just stale UI from the conversion.
Timeline of Our Experience
Time
Event
0:00
Started Workspace trial
0:05
Noticed personal Gmail was "converted"
0:10
Panic - 211,736 emails at risk
0:30
Chatbot giving mixed messages
1:00
Started Google Takeout (60GB backup)
1:30
Contacted human support
1:45
Escalated to specialist team
2:00
Got confirmed process from specialist
2:15
Successfully removed account from Workspace
2:20
All data preserved, email working
2:30
Dismissed mysterious "Activate Gmail" banner
Key Lessons
Google's Workspace onboarding can silently convert personal accounts - This is a known issue ("I can't count how many customers contacting us with this issue" - Google Support)
The documentation is wrong/misleading - Don't trust warnings about "permanent deletion" for converted accounts
Always do Takeout backup first - Even when support says you don't need it
Get a human specialist - The chatbot and first-tier support may not understand converted accounts
Get a ticket number - Document everything in case you need to escalate
Day 1 of Workspace trial may be spent recovering from Workspace - Budget your time accordingly
Confirmed Process: Unmerge Personal Gmail from Google Workspace
Source: Google Workspace Support (Ticket #67121438, January 2026)
Status: CONFIRMED WORKING ✓
The Problem
When setting up Google Workspace, a personal Gmail account can get "converted" to a managed Workspace account. This document describes the confirmed process to restore it to a personal account.
Symptoms of a Converted Account
Personal Gmail shows as "Managed by yourdomain.com"
Old personal emails appear in the Workspace account
Profile shows new Workspace address (e.g., user@yourdomain.com) but contains years of old mail
"Important changes to your account" message appeared during login
Confirmed Solution (from Google Support)
Prerequisites
Complete a Google Takeout backup first - Recommended even though support says it's not needed
Note your ticket number if you contact support (for documentation if something goes wrong)
Step 1: Create a New Super Admin
In Admin console (admin.google.com), create a new user
Grant Super Admin privileges to this new user
Sign out and sign back in as the new Super Admin
Step 2: Remove Admin Role from Converted Account
Go to Directory → Users
Find the converted account (e.g., filter@yourdomain.com)
Remove the Super Admin role from this account
Step 3: Remove the User from Workspace
Click on the converted user account
Click REMOVE USER
Choose "Do not Transfer Data"
Important: Support confirmed: "All data from personal emails are safe and secured."
Step 4: Complete the Conversion
After removal, when logging into the original Gmail address, you'll see:
"Your account has been removed from an organisation"
"Your admin has converted your managed Google Account to a consumer account."
If you used Google Workspace with Gmail: You may see a prompt to "add Gmail" to your account within 30 days. Click "Next", agree to terms and conditions.
Step 5: Verify
Sign into the original personal Gmail address (e.g., bluebirdsupport@gmail.com)
Follow any prompts to re-enable Gmail / agree to terms
Verify all emails and data are present
Test sending an email TO the account to confirm receiving works
Confirmed Outcome
Result: 211,736 emails preserved. Sending and receiving works immediately.
You may still see an "Activate Gmail" / "Set up Gmail to receive emails" banner. This can be ignored or dismissed - email works without clicking it.
Safety Net: 20-Day Restore Window
Support confirmed: "Once you deleted the user, you have 20 days to restore the user and its data."
If something goes wrong, you can restore within this window from Admin console:
Directory → Users → "Add a filter" → Show deleted users
What Support Said
"I can't count how many customers contacting us with this issue."
The documentation is misleading. The warnings about "permanent deletion" refer to Workspace-specific data, not the original personal account data.
Warnings
Always do a Takeout backup first - Even with support confirmation, protect yourself
The docs are scary and wrong - They warn about permanent deletion but that's not what happens for converted personal accounts
Get a ticket number - If you contact support, document the conversation
Ignore "Activate Gmail" banner - Email works without it
Summary
Personal Gmail got converted to Workspace-managed account during trial setup
Created new Super Admin, removed converted account from Workspace with "Do not Transfer Data"
Account converted back to personal consumer account
All data preserved, email working immediately
The support agent was right. The documentation was terrifying and wrong.
# Forward to Google Workspace
# Only need bluebird.co.za addresses - aliases follow automatically
user@bluebird.co.za smtp:[aspmx.l.google.com]:25
anotheruser@bluebird.co.za smtp:[aspmx.l.google.com]:25
# For Workspace-only addresses (no local alias)
bbfilter@intelms.com smtp:[aspmx.l.google.com]:25
# Existing entries for other routing...
hhsys.org smtp:oregon.intelms.com
.hhsys.org smtp:oregon.intelms.com
# ... etc
# NO CATCHALL! (see below)
IMPORTANT: Remove any * : catchall entry!
If you previously had * : at the end of the transport file, remove it. With the hash file now FIRST in transport_maps, a catchall would match everything and prevent LDAP lookups from ever being consulted.
Without catchall:
Hash file checked → specific matches used
No match → falls through to LDAP
LDAP determines local delivery (dovecot:, bbprocmail:, error:, etc.)
Alias → user@bluebird.co.za → transport map → Google
bbfilter@intelms.com (no alias)
relay_recipient_maps OK → transport map → Google
random@intelms.com (neither)
Rejected
user@bluebird.co.za (in transport)
LDAP validates → transport map → Google
localuser@bluebird.co.za (not in transport)
LDAP validates → LDAP transport → local delivery
Why relay_domains for intelms.com?
With virtual_mailbox_domains, Postfix requires every recipient to exist in either:
virtual_alias_maps (rewritten to another address)
virtual_mailbox_maps (local mailbox)
Addresses like bbfilter@intelms.com (Workspace-only, no local alias) have neither, so they'd be rejected.
With relay_domains, Postfix accepts addresses validated by relay_recipient_maps and routes them according to transport_maps.
Notes
Square brackets[aspmx.l.google.com] = use A record directly, skip MX lookup
Port 25 = standard SMTP (Google accepts server-to-server)
Skipping MX lookup is essential since YOUR server is the MX — without brackets, Postfix would loop
Transport map order matters — first match wins, so put the hash file before LDAP lookups
No catchall in hash file — a * : entry would prevent LDAP fallthrough
Testing
# Verify transport map entry
postmap -q "user@bluebird.co.za" hash:/etc/postfix/transport
# Should return: smtp:[aspmx.l.google.com]:25# Verify relay recipient (for intelms.com addresses without aliases)
postmap -q "bbfilter@intelms.com" hash:/etc/postfix/relay_recipients
# Should return: OK# Send test and watch logsecho"Test"| mail -s "Transport test" user@bluebird.co.za
tail -f /var/log/mail.log
You should see Postfix connecting to aspmx.l.google.com instead of delivering locally.
Filtering by Original Recipient in Gmail
If multiple users' mail is forwarded to a single Workspace account (e.g., bbfilter@intelms.com), you'll need a way to filter/forward based on the original recipient.
The Problem
Gmail filters can only match on specific headers:
To/Cc/From/Subject
Message-ID
List-ID (mailing lists)
Delivered-To
The envelope recipient isn't directly filterable, and To/Cc won't contain Bcc addresses.
Solution: Add Delivered-To Header via Procmail
Gmail supports filtering on Delivered-To via deliveredto:user@example.com in filter criteria.
Use procmail to add the header before forwarding to Google:
1. Ensure procmail.sh passes RECIPIENT
The bbprocmail transport in master.cf calls a wrapper script:
bbprocmail unix - n n - 16 pipe
flags=DRqh user=virtual:virtual
argv=/usr/local/scripts/procmail.sh ${nexthop} ${sender}
Important: The ${nexthop} is the mailbox path (e.g., bluebird.co.za/support7local), not the email address. This is because the transport map uses the path format for HOME directory lookup:
2. Create a procmail recipe (in the user's .procmailrc):
# Capture sender from positional arg (for envelope sender preservation)
SENDER="$1"
# Add Delivered-To header with original recipient
# Use -I to replace any existing Delivered-To header
:0 fhw
| formail -I "Delivered-To: $RECIPIENT"
# Forward to Google Workspace, preserving original envelope sender
# Using sendmail -f ensures bounces go to the original sender
:0
| /usr/sbin/sendmail -oi -f "$SENDER" bbfilter@intelms.com
Why sendmail instead of !? The -f "$SENDER" flag preserves the original envelope sender. Without this, bounces would go to virtual@camissa.bluebird.co.za instead of the original sender.
3. Update transport map to route through procmail:
# In /etc/postfix/transport
# Route staff addresses through procmail (adds Delivered-To, then forwards)
# Note: The part after bbprocmail: is the mailbox path (domain/user), not email address
user@bluebird.co.za bbprocmail:bluebird.co.za/user
anotheruser@bluebird.co.za bbprocmail:bluebird.co.za/anotheruser
3. Create Gmail filters in the bbfilter@intelms.com account:
Matches: deliveredto:user@bluebird.co.za
Action: Forward to user@gmail.com (or apply label, etc.)
How It Works
Mail arrives for user@bluebird.co.za
Transport map routes to bbprocmail:user@bluebird.co.za
If each user has their own Workspace account, skip procmail and route directly:
user@bluebird.co.za smtp:[aspmx.l.google.com]:25
The procmail approach is only needed when funneling multiple users through a single Workspace account.
SPF/DMARC Verification: It Works!
A common concern with forwarding setups is SPF failure. Testing confirms the inbound gateway + Gmail filter forwarding chain preserves authentication correctly.
Test Setup
Send a spoofed email through your mail server with a fake Received: header to simulate external mail. See spf_test_gist.py in this gist for the full script.
Run it from your mail server (the inbound gateway):
python2 spf_test_gist.py
The script:
Connects directly to aspmx.l.google.com
Adds a fake Received: header with a spoofed external IP
Adds a Delivered-To: header for Gmail filter matching
Uses different Header To vs envelope RCPT TO (realistic scenario)
SPF passes for intelms.com against Google's IP (209.85.220.41)
DMARC fails (header From doesn't match envelope domain)
But ARC passes — the chain proves original authentication was valid
Message delivered because arc=pass overrides DMARC failure
Key Takeaway
The forwarding architecture is sound for authentication:
SPF passes at each hop (original sender, then SRS-rewritten sender)
DMARC may fail on final hop, but ARC preserves the trust chain
Gmail trusts its own ARC signatures through the forwarding path
The only remaining issue is the UX annoyance of messages arriving as "read" (see below).
Known Limitation: Forwarded Mail Arrives as "Read"
When using Gmail filter forwarding from the Workspace account (e.g., bbfilter@intelms.com) to personal Gmail accounts, messages arrive marked as read in the destination inbox.
Why This Happens
Gmail's filter "Forward to" action marks messages as processed. The forwarded copy inherits this state and arrives read at the destination. This is Gmail's design, not a configuration issue.
Why Not Forward Directly from the Mail Server?
Forwarding directly from the mail server to personal Gmail breaks SPF:
mail server → personal Gmail
↑
SPF FAIL (server not authorized to send for original sender's domain)
The Workspace inbound gateway configuration tells Gmail to trust the mail server as a forwarder and check SPF against the original sender. Personal Gmail doesn't have inbound gateway settings — that's a Workspace admin feature.
So the flow must go through Workspace:
mail server → Workspace (gateway trust) → filter forward → personal Gmail
↑
(arrives read)
Workarounds
Option
Pros
Cons
Accept it
No complexity
Messages arrive read
Each user gets own Workspace account
Direct delivery, arrives unread
~$7.20/user/month
Label + Apps Script
Free
Complex setup per user (see below)
Access bbfilter via delegation
Free, proper unread status
Different workflow (shared inbox)
Label + Apps Script Workaround
If you want messages to appear unread in personal Gmail without paying for per-user Workspace accounts:
For a small number of users, "accept it" or "each user gets Workspace account" are the simplest options. The label+script approach works but requires per-user setup and maintenance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
