SaaS hispanohablante escalando capacidad de email transaccional
SaaS con volumen creciente que recibe asignación adicional de IPs y necesita calentarlas para entrar en producción sin afectar el placement del bloque actual.
Deliverability gestionada · Calentamiento de IPs
Calentamiento de IPs managed con curva ajustada por placement medido en tiempo real
El calentamiento de IPs es el proceso de aumentar gradualmente el volumen de envío desde una IP nueva o reasignada para construir reputación con los receivers sin disparar filtros antispam, ajustando la curva por receiver y por día. OS Domains opera calentamiento gestionado para empresas hispanohablantes con MTA propio, con curva ajustada dinámicamente y monitorizada por un ingeniero, compatible con KumoMTA, PowerMTA, MailerQ y Postfix, y plazos definidos por tamaño de bloque, bajo entidad austriaca residente en la UE.
Calentamiento de IPs gestionado standalone para bloques /29 a /24 sobre tu propio MTA. La diferencia con calentar internamente es: el cronograma estático que la mayoría de equipos sigue (curva publicada por SendGrid o por blogs de deliverability) ignora la respuesta real de cada receiver. Nuestro proceso ajusta la curva dinámicamente según placement medido en Gmail Postmaster Tools, Microsoft SNDS, y feedback loops de Yahoo. Si Gmail acepta volumen rápido pero Outlook no, la curva acelera para Gmail y mantiene conservadora para Outlook hasta que la reputación se construye. Esa flexibilidad es lo que diferencia un calentamiento exitoso de un IP quemada en la primera semana.
En breve
- Calentamiento con curva ajustada dinámicamente por receiver y por sub-bloque, monitorizado por un ingeniero en lugar de un script estático.
- Tres packs (pago único): /29-/28 2.499 € (4 semanas), /27 4.999 € (6 semanas, el más contratado) y /26-/24 a medida (8-12 semanas, secuencial por sub-bloques).
- Compatible con tu MTA propio: KumoMTA, PowerMTA, MailerQ y Postfix, con setup inicial de SPF, DKIM, DMARC y rDNS incluido.
- Coordinación con Gmail Postmaster y Microsoft cuando aplica, con documento final de métricas y 30 a 90 días de soporte post-engagement.
- Plazo definido y documentación auditable para procurement, bajo entidad austriaca residente en la UE.
Qué resuelve este producto
Para empresa hispanohablante con MTA propio que necesita escalar IPs sin quemarlas
El calentamiento de IPs nuevas es trabajo operacional altamente técnico que la mayoría de equipos subestima. La curva de envío estática que circula en blogs de deliverability (50 emails día 1, 100 día 2, 200 día 3, doblando cada 2 días hasta volumen objetivo) es punto de partida razonable pero ignora variables críticas: respuesta del receiver específico, calidad de la lista, alineamiento DMARC, autenticación SPF/DKIM, y comportamiento de la audiencia. Equipos que siguen la curva estática sin ajustar al feedback real terminan con uno de dos resultados: IP quemada en semana 2 por sobrepasar la velocidad real que el receiver tolera, o calentamiento que tarda 3 a 4 meses cuando podría haber tardado 4 a 6 semanas.
El servicio gestionado resuelve esa fricción específica. El proceso interno: ingeniero de deliverability monitorea Gmail Postmaster Tools, Microsoft SNDS, complaint rate del feedback loop de Yahoo y métricas de tu MTA durante el calentamiento. Cada 24 a 48 horas ajusta la curva según los datos: acelera para receivers que muestran reputación creciente, mantiene conservadora para receivers con resistencia, identifica receivers regionales (Free.fr, GMX, Strato) que necesitan tratamiento específico. La curva ajustada típicamente reduce el tiempo total de calentamiento en 30 a 50% respecto a curva estática, y reduce el riesgo de IP quemada cerca de cero cuando el contenido y la lista son legítimos.
Sobre los tamaños de bloque que cubrimos. /29 (8 IPs) es el tamaño mínimo donde el calentamiento gestionado tiene sentido económico, típicamente para SaaS escalando capacidad transaccional. /28 (16 IPs) es común para operación de cold email B2B con varios clientes. /27 (32 IPs) es operación más madura. /26 (64 IPs) y /24 (256 IPs) son operaciones de gran escala (ESPs, agencias grandes, empresas con alto volumen transaccional). El proceso es el mismo para todos los tamaños pero el plazo total escala con el número de IPs (más IPs = más días de calentamiento porque cada IP necesita su propia curva controlada para no saturar la respuesta del receiver).
La audiencia hispanohablante donde el producto entrega valor mensurable son SaaS o ESPs con MTA propio (KumoMTA, PowerMTA, MailerQ, Postfix con configuración avanzada) que reciben asignación de IPs nuevas y necesitan calentarlas. Casos típicos: SaaS escalando volumen donde la asignación actual quedó pequeña, ESP recibiendo bloque adicional del RIR para crecer capacidad, agencia de cold email recibiendo bloque dedicado para cliente nuevo, empresa post-incidente que necesita IPs nuevas porque las anteriores quedaron irreparablemente quemadas. Para clientes que no tienen MTA propio sino que usan ESP estandarizado (SendGrid, Mailgun), el calentamiento es responsabilidad del ESP y este producto no aplica.
Sobre el lado tributario, factura desde Viena en EUR con número de IVA intracomunitario austríaco. Para empresa española mecanismo de inversión del sujeto pasivo. Para empresa LATAM, tributación local de importación de servicios digitales según jurisdicción. La carga total efectiva queda entre 16% y 30% sobre el valor de la factura.
El producto es one-time, no recurrente, lo que diferencia del DMARC gestionado o del Monitoreo de deliverability. La factura es por engagement con plazo definido (4 a 8 semanas según tamaño del bloque) y entregable específico (documento final de calentamiento con métricas, IPs en estado operacional con placement validado).
Sobre el contexto específico del calentamiento de IPs en mercado hispanohablante hay dos observaciones operacionales relevantes. Primero: receivers regionales hispanos (Movistar/Telefónica, Vodafone, ONO) tienen sistemas de reputación menos documentados públicamente que Gmail/Microsoft, lo que hace el calentamiento más empírico. La curva ajustada con base en placement medido vía cuentas seed propias en cada receiver hispano es la única forma confiable de saber si el progreso está siendo aceptable. Segundo: empresas hispanas con audiencia internacional (UE + LATAM mezclado) tienen el desafío adicional de calentar IPs para perfiles de receiver que se comportan distinto: el calentamiento óptimo para Gmail consumer en EE.UU. es distinto del óptimo para Movistar en España.
Sobre la decisión técnica de cuándo calentar versus cuándo reemplazar IPs. A veces el equipo del cliente llega con problema de placement asumiendo que necesita calentamiento, cuando en realidad la IP está dañada irrecuperablemente y el calentamiento no va a funcionar. La diagnostic call inicial cubre esto: si la IP tiene listing histórico persistente en Spamhaus SBL o XBL, si Gmail Postmaster muestra reputación bad sostenida durante semanas, si el rDNS está mal configurado y nadie puede arreglar, el calentamiento no es la respuesta correcta y recomendamos honestamente reemplazo de IPs como camino más eficiente. Cerca del 20% de las consultas de calentamiento terminan con esa recomendación.
Sobre la observación específica del mercado hispanohablante 2024-2025 sobre calentamiento DIY que falló. Varias empresas hispanas con equipo técnico capable intentaron calentar internamente IPs de bloques nuevos siguiendo curva estática publicada por SendGrid o blogs de deliverability. Los casos de fallo fueron consistentes: equipos siguieron la curva sin ajustar al feedback del receiver, ignoraron señales tempranas de problema porque no sabían interpretarlas, escalaron volumen demasiado rápido cuando los primeros días parecían bien, terminaron con IPs en placement bajo permanente que no recuperaron sin intervención profesional. El patrón vale como advertencia: la curva estática es punto de partida pero no es suficiente; el ajuste dinámico requiere experiencia que el equipo interno tipicamente no tiene si el calentamiento es trabajo ocasional, no rutinario.
Sobre el cálculo de cuándo calentamiento gestionado paga vs autogestión. Calentar internamente un /29 (8 IPs) requiere 30-50 horas de ingeniero senior por IP distribuidas en 4 semanas, lo que suma 240-400 horas para el bloque completo. A coste fully-loaded de €60-€100 por hora en mercado europeo, el coste interno es €14.400-€40.000. Nuestro Pack /29-/28 a €2.499 sale 5-15x más barato y entrega resultado profesional con tiempo del cliente liberado para producto. Para empresa que calienta IPs ocasionalmente (1-2 veces al año), gestionado es claramente mejor. Para empresa que calienta IPs continuamente como parte del producto (típico ESP regional), construir capability interna puede tener sentido a partir de cierto volumen, pero mientras tanto el gestionado cubre el período de transición.
Sobre la observación específica del mercado europeo de calentamiento de IPs durante 2024-2025. La industria del cold email B2B europeo con audiencia internacional creció sustancialmente, lo que disparó demanda de calentamiento profesional para bloques /28 y /29 dedicados que las agencias adquieren para clientes finales. La oferta del mercado se polarizó: por un lado proveedores que automatizan calentamiento con curva estática (más baratos pero con tasa de fallo significativa), por otro proveedores con calentamiento gestionado profesional (más caros pero con tasa de éxito alta). Nuestro encaje específico es el segmento profesional con experiencia operacional desde 2008 sobre infraestructura propia.
Sobre la observación específica de receivers regionales hispanos durante 2024-2025 que afecta la estrategia de calentamiento. Movistar/Telefónica tiene infraestructura propia de email en España que afecta significativamente placement de campañas dirigidas a clientes Movistar. Vodafone/ONO opera infraestructura similar con políticas distintas. Free.fr en Francia tiene políticas de greylisting agresivas hacia IPs nuevas que persisten varias semanas más allá del calentamiento estándar. GMX y web.de en Alemania favorecen IPs con buena presencia de red europea y penalizan las que enrutan vía tránsito comercial barato. Mail.ru en países bajos rusos europeos tiene sistema de reputación opaco que requiere validación con cuentas seed propias. Cada uno requiere ajuste específico durante el calentamiento que productos automatizados con curva estática no consiguen aplicar.
Sobre el análisis específico de coste de fallar el calentamiento. Una IP /32 quemada durante el calentamiento (placement consistente bajo 50% en Gmail Postmaster Tools post-período de warming) tiene dos opciones: invertir 4-8 semanas adicionales en remediación con resultados inciertos (típicamente recuperación parcial al 70-80% del placement objetivo), o reemplazar la IP por una limpia y reiniciar el calentamiento (4 semanas adicionales con coste de oportunidad). Para empresa con producción dependiendo de la IP, la pérdida acumulada puede ser de €20,000-€50,000 según volumen y conversión. El coste del calentamiento gestionado profesional (€2,499 para Pack /29) se paga fácilmente con evitar un solo caso de IP quemada.
Sobre el patrón específico de cliente que viene de operación con AWS SES y se mueve hacia bloque IP dedicado propio en MTA self-hosted. Caso típico: cliente con volumen 5M+ al mes en SES descubre que el coste por email se vuelve desproporcionado vs el control técnico que ofrece, decide migrar a MTA propio (KumoMTA o PowerMTA) con bloque IP dedicado de RIPE. El bloque nuevo necesita calentamiento profesional antes de entrar en producción. Sin calentamiento, las primeras campañas reciben placement bajo (las IPs nuevas sin reputación tienen penalty inicial significativo), lo que arruina la experiencia del cliente final. El servicio de calentamiento gestionado nuestro cubre exactamente este caso, con coordinación entre el equipo de migración y el equipo de calentamiento si el cliente contrata Migración como engagement paralelo.
Sobre el caso específico de cliente que llega con bloque IP nuevo recién asignado por RIR donde el histórico previo es desconocido. Patrón común: empresa con crecimiento de volumen necesita más IPs y solicita asignación adicional de RIPE (para europeas) o ARIN (para US-based). El RIR asigna bloque /28 o /27 pero el bloque puede tener histórico de uso previo no documentado (asignaciones anteriores reciclan bloques tras devolución). Antes del calentamiento validamos el histórico del bloque contra Spamhaus DROP y EDROP, base de datos de blacklists históricas, MultiRBL.valli, archivos públicos de DNSBL. Si encontramos histórico problemático en alguna IP del bloque (típico: la IP fue parte de bloque cloud público con uso compartido, o asignada anteriormente a empresa que cerró sin limpiar), recomendamos al cliente solicitar bloque distinto al RIR antes de invertir el calentamiento, lo que ahorra al cliente plazo y coste de calentar IPs ya quemadas.
Sobre la observación específica del costo escondido del calentamiento mal hecho que muchas empresas no calculan al optar por DIY. Una IP /32 quemada durante calentamiento DIY (placement consistente bajo 50% post-warming) genera tres componentes de costo. Primero: el coste directo del tiempo de ingeniero invertido en el calentamiento fallido, típicamente 30-50 horas por IP que a coste fully-loaded de €60-€100 representa €1,800-€5,000 por IP perdida. Segundo: el coste de oportunidad del cliente final que esperaba placement estable y recibe placement degradado durante el período de remediación posterior, típicamente €5,000-€20,000 según volumen y conversión. Tercero: el coste de reemplazo (IP nueva, calentamiento reiniciado, plazo adicional de 4-6 semanas) que puede sumar otro €2,000-€4,000 por IP. Para el patrón frecuente de calentar 8 IPs (/29) con 2-3 IPs quemadas en proceso, el coste total esperado del DIY supera fácilmente los €15,000-€40,000 vs €2,499 del producto profesional con tasa de éxito documentada del 95%+ en bloques limpios.
Sobre la documentación específica que entregamos al cierre del engagement para preservar el conocimiento operacional adquirido. Documento final firmado por ingeniero responsable incluye: curva ejecutada por IP día a día, métricas observadas en Postmaster Tools y SNDS, decisiones de ajuste y razón de cada uno, comparación final vs baseline pre-warming, hallazgos sobre el pool específico del cliente que pueden afectar futuras IPs adicionales, recomendaciones para el cliente sobre operación continua post-warming. Este documento es propiedad del cliente al cierre del engagement y queda disponible para que el equipo del cliente pueda replicar el proceso internamente para futuras IPs sin tener que recontratar el servicio.
Sobre la observación específica durante 2025-2026 del impacto de la consolidación del mercado de cold email B2B en estrategia de calentamiento. La consolidación: muchas agencias pequeñas cerraron o se fusionaron con consolidadas mayores, lo que generó migración de portafolios de clientes finales con IPs heredadas. Las IPs heredadas tienen histórico mixto: algunas con calentamiento profesional sostenido, otras con uso descuidado del proveedor anterior, otras con histórico de incidentes. Cuando una agencia consolidada hereda IPs de agencia adquirida, el calentamiento profesional aplicado al portafolio nuevo identifica qué IPs son rescatables y cuáles requieren reemplazo. Este trabajo de evaluación + remediación es scope específico que cubrimos como engagement combinado de auditoría + warming.
Sobre el caso específico de calentamiento por etapas en operación con plazo flexible. Cliente que no tiene presión de plazo cerrado puede optar por calentamiento por etapas: primera etapa cubre las 4-6 IPs principales que el cliente usa más, segunda etapa (semanas después) cubre las IPs adicionales, tercera etapa (meses después) cubre IPs de reserva. La estrategia escalonada distribuye el coste durante varios meses, lo que ayuda a clientes con presupuesto trimestral cerrado. La calidad del resultado es idéntica al calentamiento simultáneo de todas las IPs, solo cambia el plazo de ejecución.
Escenarios donde encajamos
¿En qué cinco situaciones el calentamiento gestionado marca la diferencia?
Abajo, los perfiles donde el ajuste dinámico de la curva supera al cronograma estático.
ESP o agencia recibiendo bloque dedicado para cliente nuevo
ESP o agencia que recibe asignación de bloque /29 a /24 dedicado para cliente final con volumen alto. El cliente final espera placement productivo desde el día 1 de operación, lo que requiere calentamiento profesional anterior.
Empresa post-incidente con IPs irreparablemente quemadas
Empresa que sufrió incidente de reputación severo (listing persistente en Spamhaus, complaint spike masivo) y prefirió obtener IPs nuevas en lugar de invertir en recuperación de las antiguas. Necesita calentamiento profesional sobre el bloque nuevo para prevenir reincidencia.
Cliente migrando de ESP estandarizado a MTA propio
Cliente que migra de SendGrid o Mailgun a infraestructura propia con KumoMTA o PowerMTA. Las IPs del MTA propio son nuevas y necesitan calentamiento desde cero. El servicio gestionado entrega arranque profesional sin desperdiciar 2-3 meses internamente.
Operación con receivers regionales europeos exigentes
Operación con audiencia europea concentrada (Free.fr, GMX, Strato, Mail.ru) donde estos receivers regionales tienen filtros de greylisting agresivos sobre IPs nuevas. La curva ajustada por receiver entrega placement aceptable más rápido que curva genérica.
Bloque IP nuevo asignado por RIR donde la documentación previa es incierta
Empresa que recibe asignación adicional de IPs del RIR (RIPE para europeas, ARIN para US-based) donde el histórico previo del bloque es incierto. Antes de calentar, validamos histórico del bloque contra blacklists históricas y bases de datos de reputación; si encontramos histórico problemático, el calentamiento se ajusta o recomendamos solicitar bloque distinto al RIR antes de invertir el calentamiento.
Operación expandiéndose a nuevos receivers regionales por crecimiento geográfico
Empresa que históricamente envió principalmente a Gmail y Outlook 365 y ahora expande hacia receivers regionales (Yahoo Japan, NTT, Naver, GMX, Strato, Free.fr) que no tenía cubiertos en el calentamiento original. El calentamiento adicional dirigido a esos receivers específicos toma 2-4 semanas y construye reputación con receivers que el calentamiento original no incluía.
Configuración multi-PoP donde IPs distintas necesitan calentamiento coordinado
Cliente con setup multi-PoP donde distintas IPs envían desde distintas ubicaciones geográficas (típico Frankfurt para audiencia europea, Dallas para audiencia US-East). Las IPs de cada PoP necesitan calentamiento individual con curvas que respetan las particularidades del peering BGP de cada exchange. Coordinamos los calentamientos en paralelo con plazos alineados.
Cómo funciona el proceso
Calentamiento con ajuste dinámico monitorizado por ingeniero
El proceso es híbrido: software de orquestación que coordina volumen y tiempos, ingeniero humano interpretando datos y ajustando curva.
Setup inicial y baseline de receivers
Validación de SPF, DKIM, DMARC, rDNS por IP del bloque. Configuración inicial de Gmail Postmaster Tools y Microsoft SNDS con cuentas de validación. Baseline de Spamhaus, Spamcop, Barracuda para confirmar que las IPs vienen limpias. Setup completo en 24 a 48 horas.
Inicio del calentamiento con curva conservadora
Día 1 a 7: 50 a 100 emails diarios por IP a inboxes seed con engagement controlado. Día 8 a 14: aceleración gradual a 500 a 1.000 emails diarios por IP según respuesta del receiver. La curva conservadora protege la primera fase donde la reputación se construye desde cero.
Aceleración ajustada por placement medido
Aceleración gradual conforme placement valida buena reputación. Volumen típico va de 1.000 emails diarios en día 14 a 5.000 al día en día 21, con curva ajustada por receiver. Para Gmail y Outlook 365, aceleración más rápida porque receivers responden bien a IP nueva limpia. Para Yahoo y proveedores regionales, aceleración más lenta porque sistema de reputación tiene más inercia. Ajustes diarios conforme métricas evolucionan.
Plateau de validación y ajuste fino
Día 22 a 28: plateau en volumen objetivo del cliente (típicamente 5.000 a 50.000 emails diarios por IP según perfil). Validación final de placement consistente por receiver. Identificación de receivers regionales donde la reputación todavía no es completa (típicamente algunos europeos secundarios) y plan de continuación post-engagement.
Documento final con métricas y handoff
Al cierre del engagement: documento de 15 a 25 páginas con curva ejecutada por IP, métricas de placement por receiver, complaint rate observado, recomendaciones para mantener reputación. IPs en estado operacional listas para operación normal del cliente. Período de soporte adicional de 30 días incluido para resolver incidents de transición.
Para bloques mayores (/26 a /24)
Bloques /26 (64 IPs) y /24 (256 IPs) requieren calentamiento secuencial por sub-bloques en lugar de calentar todas las IPs simultáneamente. La razón: receivers tratan calentamiento simultáneo de muchas IPs como señal sospechosa (spammer rotando IPs). Calentamiento secuencial en sub-bloques /29 con días de offset preserva la apariencia de operador legítimo escalando gradualmente.
Coordinación con sub-procesadores y herramientas del cliente
Durante el calentamiento coordinamos con los sub-procesadores ESP del cliente cuando aplica: AWS SES para clientes que mantienen IPs SES en paralelo durante migración, Mailgun y SendGrid para clientes con setup híbrido. La coordinación incluye configuración de DKIM con autoridad correcta, ajuste de políticas SPF para evitar superar el límite de 10 lookups, configuración de routing entre el MTA del cliente y los sub-procesadores. Para herramientas de sequence (Smartlead, Instantly, Apollo), validamos integración antes de iniciar el calentamiento.
Validación pre-cierre con tráfico real del cliente
Última semana del engagement: tráfico real del cliente sustituye gradualmente el tráfico de calentamiento controlado. Volumen del 30% al 60% al 80% al 100% durante esa semana, con monitoreo intensivo de placement. Si el placement con tráfico real cae por debajo del baseline establecido durante calentamiento, identificamos la causa (típicamente diferencia entre engagement controlado del calentamiento y engagement real del cliente) y ajustamos antes de cierre formal del engagement.
Packs y precios
Pricing por tamaño de bloque, plazo definido
Precio one-time por engagement. Plazo del engagement varía según tamaño del bloque: 4 semanas para /29 y /28, 6 semanas para /27, 8 semanas para /26, 10-12 semanas para /24. Incluye soporte 30 días post-engagement.
Pack /29-/28
Para bloques /29 (8 IPs) o /28 (16 IPs).
€2.499 one-time
Ideal para
SaaS o ESP escalando capacidad con bloque pequeño, primera asignación adicional.
- Calentamiento completo /29 o /28 (4 semanas)
- Setup técnico inicial (SPF, DKIM, DMARC, rDNS)
- Curva ajustada por receiver
- Monitoreo continuo durante el engagement
- Documento final con métricas detalladas
- Soporte 30 días post-engagement
- Compatible con KumoMTA, PowerMTA, MailerQ, Postfix
Pack /27
Para bloque /27 (32 IPs).
€4.999 one-time
Ideal para
ESP o agencia con bloque dedicado para cliente final, operación de cold email B2B con varios clientes.
- Calentamiento completo /27 (6 semanas)
- Setup técnico inicial completo
- Curva ajustada por sub-bloque /29
- Monitoreo intensivo con ingeniero asignado
- Documento final extendido
- Soporte 60 días post-engagement
- Plan de mantenimiento opcional adicional
Pack /26-/24
Para bloques /26 (64 IPs) hasta /24 (256 IPs).
Custom
Ideal para
Operación enterprise con asignación grande, ESP grande, empresa con compliance específico.
- Calentamiento secuencial por sub-bloques (8-12 semanas)
- Ingeniero de deliverability dedicado durante engagement
- Coordinación con receivers (Gmail Postmaster, Microsoft) cuando aplica
- Reportes ejecutivos semanales
- Soporte 90 días post-engagement
- Documentación auditable para procurement
- Continuación opcional al monitoreo recurrente con descuento
Precios one-time antes de IVA. Pago anticipado al inicio del engagement. Para empresa española IVA al 21% mediante inversión del sujeto pasivo. Engagements simultáneos para varios bloques con descuento del 15% sobre el segundo y posteriores.
Preguntas frecuentes
¿Qué preguntan los equipos técnicos?
¿Por qué no usar la curva estática que SendGrid publica?
La curva estática es punto de partida razonable pero ignora variables críticas. Si tu lista tiene engagement alto, puedes acelerar más rápido que la curva estática indica. Si tu contenido tiene patrones de spam-score moderado, deberías ralentizar. Si tu audiencia está concentrada en receivers específicos (Yahoo, Outlook 365 corporativo), necesitas optimizar para esos. La curva ajustada dinámicamente reduce el tiempo total y el riesgo de IP quemada porque responde a la realidad del calentamiento, no al cronograma teórico.
¿Es compatible con KumoMTA, PowerMTA, MailerQ, Postfix?
Sí, los cuatro. Para KumoMTA y PowerMTA, integramos directamente con las APIs administrativas para coordinar el calentamiento (volumen, throughput, IP rotation). Para MailerQ con backend RabbitMQ, coordinamos con tu equipo el control del flujo de mensajes. Para Postfix, configuramos transport_maps y rate limits manualmente. Para AWS SES con configuration sets, coordinamos vía la configuración de IP pools que provisionas para el período de calentamiento. Otros MTAs no estándar bajo cotización.
¿Qué tasa de éxito tienen estos calentamientos?
Sobre 200 plus engagements completados en 2024-2025: 97% terminó con IPs en estado operacional con placement consistente al objetivo del cliente. El 3% que no llegó al objetivo planteado se debió a factores externos al calentamiento (lista de cliente con problemas de calidad descubiertos durante el engagement, contenido del cliente con patrones de spam-score que el receiver detecta, problema de autenticación que requirió cambios fuera del scope del engagement). En esos casos, documentamos los hallazgos y el cliente decidió continuar con plan de mantenimiento o pausar.
¿Cómo se compara con calentar internamente?
Calentar internamente requiere 30 a 50 horas de ingeniero senior de deliverability por IP, distribuidas en 4 semanas. Para un /29 (8 IPs) son 240 a 400 horas, que a coste fully-loaded de €60 a €100 por hora son €14.400 a €40.000. Nuestro Pack /29-/28 a €2.499 sale sustancialmente más barato y entrega resultados profesionales con tiempo del cliente liberado. Para empresa con equipo de deliverability senior interno y tiempo disponible, calentar internamente puede ser mejor económicamente; para empresa sin ese equipo o sin tiempo, el servicio gestionado es la opción.
¿Pueden calentar IPs en cualquier región del mundo?
Sí. La región de las IPs no es factor crítico para el proceso (los receivers son los mismos globalmente: Gmail, Microsoft, Yahoo, etc.). Calentamos IPs en EE.UU., UE, LATAM, APAC sin problema. Lo que sí varía con la región es la audiencia: IPs en LATAM tienden a tener mejor placement con audiencia LATAM que con audiencia europea, por temas de routing BGP. Lo discutimos en la llamada inicial.
¿Y si una IP del bloque resulta tener histórico oculto?
En el setup inicial verificamos contra Spamhaus, Spamcop, Barracuda, SORBS y otras blacklists relevantes para confirmar que las IPs vienen limpias. Si descubrimos que una IP tiene histórico oculto que no aparece en blacklists pero sí en sistemas de reputación de receivers (típicamente detectado en Gmail Postmaster Tools en los primeros 7 días), iniciamos delisting y proceso de remediación. Si la IP es irrecuperable, coordinamos con tu RIR para reemplazo. Es escenario raro pero ocurre, y la política es hacer lo correcto (no continuar calentando una IP irrecuperable).
¿Cuál es el siguiente paso?
Llamada técnica de 30 minutos: tamaño del bloque, MTA en uso, audiencia objetivo, plazo deseado, contexto del calentamiento (escalado, post-incidente, migración). Salida es propuesta concreta con plazo y coste, o recomendación honesta si tu caso encaja mejor con otro proveedor o con calentamiento interno.
¿Pueden calentar IPs simultáneamente con campañas de producción activas en el mismo bloque?
Limitado. Si las IPs están segregadas (la IP a calentar está separada del bloque de producción, sin tráfico cruzado del lado del MTA), sí. Si están en el mismo virtual MTA con tráfico mezclado, no recomendamos porque la curva controlada se contamina con el tráfico de producción no controlado. Para clientes con MTA bien configurado con virtual MTAs separados, el calentamiento paralelo es viable; para clientes con configuración monolítica, recomendamos primero segregar.
¿Qué pasa con receivers que no exponen Postmaster Tools?
Calentamiento ciego con cuentas seed. Para receivers como Yahoo, AOL, ProtonMail, Free.fr, GMX, Strato, Movistar, Vodafone (y la mayoría de receivers regionales) el feedback público es limitado o inexistente. Mantenemos red de cuentas seed propias en estos receivers que validan placement durante el calentamiento. El feedback es menos granular que Gmail Postmaster (no vemos métricas detalladas, solo placement final inbox/spam) pero suficiente para guiar la curva.
¿Calentamiento es necesario también para IPv6?
Sí, separado del IPv4. Receivers tratan IPv4 e IPv6 reputación independientemente. Una IP IPv6 nueva necesita su propia curva de calentamiento aunque la IPv4 paralela ya esté calentada. La diferencia operacional: IPv6 reputation tiene menos receivers maduros que IPv4 (Gmail, Microsoft tienen IPv6 nativo pero muchos receivers regionales todavía operan IPv4 primario), lo que hace el calentamiento IPv6 más rápido en algunos casos pero menos validado en otros. Lo discutimos en setup.
¿Cuánto volumen máximo se puede alcanzar al final del calentamiento?
Depende del tamaño del bloque, perfil de envío, y receiver. Por IP individual /32 calentada limpiamente: típicamente 50.000-100.000 emails diarios sostenidos a Gmail/Microsoft sin penalización. Receivers regionales: 10.000-30.000 al día por IP. Por encima de esos volúmenes la IP entra en zona de throttling agresivo que requiere coordinación con el receiver. Para clientes que necesitan volumen muy alto (millón plus al día), la respuesta es más IPs en lugar de más volumen por IP, lo que cubre el producto Cold Email Infrastructure o Sending Servers.
¿La curva ajustada se documenta para auditoría posterior?
Sí. Cada engagement entrega documento final con curva ejecutada por IP día a día, métricas observadas en Postmaster Tools, decisiones de ajuste y razón de cada uno, comparación final vs baseline pre-warming. La documentación es útil para clientes con auditoría regulatoria que exige evidencia de proceso técnico documentado. También es útil cuando el cliente quiere replicar la curva internamente para futuros bloques sin contratar nuestro servicio (la curva ajustada es la propiedad intelectual operacional, no es secret sauce, la compartimos con el cliente al cierre del engagement).
¿Pueden calentar IPs en cloud público (AWS, GCP, Azure) si las contratamos directamente?
Sí, con observaciones. Calentar IPs de AWS SES configuration sets, GCP send-as servers, o Azure Communication Services es viable y lo hemos hecho varias veces. La diferencia con calentar IPs nuestras: las IPs cloud público vienen con histórico del proveedor (típicamente neutral pero a veces contaminado por uso anterior por otros tenants), el cliente mantiene relación contractual con el cloud provider sobre las IPs (nosotros no tenemos control directo), la cobertura de monitoreo es vía herramientas del cliente porque no operamos las IPs. Plazo similar de 4 semanas, coste igual al pack equivalente.
¿Si después del calentamiento los receivers regionales todavía no muestran placement aceptable?
Caso ocasional. Algunos receivers regionales tienen políticas de aceptación más estrictas que requieren tiempo adicional o coordinación específica. Para los principales hispanos: Movistar Spain a veces requiere 4-6 semanas adicionales de tráfico regular post-calentamiento para alcanzar placement consistente. Vodafone similarmente. Free.fr en Francia requiere validación específica del peering del PoP origen. Lo discutimos en cierre del engagement con plan de monitoreo continuo durante el período post-warming si el cliente lo requiere.
¿Pueden ejecutar calentamiento sobre infraestructura del cliente sin que migre a nuestra?
Sí, parte del scope estándar. La mayoría de los engagements de calentamiento son sobre infraestructura existente del cliente (MTA propio, IPs propias, dominios propios). Operamos remotamente vía acceso de solo lectura a logs y métricas del MTA del cliente, coordinación de cambios que el cliente aplica bajo nuestra guía, validación con cuentas seed nuestras independientes del setup del cliente. No requiere migración. Para clientes que después del calentamiento deciden migrar a nuestra infraestructura, descontamos el coste del warming del precio de migración.
Si llegaste hasta aquí
Próximo paso: 30 minutos para validar encaje y plazo
Discutimos tu setup actual, tamaño del bloque, plazo. Identificamos si el servicio gestionado encaja, o si interna recomendamos otro camino.
Oficina Fleischmarkt 1, 1010 Wien Con cita previa