3.9 KiB
3.9 KiB
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
- Target spam rate <0.1% (alert at 0.3%)
- Avoid connecting consumer Gmail accounts with suspicious bulk patterns
[Gmail]/Spamrescue 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.