La migración de email es la operación que con mayor probabilidad destruye en silencio la reputación de un sender si se hace mal, y la que con mayor probabilidad se hace mal porque las partes visibles (actualizar DNS, cambiar configuración de la app) son engañosamente simples. Las partes invisibles, calentamiento de IP, transición de autenticación, continuidad del manejo de rebotes, preservación de la higiene de lista, son donde las migraciones se ganan o se pierden.
Hemos liderado más de 50 migraciones en los últimos dos años entre SendGrid, Mailgun, Postmark, Mandrill (última oleada), AWS SES y algún MTA on-premise legacy hacia destinos europeos e hispanos (Mailrelay, Acumbamail, Brevo, OS Domains). Los patrones de abajo son realidad observada, no teoría. Si planificas una migración en 2026 con foco en mercado español o LATAM, este es el playbook.
Qué significa “perder reputación” en realidad
Antes del playbook, los modos de fallo. La pérdida de reputación durante la migración aparece de tres formas distintas.
Tipo 1: pérdida de reputación de IP. Las IPs nuevas del proveedor nuevo no tienen reputación. Si haces el cutover a volumen completo, los receivers ven una ráfaga súbita desde una IP desconocida y la tratan como sospechosa. El placement en inbox cae 20-40% en los primeros 7 días. La recuperación es posible vía calentamiento pero tarda 4-8 semanas.
Tipo 2: pérdida de reputación de dominio. Los receivers siguen reputación por combinación (dominio × IP). Cuando tu dominio empieza a enviar desde IPs nuevas, el sistema de reputación del receiver necesita reestablecer confianza. Esto es más rápido que el calentamiento puro de IP (el dominio tiene historia) pero todavía toma 1-2 semanas de operación cuidadosa.
Tipo 3: pérdida de señales de engagement. Esta es la que la mayoría se pierde. El proveedor antiguo tenía categorización de rebotes ajustada a feedback que informaba tu lógica de supresión, política de reintento y manejo de quejas. El proveedor nuevo tiene categorización distinta. Si tu lógica de supresión estaba ajustada a categorías del proveedor antiguo, puedes empezar súbitamente a enviar a direcciones que deberías haber suprimido, la tasa de queja sube, la reputación cae rápido.
Una buena migración previene los tres. Una migración mala previene uno y se sorprende con los otros dos.
La decisión fundamental: puente o quemar
Funcionan dos patrones; todo lo demás es riesgo.
Patrón A: migración puente (recomendada para la mayoría)
Correr proveedor antiguo y nuevo en paralelo durante 4-6 semanas. El proveedor nuevo toma 10% → 25% → 50% → 75% → 100% sobre el período. El proveedor antiguo desciende inversamente. En cualquier momento durante la migración puedes hacer rollback si las señales se ponen feas.
Esto es más caro a corto plazo (pagas ambos proveedores) pero el perfil de riesgo es radicalmente mejor. Usamos este patrón para el 90% de migraciones de cliente.
Patrón B: migración por quemado (solo para cutovers forzados)
Cutover duro en momento planificado. El proveedor nuevo toma 100% en día 1, el antiguo se detiene. Solo se usa cuando:
- El proveedor antiguo está cerrando (Mandrill 2016 fue el caso canónico)
- El coste de operación paralela es genuinamente prohibitivo
- El proveedor nuevo tiene calentamiento de IP completado antes del cutover
- El equipo aceptó que 1-3 semanas de placement degradado es aceptable
Es más rápido pero más arriesgado. Lo hacemos ocasionalmente; siempre documentamos la aceptación de riesgo por escrito antes.
El playbook de migración puente de 6 semanas
Este es el cronograma que usamos para una migración mid-market típica: SendGrid (EE.UU.) → Mailrelay (España) o OS Domains (Austria), 1M de volumen mensual, canal único de envío.
Semana 0: evaluación y preparación
Auditar estado actual en proveedor antiguo:
- Dominios de envío y selectores DKIM
- IPs dedicadas (si las hay) y su histórico de calentamiento
- Lista de supresión (descargada vía API, limpiada)
- Integración de reportes de bounce/queja
- Integraciones webhook y consumidores de eventos
Configurar proveedor nuevo:
- Provisioning de cuenta, acuerdo sub-procesador firmado
- Selector(es) DKIM nuevo(s) configurados con alineamiento apropiado
- Bloque de IPs nuevo calentado y listo (engagement separado normalmente solapado con semanas 1-4)
- Endpoints webhook probados
Preparación DNS:
- Añadir registro DKIM nuevo sin remover el antiguo
- Actualizar SPF para incluir IPs del nuevo proveedor (junto al antiguo)
- DMARC revisado; alineamiento relajado para ambos proveedores durante la transición
Semana 1: arranque paralelo al 10%
Cambio en el lado de la aplicación: enrutar el 10% del tráfico saliente al proveedor nuevo, el 90% sigue al antiguo.
El 10% se selecciona por receiver, no por muestreo aleatorio. Empezar con los receivers más tolerantes a remitentes nuevos (típicamente Microsoft 365 con dominio corporativo, Yandex, ProtonMail). Gmail y Yahoo entran en semana 2 o 3.
Monitorear:
- Tasa de bounce en proveedor nuevo (objetivo: similar al antiguo)
- Tasa de queja en proveedor nuevo (objetivo: similar al antiguo)
- Placement vía seed testing
- Errores nivel aplicación (la integración puede sacar a la luz bugs no vistos en testing)
Si algo se ve raro, pausa e investiga antes de incrementar.
Semana 2: 25%
Subir al 25%. Para esta semana Gmail y Yahoo están recibiendo volumen significativo desde tus IPs nuevas. Los sistemas de reputación del receiver tienen 7+ días de señales limpias con las que trabajar.
Atención a divergencia entre rendimiento del proveedor antiguo y el nuevo. Si muestran patrones similares, vas en buen camino. Si el nuevo se queda muy atrás, profundiza en placement por receiver para identificar cuál es el rezagado.
Semana 3: 50%
Punto medio. El proveedor nuevo está manejando volumen suficiente para que los sistemas de reputación del receiver tengan reputación (provisional) establecida para las IPs nuevas. El antiguo está cargando la otra mitad.
Esta es la semana donde con mayor frecuencia afloran sorpresas. La aplicación se ejercita contra ambos proveedores en medida aproximadamente igual, lo que significa que cualquier bug en la integración del proveedor nuevo aparecerá si todavía no lo había hecho. Las discrepancias en lista de supresión se vuelven visibles. Los problemas de colisión de message-id (si tu aplicación usa IDs específicos de proveedor en algún sitio) se hacen evidentes.
Semana 4: 75%
Tirar más volumen al proveedor nuevo. El antiguo está ahora en modo desescalado.
Importante: no apresurar. Los receivers están vigilando cambios súbitos de volumen, tanto subidas en el proveedor nuevo como bajadas en el antiguo. Una transición gradual se observa como “variación normal de patrón de envío”; un cambio súbito parece compromiso de cuenta.
Semana 5-6: 100% y luego estabilización
Para finales de semana 5, enrutar el 100% del nuevo saliente al proveedor nuevo. El antiguo queda completamente pasivo (todavía configurado para rollback, sin envío nuevo).
La semana 6 es estabilización a volumen completo. Cualquier problema restante aflora aquí. Para finales de semana 6 deberías estar corriendo limpiamente a capacidad completa en el proveedor nuevo con reputación que iguala o supera al setup antiguo.
Semanas 8-10: descomisión del proveedor antiguo
Esperar 30 días desde el final del cutover antes de apagar la cuenta del proveedor antiguo. El colchón cubre:
- Bounces de mensajes entregados tarde (especialmente secuencias transaccionales mensuales)
- Solicitudes de atención al cliente referenciando message-IDs antiguos
- Necesidades de investigación de cumplimiento (raras pero caras si no puedes acceder a los logs antiguos)
Tras 30 días, archivar datos del proveedor antiguo, terminar la cuenta, disfrutar del ahorro.
Patrones de migración por proveedor de origen
Distintos proveedores de origen tienen distintos truquillos.
| Origen | Truquillo específico | Enfoque recomendado |
|---|---|---|
| SendGrid | Categorización de supresión no estándar; exporta vía API no UI. Sin tier gratuito desde marzo 2025: el cliente puede migrar por coste | Patrón puente, validar import de supresión explícitamente |
| Mailgun | Cuentas EU y US son separadas; los datos no transfieren. Plan Flex se duplicó a $2/1K en diciembre 2025 (dispara migraciones) | Confirmar región de origen; exportar vía API por región |
| Postmark | Opiniones fuertes sobre separación transaccional vs marketing; preservar en setup nuevo | Mantener separación de stream en config del proveedor nuevo |
| AWS SES | Categorización de bounce mínima; el proveedor nuevo puede tener categorías más ricas que cambian la supresión | Establecer línea base en proveedor nuevo antes de mover volumen |
| Mailchimp Transactional (Mandrill) | Histórico de cierre forzaba migración por quemado en algunos casos | Pre-calentar IPs del proveedor nuevo lo más posible antes del deadline |
| Brevo / Sendinblue | Lista de supresión exportable desde "Contactos > Exportar" | CSV en UTF-8 importable en Mailrelay/Acumbamail directamente |
| Postfix on-premise | Sin lista de supresión publicada; la has estado suprimiendo en aplicación | Auditar reglas de supresión de aplicación; mapear al equivalente del proveedor |
Cada origen tiene rarezas adicionales más allá de estas. El tiempo de auditoría pre-migración se paga solo durante el cutover.
Coste real comparado: cuánto cuesta cambiar y cuánto se ahorra
Para una empresa española mid-market enviando 1 millón de emails al mes, las cifras Q2 2026:
Coste actual estimado en SendGrid Pro 700K:
- Plan Pro: 602 $/mes (con overage hacia 1M)
- IP dedicada: 30 $/mes
- Total: ~632 $/mes ≈ 580 €/mes
Coste alternativo Mailgun Foundation/Scale:
- Plan Scale 1M: 700 $/mes
- O Foundation 50K + overage: típicamente más caro que Scale a 1M
- Sin EU data hosting incluido en plan base
Coste alternativo Mailrelay:
- Plan adaptado a 1M envíos/mes: ~199-299 €/mes
- Datacenter en España, soporte telefónico en castellano
- Plan gratuito hasta 80.000 emails/mes a 20.000 contactos
- Coste evita problemas Schrems II
Coste alternativo OS Domains Email API EU:
- Plan Pro 1M: 299 €/mes
- 7 PoPs UE + Panamá, DMARC gestionado incluido
- Schrems II ready by design
El delta de 280-380 €/mes a favor del proveedor europeo se traduce en ~3.500-4.500 € anuales de ahorro directo, antes de contar la reducción de fricción de procurement con clientes europeos sensibles a Schrems II.
Qué mata las migraciones
A través de nuestras 50+ migraciones, las causas de fallo son mayoritariamente evitables:
Causa 1: saltarse el calentamiento del proveedor nuevo. La más común. El equipo piensa “empezamos a enviar y se calentará natural”. Los receivers ven una IP nueva a volumen completo en día 1, throttlean agresivamente, el placement cae. Recuperación 4-8 semanas.
Causa 2: límite de 10 lookups SPF. Añadir los includes SPF del proveedor nuevo empuja el total por encima de 10. SPF empieza a fallar silenciosamente, alineamiento DMARC se rompe, reputación cae. Mitigación: SPF flattening (resolver includes a rangos IP) o migración a autenticación solo DKIM durante la transición.
Causa 3: race conditions en integración webhook. La aplicación está recibiendo webhooks de bounce/queja de dos proveedores. Si la lógica de supresión tiene race conditions o no deduplica correctamente, puedes acabar enviando a una dirección suprimida (porque el proveedor nuevo todavía no recibió la supresión) y la tasa de queja sube.
Causa 4: desajuste TTL DNS. Registros DNS actualizados para la migración pero los TTLs son de 24h+. Algunos receivers cachean el DNS antiguo, otros ven el nuevo. Autenticación inconsistente durante la transición. Mitigación: bajar TTLs a 300 una semana antes de la migración.
Causa 5: no validar placement real. El equipo monitorea tasa de bounce (se ve bien) y tasa de queja (se ve bien) y asume que va bien. El placement real en inbox se degradó pero no lo ven porque no tienen seed testing en su sitio. Para la semana 3 las métricas de engagement de la campaña se hunden y se dan cuenta tarde.
El factor Schrems II como motor de migración
Para empresas españolas con cliente final UE durante 2024-2026 hemos visto un patrón consistente: la migración no se origina por insatisfacción técnica con SendGrid o Mailgun, sino por presión de procurement de clientes europeos exigiendo sub-procesador europeo.
Casos típicos que documentamos en clientes españoles:
Caso 1: SaaS B2B catalán con cliente fintech francés. El cliente francés pidió evaluación de cadena de sub-procesadores bajo DORA. Detectó que el SaaS catalán usaba SendGrid (jurisdicción estadounidense). El SaaS catalán migró a OS Domains Austria en 8 semanas, mantuvo el contrato, ganó dos referencias adicionales en su sector.
Caso 2: e-commerce madrileño con clientes alemanes. Cliente alemán (sector industrial, NIS2) pidió documentación Schrems II del proveedor email. SendGrid Pro entregó docs genéricas; el cliente requería sub-procesador EU-incorporado. Migración a Mailrelay (España) en 6 semanas. Beneficio adicional: soporte en castellano más rápido que el chat de SendGrid.
Caso 3: agencia de marketing digital sevillana con cliente bancario. Cliente bancario español sujeto a DORA pidió que la agencia incluyera al proveedor email en el registro consolidado de proveedores TIC remitido a la CNMV en marzo 2026. Mailgun no entregó la documentación contractual requerida en plazo. Migración forzada a OS Domains.
En cada caso, la decisión técnica (qué proveedor) fue secundaria al motor regulatorio (Schrems II + NIS2/DORA). El playbook de migración fue idéntico.
Cuándo necesitas ayuda profesional para migrar
La migración auto-gestionada funciona si:
- Tienes un canal de envío único
- El volumen está por debajo de 500K mensual
- El equipo tiene experiencia previa de migración
- Tienes flexibilidad sobre el cronograma si afloran sorpresas
La migración externalizada tiene sentido si:
- Multi-canal (transaccional + marketing + cold email separadamente)
- Volumen por encima de 500K mensual
- Deadline duro de cutover (cumplimiento, fin de contrato, cierre de proveedor)
- El coste del fallo es alto comparado con el coste del servicio de migración
Nuestro servicio de migración cubre la ejecución operacional: auditoría pre-migración, setup de operación paralela, revisión semana a semana de métricas, garantía contractual de placement. Para clientes mid-market y enterprise con cronogramas duros, la previsibilidad vale el coste.
Línea final
La migración de email es disciplina, no tarea. Las piezas técnicas están bien documentadas. La disciplina para seguir el patrón puente, monitorear a nivel receiver, y resistir la presión de hacer cutover más rápido de lo que los receivers aceptarán, esa es la diferencia entre migraciones exitosas y las que cuestan a la empresa tres meses de placement.
Si migras en 2026, planifica 4-6 semanas para ejecución limpia. El enfoque “solo cambiamos el DNS” no funciona desde hace años y funciona menos ahora que antes del bulk sender mandate. Planifica el puente, haz el calentamiento, valida a nivel receiver, y trata el coste de operación paralela como seguro barato.
Para senders españoles e hispanohablantes, el motor regulatorio (Schrems II, NIS2, DORA) está empujando migraciones hacia sub-procesadores europeos como Mailrelay, Acumbamail, Brevo o nuestra propia infraestructura. El cálculo cambió: lo que era opcional en 2022 se está volviendo requisito de procurement en 2026.