# ESP Compliance Playbook

How to avoid Google, Microsoft, and Yahoo flagging Warmbox as an abusive or detectable warmup service.

## Threat model

ESPs detect warmup services via:

| Signal | Detection vector |
|--------|------------------|
| Volume spikes | Sudden send increases |
| Machine cadence | Sends every N minutes exactly |
| Identical content | Same body hash across mailboxes |
| Artificial pools | Known warmup IP/domain clusters |
| 100% engagement | Every message opened/replied |
| Bad pool hygiene | High bounce rate in network |
| Missing auth | SPF/DKIM/DMARC failures |
| Spam complaints | User marks as spam |

## Warmbox mitigations

### 1. Own satellite pool (phase 1)

User controls all mailboxes. No unknown third-party addresses. Lower pool-toxicity risk than public warmup networks.

### 2. Human-like scheduling

- Send windows (business hours)
- Random jitter 45–180 min between sends
- 48h volume cap +20%
- Weekend volume reduction (optional)

### 3. Realistic engagement

- Reply rate 30–45%, not 100%
- Some messages: rescue + read, no reply
- Varied AI content with validation
- Threaded replies with proper `In-Reply-To`

### 4. Content hygiene

- Plain text, no links/pixels in warmup
- No placeholder templates
- Industry-appropriate language
- No sales spam triggers

### 5. Authentication

Pre-flight checks before campaign start:

| Check | Required |
|-------|----------|
| SPF record | Pass or warn |
| DKIM signing | Pass or warn |
| DMARC policy | Present (p=none minimum) |
| Reverse DNS | Warn if missing |

`POST /mailboxes/:id/dns-check` (future)

### 6. Volume discipline

| Rule | Value |
|------|-------|
| Max warmup sends/day/mailbox | 50 hard cap |
| Recommended max | 40 |
| New domain age before warmup | 14 days recommended |
| Never stop warmup during cold sends | Maintenance mode 20% |

### 7. Auto-pause

| Trigger | Action |
|---------|--------|
| Bounce rate >5% | Pause campaign |
| Spam rate >30% (3 days) | Pause + alert |
| Auth errors | Mark error, stop |
| Complaint signal (future) | Immediate pause |

### 8. Peer network (phase 3 only)

If added:

- Verify DNS on every peer mailbox
- Remove bouncing addresses within 24h
- No cross-tenant data leakage
- Rate limit peer assignments
- Monitor pool spam rate aggregate

## Provider-specific guidance

### Google Workspace / Gmail

- Use app passwords or OAuth
- Enable [Postmaster Tools](https://postmaster.google.com)
- Target spam rate <0.1% (alert at 0.3%)
- Avoid connecting consumer Gmail accounts with suspicious bulk patterns
- `[Gmail]/Spam` rescue is user-owned mail — acceptable

### Microsoft 365 / Outlook

- Enable IMAP/SMTP auth
- Respect sending limits (~30/min, ~10k/day)
- Monitor SNDS (future)
- Junk folder rescue

### Yahoo

- App password required
- Lower daily limits than Google
- Watch Bulk folder

## What Warmbox is NOT

- Not a cold email sender — don't blast prospects through warmup
- Not a link tracker — no pixels in warmup phase
- Not a shared bot network — own satellites first

## Legal & ToS

Operators must:

- Own or control all connected mailboxes
- Comply with provider Terms of Service
- Not use warmup to deceive recipients (warmup is internal engagement only)

Document in Terms of Service before SaaS launch.

## Compliance checklist (pre go-live)

- [ ] SPF/DKIM/DMARC verified on primary domain
- [ ] Domain age ≥14 days
- [ ] Recipe = Grow, duration ≥30 days
- [ ] Reply rate ≤45%
- [ ] ≥4 satellites assigned
- [ ] AI validation enabled
- [ ] Send window configured
- [ ] Postmaster Tools connected (Gmail)
- [ ] Test campaign 48h with 2 sends/day before full ramp

## Rumor: "ESPs detect warmup services"

**Partially true.** ESPs detect **patterns**, not brand names. Mitigation is behavioral realism + own pool + auth + volume discipline — not hiding that warmup exists.

Warmbox should be undetectable as a **low-quality bot network**, not invisible as a product.