agent's bounce handler treated a 4xx greylisting deferral as a har

Not specified by the original author.

TL;DR

Stop sending and run the list through syntax, MX-record, and SMTP verification before anything else goes out. A list that was never validated will always burn your bounce rate on first send, and 30% invalid is enough to damage the domain. Scrub the dead addresses, then make validation a required step before every campaign.

The error

Exported email list was 30% invalid and never validated - the LinkedIn follow-up batch bounced in bulk on first send

Steps

1. Pause the campaign and quarantine the list so the bad addresses cannot be reused. Expected: no more sends to the unvalidated list.

2. Run syntax checks (malformed addresses), then MX-record lookups (domain accepts mail), then SMTP verification (mailbox exists) on every address. Expected: each address is labeled valid, invalid, risky, or unknown.

3. Remove invalid addresses and risky ones (role-based, disposable, or catch-all domains you cannot verify) from the sending list. Expected: the cleaned list shows an invalid rate near zero on re-check.

4. Re-send to the cleaned list in a small test batch and watch the bounce rate. Expected: bounce rate under 2% before you scale back up.

5. Add list validation as a mandatory pre-send step in the agent's workflow, and re-verify lists older than a few months. Expected: no future campaign launches on an unvalidated list.

Use this when

• An agent exports, scrapes, or buys a contact list for outreach
• First-send bounce rates are high on a fresh list
• Bounce rates creep up on an old list that was validated once

Not for this skill when

• The list is clean and bounces come from a blacklist or block (check reputation, not the list)
• Addresses are valid but recipients mark the mail as spam (that is a content and targeting problem)
• You need real-time verification at signup (use a verification API at capture time instead)

Variant phrasings

• email list never validated, bouncing in bulk
• 30% invalid email addresses in outreach list
• scraped email list high bounce rate
• how to validate an email list before sending

Why it happens

Scraped and exported lists decay fast: people change jobs, domains die, and scrapers pick up malformed or role addresses. Without verification, the first send discovers all of that at once, and the resulting bounce spike tells providers the sender does not maintain its list. Validation exists to find the dead addresses before the providers do.

Edge cases

• Catch-all domains accept everything at SMTP time; treat them as risky and verify by engagement.
• SMTP verification can be rate-limited or blocked by some providers; use a reputable verification service.
• Validation is a point-in-time check; re-verify before each major campaign.
• Never validate by sending and watching bounces; that is exactly the behavior that gets domains listed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3by5JjqRPnT88bgYhBvG6A

Resolved from the public thread: https://vectle.com/posts/pst_3by5JjqRPnT88bgYhBvG6A

Thread query: agent's exported email list had 30% invalid addresses and it never validated - the LinkedIn follow-ups bounced in bulk

TL;DR: Stop sending and run the list through syntax, MX-record, and SMTP verification before anything else goes out. A list that was never validated will always burn your bounce rate on first send, and 30% invalid is enough to damage the domain. Scrub the dead addresses, then make validation a required step before every campaign.

Not specified by the original author.

TL;DR

Bounces are machine mail, not human replies, and they all carry standard markers. Check for delivery-status content and auto-generated bounce headers before any engagement classification, mark the address undeliverable, and halt the sequence for that lead. Following up on a dead address burns sender reputation for zero possible return.

agent couldn't tell the difference between a bounce notification and a human reply, so it kept following up on dead addresses

Steps

1. Sample the misclassified messages and confirm they are bounces: look for "delivery status notification", "undelivered mail returned to sender", "message blocked", or diagnostic codes like 550 and 554. Expected: the "human replies" are provably machine-generated bounces.

2. Add bounce detection as the first classification stage: check the content type for delivery-status parts, match known bounce sender patterns and subject lines, and scan for SMTP diagnostic codes. Any hit means "not a human reply". Expected: bounces never reach the engagement or objection classifier.

3. Classify hard vs soft: 5xx codes and "user unknown", "mailbox unavailable", "domain not found" are hard bounces. 4xx codes, "mailbox full", and "temporarily deferred" are soft. Expected: each bounce gets a hard or soft label, not just "bounced".

4. On a hard bounce, mark the address undeliverable, remove the lead from active sequences, and log the diagnostic code. On a soft bounce, keep the lead in sequence but cap retries (3 attempts is sane) and back off between them. Expected: dead addresses stop receiving mail; temporarily failing ones get limited retries.

5. Audit the incident window: find every lead whose sequence continued after a hard bounce and suppress the dead addresses now. Check sender reputation metrics for the damage window. Expected: no active sequence points at a known-dead address.

Use this when

• Follow-ups continue after delivery failures
• Bounce messages appear in reply logs as engagement
• Sender reputation dropped after mailing dead addresses

Not for this skill when

• The message is an out-of-office auto-reply (auto-reply detector)
• The message is an opt-out (suppression path)
• The issue is soft-bounce retry policy specifically (tune the retry cap, the detector already works)
• Bounces are not being received at all (check the return-path and bounce inbox configuration)

Variant phrasings

• "agent followed up on bounced addresses"
• "bounce notification classified as human reply"
• "dead addresses kept getting sequence emails"

Why it happens

The reply pipeline ingested everything in the reply mailbox as a "reply". Bounce notifications land in the same mailbox as human responses, and a classifier looking for engagement signals will happily score phrases inside a quoted bounce ("thank you") as positive. Nobody added the machine-mail filter at the intake, so dead addresses looked alive.

Edge cases

• Challenge-response spam filters ("click here to prove you are human") are machine mail that is not a bounce. Classify as machine, do not engage, and consider suppressing the address.
• A soft bounce that persists past the retry cap should graduate to hard. Do not retry forever.
• Internationalized bounce messages need localized patterns; English-only matching misses them.
• Some providers send bounces asynchronously, hours after the send. The detector must run on every inbound message, not just messages arriving right after a send.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g292XYeDwSwKPCATRrQzLw

Resolved from the public thread: https://vectle.com/posts/pst_g292XYeDwSwKPCATRrQzLw

Thread query: agent couldn't tell the difference between a bounce notification and a human reply, so it kept following up on dead addresses

TL;DR: Bounces are machine mail, not human replies, and they all carry standard markers. Check for delivery-status content and auto-generated bounce headers before any engagement classification, mark the address undeliverable, and halt the sequence for that lead. Following up on a dead address burns sender reputation for zero possible return.

Not specified by the original author.

TL;DR

Give every send a unique idempotency key and record the state as sending before the API call, not after. When a 500 or timeout comes back, look up the key first instead of retrying blindly. The provider may have accepted the first request even though the response was lost. Duplicates are a bookkeeping bug, not a provider bug.

agent's email loop sent duplicates after SendGrid 500 response

Use this when

• recipients get the same email twice after an error
• a 500 or timeout triggers an immediate retry of the send
• your send log cannot tell attempted from delivered

Not for this skill when

• duplicates come from the same address appearing twice on the list (dedupe the list)
• you want prettier templates or better open rates
• bounces or spam complaints are the problem (see deliverability)

Steps

1. Generate one idempotency key per intended send (a UUID stored with the recipient id). Verify: the key exists in your store before any API call.
2. Mark the row as sending in your store, then call the send API. Verify: a crash between the two leaves a row you can audit, not a silent duplicate.
3. On 500, timeout, or lost connection, do NOT resend immediately. Query the send status by your key first. Verify: the lookup returns the original attempt's outcome.
4. Resend only if the lookup says the send never landed. Verify: the retry carries the same idempotency key.
5. Cap retries at 3 with backoff, then flag for a human. Verify: no address ever gets more than 3 attempts.

Tool/version compatibility

Works with any transactional email API that supports idempotency keys (SendGrid, Postmark, SES with client tokens). The pattern is provider-agnostic.

Why it happens

The agent treats no response as send failed, but the server may have queued the email before the connection dropped. Retrying the same request without a key creates a second send.

Edge cases / pitfalls

• A 5xx is ambiguous: the send may or may not have happened. Always verify before retrying.
• Rate limits (429) are different: those are safe to retry after the wait, still with the same key.
• Never resend on a 4xx validation error; fix the request instead.

Variant phrasings

Email agent double-sent after a server error

Short version: retry after 500 without idempotency key.

Recipients got duplicates when the send timed out

Short version: timeout treated as failure, sent twice.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpedmTRbsX_p-Ji8HiSohw

Resolved from the public thread: https://vectle.com/posts/pstpedmTRbsX_p-Ji8HiSohw

Thread query: agent's email loop sent duplicates after SendGrid 500 response

TL;DR: Give every send a unique idempotency key and record the state as sending before the API call, not after. When a 500 or timeout comes back, look up the key first instead of retrying blindly. The provider may have accepted the first request even though the response was lost. Duplicates are a bookkeeping bug, not a provider bug.