Un cronograma de IP warmup de 6 semanas para remitentes autohospedados

Una IP sin historial de envío le parece igual a un proveedor de buzones que una IP recién traspasada tras un takeover. No hay señal de legitimidad — todavía. Enviar 50.000 mensajes el día uno desde una IP nueva resulta indistinguible de un spammer alquilando un bloque de IP virgen para disparar antes de que los sistemas de reputación se enteren.

Así que Gmail, Outlook, Yahoo, Apple iCloud Mail y los proveedores regionales hacen todos lo mismo en el primer contacto: aceptan un volumen inicial pequeño, observan cómo reaccionan los destinatarios (abrir / clic / marcar como spam / borrar sin leer) y solo después de algunos días de engagement limpio desbloquean volúmenes mayores. Esos "algunos días" son la ventana de warmup. Si la salta, no queda bloqueado — queda throttled y spam-foldered durante semanas, lo cual es más difícil de recuperar que un rechazo directo.

Hay dos formas de rampa de uso extendido:

• Lineal — mismo incremento fijo por día. 50 → 100 → 150 → 200 → 250 … Predecible, lenta, conservadora.
• Exponencial — multiplica. 50 → 100 → 200 → 400 → 800 … Llega al volumen objetivo más rápido pero es más agresiva al final.

El motor de warmup integrado de AcelleMail (modelo: app/Model/WarmupStrategy.php) soporta ambas vía las constantes GROWTH_STRATEGY_LINEAR y GROWTH_STRATEGY_EXPONENTIAL, más dos presets de conveniencia: PRESET_BALANCED (lineal, incremento moderado) y PRESET_CAUTIOUS (lineal, incremento más chico con una ventana de rampa más larga). Para dominios de envío totalmente nuevos sin reputación histórica, cautious es el default más seguro. Para una migración de IP donde el dominio From ya tiene reputación en otra IP, balanced o exponencial son aceptables.

Las cifras exactas de abajo corresponden a una rampa lineal cautious. Son deliberadamente conservadoras; la disciplina importa más que los números precisos. La única regla que rompe todo warmup: nunca duplique el volumen de ayer en la IP nueva antes de que la reputación esté establecida. Una vez que las tasas semanales de bounce + complaint están limpias durante una semana en el pico, la IP está "warm" y el warmup termina.

Al final de la semana 1 ya probó que puede enviar y que los destinatarios están enganchando. Al final de la semana 2 está en 10.000/día — un salto de un orden de magnitud desde el día uno. Es ahí cuando los thresholds de bulk sender en Gmail y Yahoo empiezan a aplicarse: por encima de ~5.000 mensajes/día hacia un mismo proveedor de buzones, la alineación DMARC, el unsubscribe de un clic y los techos de complaint rate pasan de aconsejables a exigidos. Si le falta cualquiera de esas precondiciones, la semana 2 es cuando aparece — no como un bloqueo sino como un desvío silencioso a la carpeta de spam.

La solución es aterrizar las tres precondiciones antes de que arranque el warmup:

• DMARC en p=quarantine; pct=100 como mínimo, idealmente p=reject, con los reportes RUA fluyendo.
• Unsubscribe de un clic vía las cabeceras List-Unsubscribe + List-Unsubscribe-Post (RFC 8058). AcelleMail las emite por defecto.
• Presupuesto de complaint rate — Amazon SES impone un techo duro de 0,1% en complaint rate. Quédese por debajo del 0,05% como margen de trabajo.

El comando de consola app/Console/Commands/WarmupListServers.php es el entry point del cron. Itera cada sending server activo con una estrategia adjunta y aplica el cap diario del day-of-strategy antes de permitir que cualquier campaña consuma el servidor. El cap vive en SendingServerWarmupUsage; el log de ejecución por día es SendingServerWarmupLog. La estrategia en sí soporta tres tipos de límite vía constantes en WarmupStrategy:

• LIMIT_TYPE_PER_DAY_CAP — "el presupuesto de envío de hoy es N, no más"
• LIMIT_TYPE_TARGET_VOLUME — "rampa hasta que N/día se sostenga y entonces márcalo como completo"
• LIMIT_TYPE_STOP_AFTER_DAYS — "rampa durante N días y entonces detente"

Para la mayoría de operadores la combinación correcta es GROWTH_STRATEGY_LINEAR + LIMIT_TYPE_TARGET_VOLUME: rampar linealmente hasta alcanzar el objetivo diario, luego desactivar el warmup y operar con normalidad. La estrategia se puede adjuntar a cualquier sending server — SES, Mailgun, SMTP genérico, custom — independientemente del driver subyacente.

Si está haciendo warmup contra Amazon SES (el pairing recomendado según /pricing), tres números del panel "Reputation metrics" de la consola SES importan durante la rampa:

• Bounce rate — AWS avisa al 5%, pausa al 10%. Usted debería estar bien por debajo del 2%.
• Complaint rate — AWS avisa al 0,1%, pausa al 0,5%. Quédese por debajo del 0,05% como margen de trabajo.
• Sending limit diario — SES lo crece automáticamente conforme se acumula su historial de envío. Si dejó de crecer, su rampa de warmup le está ganando al auto-grant.

Cada uno es por cuenta, no por IP, así que la métrica es una derivada de todos sus envíos en agregado. Si el número de bounce rate empieza a trepar durante la semana 2, baje el ritmo — no intente forzar el paso. El proveedor notó algo y el costo de investigar ahora es muchísimo menor que el costo de recuperarse después de una pausa.

Puede saltarse el warmup en dos situaciones, y solo dos:

1. Está usando SES con IPs compartidas (el default — las cuentas SES de producción comparten un pool de IPs gestionado). El pool está preaquecido; usted hereda su reputación. El warmup no es relevante a menos que pase a IPs dedicadas de SES.
2. Su dominio From existente ya tiene reputación construida en otra IP, y está migrando a la IP nueva. Igual hace warmup, pero en preset exponencial en vez de lineal cautious, porque la reputación del dominio From se traslada.

Para el resto — dominios nuevos, IPs dedicadas, instalaciones frescas de Postal MTA autohospedado — el warmup no es opcional. El tratamiento más largo con interpretación del dashboard SES día a día vive en /guide/email-deliverability §7.