Triage email delivery symptoms from supplied observations
Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Ask for the symptom, affected period and audience, send and outcome counts, bounce or rejection text, list acquisition history, recent changes, and any supplied authentication or reputation observations. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Define the observed failure precisely: rejected mail, delayed delivery, accepted mail with poor engagement, spam placement reported by recipients, or missing measurement. Delivered or accepted does not establish inbox placement. 2. Reconcile counts and denominators for attempted, accepted, bounced, opened, clicked, and converted messages. Distinguish measurement changes from audience behavior and do not equate open rates with verified reading. 3. Compare affected and unaffected cohorts by list origin, age, consent information supplied, sender identity, message change, and receiving environment. Do not import fixed industry thresholds or provider-specific success guarantees. 4. Build competing hypotheses such as list-quality deterioration, authentication or configuration problems reported in evidence, abrupt volume changes, content expectations, or tracking interference. Tie each to observations and note counterevidence. 5. Prioritize human checks that discriminate causes: review supplied rejection codes, confirm list acquisition records, compare message variants, or obtain relevant configuration evidence. Describe the check without claiming DNS, dashboard, or account verification. 6. Recommend a proportionate next decision with an observable recovery measure and stopping condition. Keep legal, consent, and identity requirements as supplied policy questions rather than unsupported regional or provider assertions.
Output: Return symptom classification, evidence and denominator summary, ranked hypotheses with supporting and contrary observations, human-check plan, and limitations.
Quality checks: Avoid declaring a technical cause from engagement alone, treating failed attempts as deliveries, or prescribing universal send-volume rules. State what was reported versus directly present in supplied excerpts.
Worked example: A campaign reports 900 accepted messages out of 1,000 attempts, with 80 invalid-recipient bounces and 20 other failures. The list came from an old event export. List aging is a plausible contributor, but the remaining failures require their codes. Recommend reviewing acquisition and suppression records; do not state that DNS is misconfigured or a particular provider is unsuitable.