Troubleshooting
Gmail Connected, But Sending from the Wrong Account?
A deterministic fix for account/alias mismatch so emails send from the identity you expect.
Common pain point: your connector works, but sent emails come from the wrong Gmail inbox, wrong alias, or wrong display identity. This is usually account mismatch—not a broken connector.
Reality check: "connected" does not guarantee the sender identity you intended. You must prove the active sender with one canary email.
Fast path (4 steps)
1) Identify the exact sender you want
Write it down explicitly (for example: founder@company.com alias under yourname@gmail.com). Most loops happen because this is implied, not stated.
2) Ask the agent to report active authorized account before sending
Require exact output: active Gmail address + available send-as identities/aliases (if any).
3) Run a one-recipient canary with sender proof
Send one plain-text email to yourself with a unique subject and return the message ID. Verify the visible sender in your inbox.
Subject: GMAIL_SENDER_CANARY_{{YYYY-MM-DD_HH:mm}}
Body: sender identity test
4) Lock sender identity in task prompts
Before every production email task, require: “Use sender X only; if unavailable, stop and report.”
Copy/paste recovery prompt
My Gmail connector is sending from the wrong account/alias.
Do this exactly:
1) Report the currently authorized Gmail address.
2) Report available send-as aliases (if exposed).
3) Send ONE canary email to MY_EMAIL@example.com
4) Subject: GMAIL_SENDER_CANARY_TEST
5) Body: "sender test"
6) Return only: authorized account, actual sender shown, message ID, and exact error text if anything fails.
7) If the requested sender identity is unavailable, STOP and tell me exactly what must be changed.
High-friction failure patterns
- Wrong Google account authorized: OAuth completed with personal Gmail while user expected workspace/domain mailbox.
- Alias not verified in Gmail settings: connector can send, but not from custom alias until verification is complete.
- Cross-surface confusion: connected in one account/session, tested in another surface or workspace.
- Draft created by one identity, sent by another: workflows that split draft/send can hide sender mismatch.
Advanced edge cases
- Google Workspace policy restrictions: org rules may block send-as for unapproved aliases/domains.
- Multiple browser profiles during OAuth: user finishes consent in a different signed-in account than intended.
- Reply-from confusion: recipient clicks reply and sees a different return path due to alias/reply-to configuration.
- Stale auth state after account changes: reconnect once cleanly, then retest with canary before production sends.
Loop-break rules
Stop blind reconnecting: do one identity-proof canary cycle at a time. If sender is still wrong, escalate with exact account + sender evidence instead of repeating setup.
What to include if you escalate
- Expected sender identity (exact address/alias)
- Authorized account reported by the agent
- Canary subject + timestamp (with timezone)
- Actual sender seen in inbox
- Message ID + exact error text (if failed)
Bottom line: sender mismatch is almost always identity/config drift, not random failure. Prove sender with one canary, then scale.