Escalando outbound email más allá del hosting compartido — los cambios técnicos cuando el envío deja de ser accesorio del hosting

El path típico de muchas empresas: empieza con WordPress en hosting compartido (Hostinger, GoDaddy, Bluehost, SiteGround, Hostgator, MediaTemple, OVH, IONOS). Funciona durante 1-2 años. Eventualmente, los problemas aparecen — emails de WooCommerce no llegan, password resets a clientes Gmail van directo a spam, las facturas que envía el plugin de billing acaban filtradas. La causa es siempre la misma: la IP del hosting compartido es problema reputacional. Este post cubre cuándo y cómo migrar a infraestructura más seria.

Por qué SMTP de hosting compartido eventualmente falla

El SMTP que viene incluido con hosting compartido (Hostinger, GoDaddy, Bluehost, SiteGround, etc.) usa servidores compartidos con muchos otros clientes. Cada cliente envía sus emails desde la misma IP o pool de IPs. Las consecuencias operativas:

Reputación compartida con clientes problemáticos. Algunos clientes del hosting envían spam, listas mal limpias, contenido marcado por filtros. La reputación de la IP compartida se degrada por sus problemas. Su email legítimo paga el coste — emails a Gmail van a spam, Microsoft los filtra, Yahoo los retrasa.

Configuración SMTP genérica sin optimización. El hosting provider no optimiza para deliverability serio. Sin custom DKIM por dominio del cliente. Sin separación de flujos. Sin warming. Sin monitoreo proactivo. Sin FBL handling.

Limitaciones de volumen agresivas. La mayoría de hosting compartido limita a 200-500 emails/hora por cliente. Para operación que crece, ese límite se golpea regularmente — emails se quedan en cola, llegan tarde, ocasionalmente se pierden.

Resolución de problemas mediocre. Cuando algo va mal (IP en blacklist, deliverability degradada), el soporte del hosting típicamente no tiene expertise email infrastructure. La respuesta es genérica o inexistente.

El SMTP de hosting compartido es funcional para sites con bajísimo volumen de email (notificaciones ocasionales del CMS, emails internos del admin). Para cualquier operación con volumen real, eventualmente se vuelve problema operativo.

Las señales de que es momento de migrar

Cinco señales concretas que indican que el SMTP del hosting ya no encaja:

Señal 1 — Tickets recurrentes de "no recibí mi email". Clientes reportando que emails (facturas, confirmaciones, recibos) no llegan. Si el patrón es 2-5 tickets mensuales con esta queja, indica que algo significativo del envío está siendo filtrado.

Señal 2 — Emails a Gmail/Outlook van a spam frecuentemente. Pruebas internas: enviar email del sistema a una cuenta Gmail propia, a una Outlook.com propia, a una Yahoo propia. Si más del 25% va a spam, el SMTP del hosting tiene problema reputacional serio.

Señal 3 — Volumen del sistema crece significativamente. Si el volumen mensual cruza 5.000-10.000 emails, los límites de hosting compartido empiezan a golpear y la calidad del envío degrada con escala.

Señal 4 — La empresa adquiere clientes B2B importantes. Los clientes B2B (especialmente enterprise) tienen filtros más estrictos y políticas de seguridad explícitas. Emails desde IPs de hosting compartido pueden ser bloqueados completamente por estos clientes.

Señal 5 — DMARC reportes muestran fails. Si la operación ha empezado a configurar DMARC y los reportes muestran fails desde la IP del hosting, indica que la configuración compartida no permite alignment correcto.

Cualquiera de estas señales sostenida durante 2-3 meses indica que la migración a infraestructura más seria justifica la inversión.

Las opciones a considerar al migrar

Salir del SMTP del hosting tiene varios destinos según volumen y necesidad:

Opción A — Relay SMTP de proveedor especializado low-cost. Postmark, Mailgun, Brevo, SMTP2GO. Cuesta 10-50 USD/mes para volúmenes bajos a medios. Setup es minutos: cambiar configuración SMTP en el sistema (WordPress, WooCommerce, ERP, etc.) para apuntar al proveedor en lugar del hosting. Adecuado para volumen bajo (hasta 100-300k mensuales).

Opción B — Cloud ESP all-in-one. SendGrid, Brevo Standard. Si la operación necesita marketing platform además de transactional, SCS+marketing en mismo proveedor. 35-150 USD/mes según features.

Opción C — Relay especializado europeo con IPs dedicadas. Para operaciones que cruzan 500k+ mensuales con perfil mixto y necesidad de varias IPs. Authorize Hosting Starter €399/mes con 5M mensajes y 10 IPs dedicadas, o equivalentes.

Opción D — Self-hosted con MTA propio. Solo tiene sentido para operaciones grandes (5M+ mensuales) con FTE dedicado. La complejidad rara vez compensa para casos que están migrando desde hosting compartido.

Para la mayoría de casos que migran de hosting compartido, Opción A o B son los destinos típicos. Opciones C y D entran cuando el volumen y complejidad justifican.

Pasos de migración técnica

La migración técnica desde SMTP del hosting es operacionalmente más simple de lo que muchos equipos esperan:

Paso 1 — Crear cuenta con el proveedor nuevo. Verificar dominio, configurar autenticación (SPF, DKIM con custom DKIM del proveedor para alignment, DMARC).

Paso 2 — Test con un sistema de bajo riesgo. Configurar primero un sistema secundario para apuntar al nuevo SMTP. Verificar que funciona, que la deliverability mejora, que los bounces se procesan. 1-2 semanas de prueba.

Paso 3 — Migrar sistemas restantes progresivamente. Uno cada pocos días: WordPress (vía plugin SMTP), WooCommerce, plugins específicos de billing, cualquier integration. Cada migración es cambio de configuración SMTP, sin tocar código.

Paso 4 — Verificar que la IP del hosting deja de enviar. Una vez todos los sistemas migrados, verificar que ninguno cae en fallback al SMTP del hosting. Logs del proveedor nuevo deberían mostrar todo el tráfico.

Paso 5 — Actualizar SPF para excluir el hosting. El registro SPF que incluía las IPs del hosting debe actualizarse para excluirlas (si el hosting ya no envía en su nombre, mantenerlo en SPF es vector innecesario).

Total tiempo de migración: 2-4 semanas para operación típica. La mayor parte es tiempo de calendar (verificación de cada paso) más que trabajo activo.

Errores frecuentes durante la migración

Error 1 — Migrar todo de golpe. Cambiar SMTP en todos los sistemas el mismo día. Si algo va mal, debugging es complejo (¿qué sistema causa el problema?). Migrar progresivamente identifica problemas específicos rápidamente.

Error 2 — No configurar custom DKIM. Apuntar al proveedor nuevo sin configurar custom DKIM significa que los emails firman con d=proveedor.com en lugar de d=su-empresa.com. DMARC alignment falla. Resultado: deliverability inferior pese a haber migrado a proveedor "mejor".

Error 3 — No actualizar SPF. Mantener las IPs del hosting en SPF tras migrar permite que cualquier compromiso del hosting envíe email "legítimo" desde el dominio. Vector de seguridad innecesario.

Error 4 — Esperar mejora inmediata. La reputación del nuevo proveedor (si IPs shared) o de las IPs nuevas dedicadas (si dedicadas) requiere construirse. Primeras 2-4 semanas pueden ser similares a antes mientras el sistema "calienta" la nueva reputación. Mejora real visible típicamente 4-8 semanas post-migración.

Error 5 — No medir antes y después. Sin baseline previo (inbox placement antes de migrar), comparar es ejercicio de impresión. Hacer test de inbox placement con seed list antes de migrar y repetir 6-8 semanas después da datos concretos sobre el ROI.

El ROI honesto

Para empresa con volumen modesto (10k-50k emails mensuales) que migra de hosting compartido a relay especializado, el ROI viene de varios lugares:

• Reducción significativa de tickets de soporte por "no llegó email" — tiempo del equipo recuperado
• Mejor conversión en flows que dependen de email (signup, checkout) — revenue protegido
• Capacidad de escalar volumen sin golpear límites del hosting — flexibilidad operativa
• Configuración profesional permite añadir DMARC reject que protege la marca de phishing
• Soporte técnico real cuando algo va mal — capacidad operativa diferente al "abre ticket genérico al hosting"

El coste típico (10-50 USD/mes para volúmenes bajos) se recupera fácilmente con uno o dos clientes B2B que no se hubieran perdido por problemas de deliverability. Para operaciones que crecen, la migración deja de ser "mejor opcional" y se vuelve infraestructura básica de la operación.