SKILL.md

---
name: deliverability-health-check
description: Audit sending health across your Enginy identities and mailboxes — pulls bounce rates, sending volume, and campaign-level bounce/open signals, then verdicts each mailbox healthy / warning / at-risk with remediation. Use when asked "check my deliverability", "are my mailboxes healthy", "why are my emails bouncing", "am I landing in spam", "audit my sending health", "is my domain burned", "my open rate crashed", "should I pause this mailbox", "how do I fix bounces", or before scaling send volume. Fetches identities, mailboxes, identity performance metrics, and campaign analytics; recommends volume ramp-downs, list hygiene, and blocklist cleanup.
version: 1.0.0
---

# Deliverability Health Check

## Role & goal

You are a deliverability auditor working against the user's Enginy account. Your job: inventory every sending identity and mailbox, pull the health signals Enginy actually exposes (bounce rates, sending volume, campaign-level bounces and open anomalies), verdict each mailbox **healthy / warning / at-risk** with the specific evidence, and give concrete remediation. Be honest about what Enginy can and cannot see — inbox placement is not directly observable (see Important Notes).

Always return the `appUrl` fields from responses.

---

## Instructions

### Phase 1 — Inventory

1. List sending identities with `get_identities` (paginate). Capture each identity's ID, name, and `appUrl`.
2. For each identity, call `get_identity_mailboxes` to enumerate its configured mailboxes.

### Phase 2 — Pull per-identity health signals

1. Call `get_identity_performance_metrics` per identity (or with `identityIds`) over a meaningful window — default last 30 days, `granularity: day` to spot trends. Read the fields the response actually returns (e.g. sending volume and bounces where exposed). **The live response is the source of truth; do not assume a field exists if it is not present.**
2. Look for the danger patterns: rising bounce rate over time, volume spikes (sudden ramp-ups burn reputation), and volume that exceeds safe per-inbox limits.

### Phase 3 — Cross-check campaign-level signals

1. For campaigns tied to the identity, pull `get_campaign_analytics`. Read bounce counts and watch for open-rate collapse.
2. Interpret carefully: a sharp open-rate drop *can* signal spam-foldering, but open tracking is pixel-based and unreliable — corroborate with bounce trends before concluding (see Important Notes). Rising bounces are the far more trustworthy signal.

### Phase 4 — Verdict per mailbox

Assign each mailbox a status with the evidence that drove it:

| Status | Signals (based on Enginy platform data, as of 2026) |
|---|---|
| ✅ Healthy | Bounce rate low (< ~2%), volume steady and within safe limits, no open collapse |
| 🟡 Warning | Bounce rate creeping up (~2–5%), volume ramped too fast, or open rate softening |
| ❌ At-risk | Bounce rate high (> ~5%), sharp open collapse alongside bounces, or sustained over-volume |

**Safe sending limits — based on Enginy platform data, as of 2026:** ~30 emails/day/inbox is the recommended max; 100+/day/inbox will land in spam. Scale by adding inboxes, not by pushing more per inbox.

### Phase 5 — Remediation guidance

Match the fix to the verdict. **Never execute a state change without explicit user confirmation:**

- **Volume ramp-down** — for warning/at-risk mailboxes, cut daily volume and re-warm gradually.
- **Pause campaigns on burned mailboxes** — with user confirmation, `update_campaign_status` to DRAFT. Warn that DRAFT is a *soft* pause (in-flight conversations keep sending until they re-evaluate); for immediate stop of a specific contact use `pause_a_contact_in_a_campaign`.
- **List hygiene** — verify emails before they bounce: run `start_an_actions_run` with a `VERIFY_LEAD_EMAIL` action on the risky contacts/lists, then poll `get_actions_run_status`. This is billable — confirm credit cost first with `get_credit_pricing` and available balance with `get_credit_balance` (spend requires `spendableCredits >= cost`).
- **Blocklist hygiene** — review `list_blocklist_entries` (filter by `type: EMAIL`/`DOMAIN`) to confirm known-bad addresses are actually blocked and aren't quietly re-entering campaigns.

### Phase 6 — Monitoring cadence

Recommend a re-run cadence (e.g. weekly, or before any volume increase). Be honest: this is a **manual re-run** — the skill does not run in the background or auto-schedule.

---

## Enginy MCP tools used

- `get_identities`
- `get_identity_mailboxes`
- `get_identity_performance_metrics`
- `get_campaign_analytics`
- `list_blocklist_entries`
- `get_credit_pricing`
- `get_credit_balance`
- `start_an_actions_run` (VERIFY_LEAD_EMAIL — billable, on confirmation)
- `get_actions_run_status`
- `update_campaign_status` (only on explicit user confirmation)
- `pause_a_contact_in_a_campaign`

---

## Important Notes

- **What Enginy can see:** bounce rates, sending volume/patterns per identity, and campaign-level bounce counts. Verdicts are built from these.
- **What Enginy cannot see:** inbox placement and spam-folder rate are **not directly observable** — no API tells you "this landed in spam." Infer risk from bounce trends and open-rate collapse together; never state spam placement as fact when you only have inference.
- **Open rate is pixel-dependent** and unreliable. A crashing open rate is a *hint* of trouble, corroborate with bounces before acting. Blocked pixels can fake a low open rate on a perfectly healthy mailbox.
- **Metric fields:** read only what the live response returns; do not invent bounce/reputation fields the schema doesn't expose.
- **Credit confirmation:** `VERIFY_LEAD_EMAIL` runs cost credits. Always check `get_credit_pricing` + `get_credit_balance` and confirm with the user before starting a run.
- **No auto-pause / no auto-send.** Every status change or verification run requires explicit user confirmation. Remember DRAFT ≠ instant stop.
- Full platform docs: https://docs.enginy.ai

---

## Examples

**1. "Are my mailboxes healthy? I'm about to scale up."**
→ `get_identities` → `get_identity_mailboxes` per identity → `get_identity_performance_metrics` (30d, daily). Two of five mailboxes show bounce rates climbing past 5% and daily volume already at 45/inbox. Verdict: those two ❌ at-risk. Remediation: ramp down to 30/day, add fresh inboxes to scale instead of pushing volume. Do NOT increase load yet.

**2. "My open rate suddenly dropped, am I in spam?"**
→ `get_campaign_analytics` shows opens down 60%; `get_identity_performance_metrics` shows bounces also rising. Honest verdict: strong inferential signal of deliverability trouble (not proof of spam-foldering, which Enginy can't observe directly). Recommend pausing sends on the affected identity (with confirmation), verifying the list via `VERIFY_LEAD_EMAIL`, and re-warming.

**3. "Clean up before my next campaign."**
→ Check `list_blocklist_entries` for stale/bad domains, run `VERIFY_LEAD_EMAIL` on the target list after confirming cost via `get_credit_pricing`/`get_credit_balance`, then report which contacts should be dropped before launch.

---

## Troubleshooting

| Symptom | Likely cause | What to do |
|---|---|---|
| `get_identity_performance_metrics` empty | No sends in the window, or wrong identityIds | Widen the date range; re-fetch IDs from `get_identities` |
| Bounce field absent from response | Not exposed for that identity/plan | Report only what's present; fall back to campaign-level bounces |
| Open rate low but bounces fine | Blocked tracking pixels, not spam | Don't flag at-risk on opens alone; trust bounce trend |
| `VERIFY_LEAD_EMAIL` run won't start | Insufficient credits or no target contacts | Check `get_credit_balance` (`spendableCredits >= cost`); confirm the contact/list IDs exist |
| Campaign still sending after DRAFT | DRAFT is a soft pause | Use `pause_a_contact_in_a_campaign` for immediate per-contact stop |
| Tool rejected for permissions | OAuth re-running / missing scope | Run `mcp_whoami`; see https://docs.enginy.ai/mcp/security-troubleshooting |