Diagnose Lifecycle Email Deliverability Failures

Required inputs

Have these details available before following the usage instructions.

• ESP performance data: deliveries, bounces, complaints, opens, clicks, unsubscribes, deferrals, blocks, suppressions, and affected segments.
• Sender identity details: domains, subdomains, IPs if applicable, recent DNS/authentication changes, SPF, DKIM, DMARC, BIMI, and alignment status evidence.
• Lifecycle flow details: triggers, audience criteria, send cadence, templates, subject lines, content, personalization, and recent changes.
• Consent and audience-quality evidence: source of subscribers, opt-in method, list age, inactive cohorts, imports, suppression rules, and unsubscribe handling.
• Provider or mailbox evidence: bounce codes, block messages, postmaster data, seed tests, spam reports, or support responses.
• Business constraints: critical transactional/lifecycle messages, risk tolerance, recovery timeline, compliance requirements, and approval owners.

How to use this Skill

When to use:
- When lifecycle emails are landing in spam, being deferred, bouncing, throttled, blocked, or showing sharp engagement degradation.
- Before increasing send volume after a deliverability incident, sender-domain change, list migration, or ESP migration.
- When diagnosing authentication, consent, suppression, segmentation, reputation, or content risks in automated lifecycle campaigns.
- When creating a cautious staged sending recovery plan for marketing, lifecycle, or customer-communications teams.

When not to use:
- Do not use to bypass consent, unsubscribe, suppression, legal, or platform policies.
- Do not use for cold outbound strategy unless lifecycle-email evidence and permission basis are clearly supplied.
- Do not use to claim inbox placement guarantees; deliverability outcomes remain uncertain and provider-controlled.
- Do not use to send, warm, throttle, or change DNS records automatically; those require authorized owners.

Instructions:
1. Open AMO-P-000255, supply its required inputs, and run the complete source Prompt in ChatGPT. Review its evidence register and limitations before using the result.
2. Separate confirmed facts, plausible hypotheses, unsupported assumptions, missing information, and uncertainty for each suspected cause.
3. Trace the issue across sender identity, authentication, DNS alignment, reputation, audience quality, consent, segmentation, content, cadence, provider feedback, suppression logic, and recent operational changes.
4. Compare affected and unaffected message streams, domains, cohorts, geographies, mailbox providers, templates, and time periods to narrow likely causes.
5. Propose owner-authorized recovery actions that reduce harm first: pause or throttle risky flows, protect critical messages, fix authentication, respect suppression, isolate bad cohorts, and verify consent boundaries.
6. Design staged sending controls with measurable entry/exit criteria, monitoring thresholds, rollback triggers, and owners.
7. Avoid claiming provider-level confirmation, DNS validation, or placement improvement unless the user supplies evidence.

Expected output:
A deliverability recovery brief with an evidence register, likely-cause ranking, affected-scope map, immediate containment actions, staged remediation plan, monitoring metrics, approval gates, and unresolved evidence requests.

Constraints and boundaries:
- Require human approval for DNS changes, sender-domain changes, volume increases, suppression changes, policy changes, or customer-facing communications.
- Do not recommend emailing users who lack a valid permission basis or who are unsubscribed, suppressed, or legally restricted.
- Do not overstate certainty from open-rate changes alone; account for privacy filtering and measurement limitations.
- Do not promise inbox placement, sender reputation repair, or provider delisting outcomes.
- Keep content recommendations grounded in supplied templates and policy constraints.
- Use sanitized message/header evidence without recipient addresses, credentials or confidential message contents. Distinguish sent, accepted, deferred, bounced, measured delivery and inbox placement. Do not rotate identities or routes to evade enforcement; verify current provider-specific requirements from supplied authoritative evidence rather than inventing thresholds.

Based on an Amo.ng Prompt

Lifecycle Email Deliverability Recovery Playbook

Open the linked Prompt to read the instructions this Skill is based on.

Completion criteria

Complete when:
- Findings cite supplied ESP metrics, bounce codes, DNS/authentication evidence, consent records, provider feedback, or clearly marked inference.
- The plan identifies affected versus unaffected streams and explains why likely causes were ranked.
- Recovery steps include measurable thresholds for throttling, resuming, escalating, or stopping.
- Compliance and suppression risks are explicitly checked before recommending further sends.
- The output includes missing evidence that would materially change the diagnosis.