Gt Email Infra

Setup (Run Once Per Session)

Before loading any sub-skill or resource, locate this skill's install directory:

1. Use Glob to search for **/gt-email-infra/SKILL.md.
2. The directory containing this SKILL.md is SKILL_BASE.
3. Sub-skills are at: {SKILL_BASE}/.claude/skills/{sub-skill}/gt-SKILL.md.
4. Resources are at: {SKILL_BASE}/resources/....

Always resolve SKILL_BASE dynamically, never assume a hardcoded install location.

Email Infrastructure & Deliverability, Orchestrator

This skill is the plumbing that gets cold email delivered, not the message itself. Route by who you are and what you're doing to the one sub-skill that matches. Each sub-skill is self-contained and ends in a copy-pasteable checklist.

Platform: this skill supports the sequencers Growth Today uses, EmailBison, Instantly, Smartlead, and Lemlist. Use the matching setup sub-skill for whichever you run. Concepts are ESP-agnostic; platform-specific steps are called out inline.

When NOT to use this skill

• Writing the email, subject lines, body, sequences, personalization → gt-cold-email.
• Building or verifying the lead list → gt-list-building.
• Marketing emails / newsletters, this is cold-outreach infrastructure only.
• CRM setup or data hygiene → gt-hubspot-admin / gt-salesforce-admin.

Sub-Skill Routing

Cross-Cutting Resources

• All numbers, limits, timelines, thresholds, and the ESP/SEG taxonomy → Read {SKILL_BASE}/resources/reference.md. Never restate one of its numbers in a sub-skill.
• Approved SMTP / sequencer / masking vendors → Read {SKILL_BASE}/resources/approved-vendors.md.
• 2026 market performance benchmarks (results-side: is a bounce/reply rate good or bad vs the market) → Read {SKILL_BASE}/resources/benchmarks.md.

▶️ Playbooks (run these, don't do them by hand)

A playbook is an executable version of a checklist: an interview that collects the inputs, a script that does the work, and an after-state that proves it landed. Read playbook.md first — it contains the interview questions — then run the script.

cd {SKILL_BASE}/playbooks/<name>/scripts
uv run execute.py --help          # every playbook is self-documenting

uv reads the PEP-723 header in each script, so there is nothing to install. If you don't have uv, the fallback from inside a scripts/ directory is pip install -r ../../../requirements.txt.

Scope note. Both playbooks above are read-only and provider-independent — they query public DNS or do arithmetic. Anything that touches a sending platform is governed by the email infra management system boundary below: reads are fine, writes to sending limits, warmup config, tagging or routing are not GT's to make.

🔒 Email infra management system: read-only

The email infra management system is Growth Today's own stack — Supabase, Railway and n8n crons. It is the source of truth for the automated inbox layer. This skill holds that knowledge and exposes it as a read-only checklist. It is never a second source of truth, and the system's dashboard stays primary.

Read-only exists so there is one answer. The system is ours, so the rule is not "someone else's tool, hands off". It is that the moment a GTM engineer changes a sending limit in Instantly by hand, the system's number and Instantly's number disagree and nobody knows which is right. That is how we ended up with four inbox trackers.

GTM engineers and Sales Ops do not change these. Read the state, report the gap, escalate.

The one time we do set these: at first setup, before an inbox is live and being classified, Sales Ops or the vendor sets the starting warmup and cold values (see the instantly-setup sub-skill). That window closes at go-live. After that, limits, warmup and tags belong to the email infra management system.

Access: no token given to a GTM engineer may change sending limits, warmup config, tagging or routing. Instantly's account-update endpoint can change daily limits and is deliberately out of scope — a permission test must confirm it is refused before any settings check ships.

Critical Rules (Never Break)

1. Never cold-send from the primary/brand domain, only dedicated secondary domains.
2. Mailboxes per domain is provider-specific: Google 2–3, Microsoft up to ~25 (average). Google stays lean for deliverability; Microsoft can host many per domain.
3. One domain = one workspace.
4. Buy across multiple registrars, spread across multiple days, max 4 per registrar per day. ScaledMail owns the buying; GT verifies it happened.
5. Warm up ≥ 21 days / 3 weeks (hard floor; 4 weeks on a cautious build) before sending; link only from domains > 30 days old.
6. Never disable warmup once campaigns are running.
7. Masking or a real landing page, never a bare 301/302 redirect to the main site. (Currently held: GT runs no client redirects. The open item is replacing EmailBison's masking — see approved-vendors.md.)
8. No links and no custom tracking domain in cold email by default (share via LinkedIn or an unlinked URL).
9. ESP matching is not a rule: decide keep/drop from our own dashboard data.
10. Start conservative, scale gradually (≤ 20%/week).

Sizing formula (detail in {SKILL_BASE}/resources/reference.md §4)

Monthly goal ÷ 20 workdays = daily volume → ÷ blended cold per mailbox = mailboxes → × 1.5 buffer. Domains: Google mailboxes ÷ 2–3 + Microsoft mailboxes ÷ ~25 (Microsoft packs far more per domain).

There is no fixed divisor. Ask the client's provider mix first. blended = google_share × 20 + microsoft_share × 5

A Google mailbox sends 20 cold/day, a Microsoft one sends 5. The mix is a per-client call driven by industry and market, so the same 15k/month goal needs anywhere from 57 mailboxes (all Google) to 129 (25/75). Ask for the mix before you quote a number. Full grid in reference.md §4.

Don't do this by hand — run it:

cd {SKILL_BASE}/playbooks/sizing-calculator/scripts
uv run execute.py --monthly-goal 15000
uv run execute.py --contacts 9000 --steps 4 --days-to-clear hiring

The script reads the cold limits out of reference.md §1 at run time, so it cannot drift from the standard the way the old spreadsheet did.

What we can and cannot see

• We can see and control: each domain's public footprint (WHOIS, registrar, creation date, DNS, nameservers, masking host) and our own per-inbox/per-domain sending metrics (bounce, reply, placement, warmup).
• We cannot inspect or split: the vendor's shared warmup/seed pool (EmailBison + EmailGuard under one shared Growth Today account). This risk materialised in June–July 2026: 13 of 17 audited clients were flagged at once on a shared-pool blocklist, and the shared warmup/seed pool is the suspected cause. The escalation path is no longer hypothetical: DNS-footprint check across clients → written per-tenant isolation from the vendor → separate workspace + placement-test account per client.

Growth Today's point of view (our answers)

• Blacklists: only Spamhaus DBL and URIBL count. Everything else is out of scope — Google and Microsoft barely weight the other lists and the email infra management system does not track them. The real fix is domain sourcing, not chasing delistings.
• Microsoft / Outlook: expect weaker Outlook placement; check sudden drops against Microsoft BCL recalibration dates before blaming infra; conservative limits; short copy.
• SEG (Mimecast/Proofpoint/Barracuda): a block is the recipient's policy working as designed. Isolate SEG leads onto dedicated, never-reused domains, low concurrency into one org, no links/tracking, go multi-channel, and recycle burnt SEG domains onto easy Google/Outlook segments before retiring.
• Bounces: strip OOO/auto-replies first: Bison counts them as bounces. In one real audit that turned 1,231 actual bounces into 2,687 — more than double. Read the real number, then diagnose.
• Failover gap: EmailBison can't set a cold limit of 0, so it strands leads on unhealthy inboxes, a real bounce driver. Instantly and Smartlead can set 0 and reroute the lead to a healthy inbox on the campaign.

Routing Rules (composite requests)

Most real requests chain sub-skills. Common ones:

1. "Set up cold email infra for X/month" → domain-research → provisioning → the matching platform setup sub-skill (emailbison / instantly / smartlead / lemlist) → warmup-golive (in order).
2. "Is this workspace set up correctly / audit our setup" → setup-audit (live per-item PASS/WARN/FAIL).
3. "Audit our deliverability / why are we bouncing?" → blacklist-bounce-audit (root cause) + dashboard-reading (health context).
4. "Build / launch a campaign" → campaign-building (route from the matrix), then the launch gate in warmup-golive.
5. "How many domains and mailboxes do I need?" → {SKILL_BASE}/resources/reference.md §4 (sizing).
6. "Is this bounce/reply rate good?" → {SKILL_BASE}/resources/benchmarks.md.
7. Single-topic question → the one matching sub-skill above.

How the SOP Runs (End to End)

The Decision Tree below routes a single question. This is the job in order.

SALES OPS — build the infrastructure
─────────────────────────────────────────────────────────────────────────────────────────
1  Size the build              domain-research         ▶ playbooks/sizing-calculator
2  Ideate + brief ScaledMail   domain-research         ·  ScaledMail buys them, not us
3  Mailboxes + DNS / auth      provisioning            ▶ playbooks/dns-auth-audit
4  Connect to the sequencer    <esp>-setup             🔒 done in the system · verify at 6
5  Warm up, then go live       warmup-golive           ▶ dns-auth-audit as the launch gate
                                                       ·  warmup score read in the dashboard  🔒
        │
        ▼   handover — infrastructure is live
GTM ENGINEER — run campaigns on it
─────────────────────────────────────────────────────────────────────────────────────────
6  Verify before launch        setup-audit             ▶ 21-row table: MCP + DNS playbook
7  Build + route the campaign  campaign-building       ▶ dns-auth-audit --esp-mix (profile the list)
                                                       🔒 the build and the routing themselves
8  Watch inbox health          dashboard-reading       ▶ MCP  list_accounts,
                                                          get_campaign_analytics  🔒 read
9  Bouncing or blacklisted     blacklist-bounce-audit  ▶ EmailBison API replies + DNSBL
                                                          (REST, no MCP connector yet)
        │
        └──▶ fix at 3 (repair / replace domains)  or  re-verify at 6

▶ you can actually run this — a playbook or a named call, not a description of one
·  nothing to run — no API for this, so the skill holds the rules
🔒 read it, don't change it — the email infra management system owns this setting

Numbers and thresholds for every step live in one place: {SKILL_BASE}/resources/reference.md. Steps quote the key (google_cold, warmup_floor_days), never a copied number.

Decision Tree

Who / what?
├─ Sales Ops: ideate or buy domains? → domain-research
├─ Sales Ops: mailboxes / DNS / auth? → provisioning
├─ Set up / connect inboxes (Bison/Instantly/Smartlead/Lemlist)? → the matching *-setup sub-skill
├─ Warm up / go live? → warmup-golive
├─ GTM: build or route a campaign (ESP/SEG)? → campaign-building
├─ GTM: read the dashboard / act on health? → dashboard-reading
├─ GTM: verify a workspace is set up right? → setup-audit
├─ GTM: something bouncing / blacklisted? → blacklist-bounce-audit
├─ Just need a number / limit / threshold? → resources/reference.md
└─ Is this metric good or bad vs the market? → resources/benchmarks.md

Created by Growth Today, the AI-native GTM engineering firm. Maintained by Brigitta Ruha. More open Claude Skills for go-to-market teams: https://www.growthtoday.co/claude-skills