Troubleshooting

Gmail Says “Sent,” But Recipient Never Got It?

A fast, proof-first workflow to separate true delivery failures from inbox filtering and sender mismatch.

Common loop: your agent returns success, maybe even a message ID, but the recipient says nothing arrived.

Reality check: “Send succeeded” is not the same as “recipient saw it in Primary Inbox.” You need delivery proof on both sender and recipient sides.

Fast path (5 steps)

1) Lock sender identity first

Confirm the exact sending account and alias before retrying. Many misses are “sent from wrong mailbox” incidents.

2) Send one canary with unique subject

Use plain text and no links/attachments:

DELIVERY_CANARY_{{YYYYMMDD}}_{{HHmm}}

Keep this test tiny. No campaigns, no formatting, no bulk recipients.

3) Capture sender-side proof

Require: sent status + message ID + timestamp + recipient address exactly as sent.

4) Check recipient-side folders in order

Recipient should check: Primary → All Mail → Spam/Junk → Promotions/Updates using the unique subject line.

5) Retry once with one variable changed

If not found, change only one variable (recipient domain, alias, or subject/body style) and retest. Avoid random multi-change retries.

Copy/paste recovery prompt

My Gmail connector reports success, but the recipient didn’t receive the email. Do this exactly: 1) Confirm active sender account and alias. 2) Send ONE plain-text canary email to: RECIPIENT@example.com 3) Subject: DELIVERY_CANARY_TEST 4) Body: "canary" 5) Return only: sender address, alias used, recipient address, send status, message ID, timestamp, and raw error text if any. 6) Do not reconnect unless there is an explicit auth error.

High-friction failure patterns

Wrong sender account/alias: message was sent, but from an unexpected mailbox.
Recipient-side filtering: message lands in Spam/Promotions, so it appears “missing.”
Formatting triggers: heavy links/attachments on first send can increase filtering.
Workspace domain policy: recipient org silently blocks or quarantines external senders.

Advanced edge cases

Send-as alias not fully trusted: Gmail accepts send request but downstream providers de-prioritize or reject.
SPF/DKIM/DMARC misalignment: custom domain configuration can cause delivery failure despite local “sent” success.
Recipient typo or auto-corrected address: especially when pulling contacts from memory/context.
Rate or reputation throttling: multiple retries in a short window may degrade deliverability.

New high-friction cases (worth checking early)

Threading confusion: recipient replies in an older thread while you’re checking only for a new top-level message.
Recipient forwarding rules: message was delivered, then auto-forwarded/archived/label-filtered out of expected inbox views.
Google Workspace quarantine/hold: sender sees success, but recipient org security policy delays or quarantines delivery.
Plus-address mismatch: canary sent to name+tag@domain.com while recipient checks only name@domain.com routing expectations.

Loop-break rule: after two canary attempts with full proof capture, stop retrying and escalate with evidence. Reconnect loops won’t fix deliverability policy issues.

Escalation packet (copy exactly)

- Sender mailbox + alias used - Recipient mailbox/domain - Canary subject - Send timestamp + timezone - Message ID returned by send action - Recipient folder search result (Primary/All Mail/Spam/Promotions) - Exact raw error text (if any) - Surface used (dashboard/DM/server/thread)

Bottom line: prove sender identity + one canary + recipient folder search before changing config. Most “never got it” cases are filtering or identity mismatch, not connector breakage.