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
Gmail deduplicates messages by Message-ID within a single mailbox. When forwarding mail from multiple recipients through a single Google Workspace account, CC'd messages only reach one person.
Postfix forwards both to [email protected] (Workspace account with filters)
Gmail sees same Message-ID twice → keeps only ONE copy
Only one Delivered-To header survives
Workspace filters forward to personal Gmail based on Delivered-To
Result: only Alice OR Bob gets the email, not both
Why This Happens
Gmail's dedup is per-mailbox. When using a single Workspace account as a forwarding hub, all incoming mail hits the same mailbox before filters run. By then, the duplicate is already discarded.
The Solution: gws-forward
Distribute mail across multiple Workspace accounts (bbfilter, bbfilter2, bbfilter3), each with identical filters. A custom Postfix pipe transport tracks which Message-IDs have gone to which accounts.
Postfix invokes gws-forward as a pipe transport for each recipient
gws-forward reads the message, extracts Message-ID
SQLite tracks which accounts have seen this Message-ID
First recipient → preferred account (hash-based)
Second recipient (same Message-ID) → different account
Third recipient → third account
Each Workspace account has identical filters that forward based on Delivered-To
Concurrency Handling
Postfix may deliver the same message to multiple recipients simultaneously. The binary uses SQLite's BEGIN IMMEDIATE transaction to atomically select and record account assignments, preventing two processes from picking the same account.
Overflow Handling (4+ recipients)
With only 3 accounts, the 4th+ recipient would cause Gmail dedup again. Solution:
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., [email protected]) 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., [email protected]) 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., [email protected]) 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
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., [email protected])
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
[email protected] smtp:[aspmx.l.google.com]:25
[email protected] smtp:[aspmx.l.google.com]:25
# For Workspace-only addresses (no local alias)
[email protected] 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.)
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 [email protected] (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 "[email protected]" hash:/etc/postfix/transport
# Should return: smtp:[aspmx.l.google.com]:25# Verify relay recipient (for intelms.com addresses without aliases)
postmap -q "[email protected]" hash:/etc/postfix/relay_recipients
# Should return: OK# Send test and watch logsecho"Test"| mail -s "Transport test"[email protected]
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., [email protected]), 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:[email protected] 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" [email protected]
Why sendmail instead of !? The -f "$SENDER" flag preserves the original envelope sender. Without this, bounces would go to [email protected] 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
[email protected] bbprocmail:bluebird.co.za/user
[email protected] bbprocmail:bluebird.co.za/anotheruser
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)
The key field is dis=NONE — Gmail took no action despite p=REJECT because arc=pass vouched for the original authentication. Message delivered successfully.
Conclusion: ARC overrides even the strictest DMARC policies when the chain is trusted.
Gmail UI vs Raw Headers
Gmail's "Show original" UI displays DMARC results that may seem inconsistent:
Sender Domain
DMARC Record
Raw Header Result
Gmail UI Shows
linkedin.com
p=reject
dmarc=fail ... arc=pass
PASS
bluebird.co.za (before)
(none)
No DMARC check
FAIL
bluebird.co.za (after)
p=none
dmarc=pass
PASS
Why? Gmail's UI shows the effective authentication status:
Reports are gzipped XML, not human-friendly. Services like Postmark DMARC (free) can parse them into dashboards.
Verify:
dig +short TXT _dmarc.yourdomain.com
# Should return: "v=DMARC1; p=none"
Rule of thumb: Any domain with MX or SPF records should also have DMARC.
Status: All domains now have DMARC records:
✓ bluebird.co.za
✓ intelms.com
✓ intelms.com.au
✓ intelms.ca
✓ radiology.co.za
✓ gynecology.co.za
✓ bluebirdims.com
✓ bluesanit.com
✓ bbehraas.com
Known Limitation: Forwarded Mail Arrives as "Read" (False Alarm!)
Update: Initial testing suggested messages arrived as "read" in personal Gmail. This turned out to be caused by an old filter in the test mailbox that was marking everything as read. The forwarding setup works correctly — messages arrive unread.
If you experience this issue, check for filters in the destination Gmail account that might be marking messages as read.
Why Go Through Workspace At All?
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
This preserves authentication via ARC and ensures reliable delivery.
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
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