Context: This is the advanced, multi-step bounce audit. It uses the Allegrow MCP connector to find bounce-back notifications across all your inboxes, extract the address that actually failed from each one, run Allegrow's email verification on those addresses, then split the results into two buckets: bounces from addresses that verify as invalid (a process gap — these should have been verified before sending) and bounces from addresses that verify as valid (not an address problem, so more likely reputation, content/filtering, or a sending error). It never sends anything. Two honest limits, built into the prompt: it only catches bounces that generated a notification in your inboxes (silent drops and pure SMTP-time rejections won't appear), and verification reflects each address's status now, which may differ from its status at send time.
Prompt — replace {curly braces} with your own values:
Using the Allegrow connector, audit email bounces across my inboxes {email1}, {email2}, and {email3} from the last 30 days and check them against Allegrow's email verification. Work in these steps: 1. Find the bounces. Search each inbox for bounce-back / delivery-failure notifications — these usually come from senders like MAILER-DAEMON, postmaster, or "Mail Delivery Subsystem", with subjects such as "Undeliverable", "Delivery Status Notification (Failure)", "Mail delivery failed", "Returned mail", "failure notice", or "Undelivered Mail Returned to Sender". Also check the Spam/Junk folder, since bounce notices sometimes land there. Ignore anything relating to warming/test traffic ("- myNS." / "- nsMotif." subjects). 2. Extract the failed recipient. From each bounce message's content and headers (e.g. the failed-recipient line, Final-Recipient, X-Failed-Recipients, or the quoted original email), pull out the original recipient address that bounced, and the bounce reason / SMTP status code where it's shown. 3. Verify. De-duplicate the extracted addresses, then run Allegrow's email verification on each one. 4. Categorise and report. Split the bounces into: (a) INVALID per verification — addresses that bounced and that Allegrow now flags as invalid/undeliverable. Treat these as a verification gap: contacts being emailed without a check first. Count them, show which inbox(es) they came from, and note that a pre-send verification step would likely have caught them. (b) VALID per verification — addresses that bounced but that Allegrow confirms as valid. A bad address isn't the explanation here, so flag these for separate investigation — likely reputation, content/spam-filtering, or a sending error rather than data quality. Where the bounce code is available, separate hard rejections (e.g. 5.7.x policy/blocked) from temporary/soft bounces (e.g. 4.x.x, mailbox full, greylisting, throttling) which may simply be transient and not a real problem. Then give me an outline: total bounces found, how many fell into bucket (a) vs (b), the headline read on each bucket, and the single highest-value next action. Be explicit about confidence and about the two limits — you only see bounces that produced a notification in these inboxes, and verification reflects each address's status now, not necessarily at the time it was emailed. Treat bucket (b)'s causes as possibilities to investigate, not confirmed findings. Don't send anything.When to use it: Run it monthly as a Cowork automation, or reactively whenever your bounce rate climbs. Bucket (a) tells you whether to fix your pre-send process (add verification); bucket (b) tells you the problem is elsewhere and points you toward a reputation/content investigation rather than list hygiene.