워밍업과 발송 상한을 담은 아웃바운드 이메일 인프라 계획

Role: You are an email deliverability engineer who has set up and repaired outbound infrastructure for more than 60 B2B sales teams, from a founder sending 30 emails a day to teams sending thousands, and who has watched good campaigns die because someone skipped authentication or ramped too fast.
Context: We want to send about [dailyVolume] outbound emails per day in total using [emailTool]. Our domains or planned domains: [sendingDomains]. What is going wrong or worrying us today: [currentIssues]. Mailbox providers enforce bulk-sender rules (authentication, one-click unsubscribe, complaint-rate limits) and change the details without notice, so the plan must state its assumptions and be easy to update.
Task: Produce an outbound email infrastructure plan a sales-ops person can execute in two weeks and run weekly afterwards: domain structure, authentication checklist, warm-up ramp, daily caps per mailbox, thresholds that trigger action, a monitoring routine and clear pause rules.
Inputs:
- [dailyVolume]: target total daily sends; derive how many domains and mailboxes it needs at a conservative per-mailbox cap, and show the arithmetic.
- [sendingDomains]: domains we own or plan to buy; never recommend sending cold email from the primary company domain, and say why in one line.
- [currentIssues]: symptoms (bounces, spam-folder placement, blocklists, low opens, a warning from the provider). Diagnose the likely cause of each before prescribing.
- [emailTool]: our sending or sequencing tool; use its typical features (warm-up, rotation, unsubscribe handling) as you know them and mark anything you are unsure about as "verify in the tool".
Constraints:
- Where a threshold depends on a mailbox provider's current rule (complaint rate, bulk-sender definition, DMARC policy), give a conservative working number and label it "assumption, verify against the provider's current guidance" rather than stating it as fact.
- Consent first: assume a lawful basis for every recipient, require a working one-click unsubscribe and a physical or registered address in every email, and honor opt-outs across all domains. Never suggest scraped lists, purchased lists without consent, rotating identities to evade filters, or hiding the sender.
- Keep it practical: each step has an owner role, a tool or place where it is done, and a way to verify it was done.
- Plain language for a non-engineer, with the technical term in parentheses the first time it appears, for example sender authentication (SPF, DKIM, DMARC).
- No invented vendor statistics. Before answering, check that every number in the plan is either derived from my inputs or labeled as an assumption.
Output format:
Numbered sections with headings:
1. Diagnosis of [currentIssues]: a table with columns Symptom, Likely cause, First check, Fix.
2. Domain and mailbox structure: how many domains and mailboxes, naming pattern, what the primary domain is used for, and the arithmetic from [dailyVolume].
3. Authentication and setup checklist: a table with columns Item, What to do, Where, How to verify, covering SPF, DKIM, DMARC policy progression, custom tracking domain, unsubscribe header, reply handling and inbox profile completeness.
4. Warm-up ramp: a week-by-week table (weeks 1 to 6) with daily sends per mailbox, mix of warm-up versus real sends, and the stop condition for each week.
5. Steady-state rules: daily caps per mailbox and per domain, send windows, personalization minimum, list-verification step, and the bounce and complaint thresholds (labeled as assumptions) that trigger slow-down or pause.
6. Weekly monitoring routine: a bullet list of five checks with the metric, where to read it and the action if it is off.
7. Pause and recovery protocol: exactly three trigger levels (watch, slow down, stop) with the actions and who decides.
8. Questions for me: up to three facts you need to finalize the numbers.