Relay SMTP con IPs dedicadas desde el plan de entrada — para aplicaciones que ya hablan SMTP y no quieren reescribir nada

Relay SMTP fiable para aplicaciones que ya envían email — sin migración de código

El relay SMTP es la primera elección lógica cuando ya hay un sistema enviando correo por SMTP y la prioridad es subir la calidad de entrega sin tocar el código de la aplicación. Una migración desde SendGrid, Mailgun, Postmark, Amazon SES o un servidor SMTP propio se reduce, en términos prácticos, a actualizar dos variables de entorno: el host de salida y las credenciales de autenticación. La aplicación sigue usando la misma librería SMTP, los mismos templates, el mismo flujo de envío. Lo que cambia es la infraestructura por la que pasa el correo después de salir del proceso.

Esto es relevante porque la alternativa — migrar a una API REST de envío — implica reescribir la lógica de envío en la aplicación, modificar las plantillas, cambiar el modelo de eventos y reentrenar al equipo. Para muchas aplicaciones (especialmente las que ya están en producción con código maduro), ese coste no compensa frente al beneficio. El relay SMTP existe precisamente para ese escenario.

Arquitectura del servicio: qué ocurre cuando su aplicación envía por nuestro relay

El flujo técnico, paso a paso, para que el equipo de ingeniería entienda exactamente qué firma está adoptando:

1. Submission desde su aplicación. La aplicación se conecta a nuestro endpoint relay.authorizehosting.com en puerto 587 (recomendado, STARTTLS) o 465 (alternativo, SMTPS implícito). Autenticación con AUTH PLAIN o LOGIN sobre TLS 1.2 mínimo. El puerto 25 está bloqueado para submission desde aplicaciones por seguridad — se reserva para tráfico legítimo server-to-server entre MTAs.
2. Validación inicial en nuestra capa de submission. Verificamos las credenciales, el rate limit del cliente, la estructura del mensaje (headers obligatorios, From alineado con dominio autorizado), y la firma DKIM si la aplicación ya la añade. Si DKIM no se añade desde la aplicación, lo añadimos nosotros en el siguiente hop con la clave privada gestionada por nuestro servicio.
3. Routing al pool de IPs apropiado. Cada cliente tiene asignado un pool de IPs dedicadas (10 en Starter, 25 en Growth, 50 en Pro). El mensaje se enruta al pool correcto según la categoría (transaccional vs promocional cuando esa separación está activa) y según la disponibilidad de las IPs del pool.
4. Entrega al MX del receptor con políticas adaptadas. Nuestro MTA (PowerMTA en producción) aplica políticas de entrega específicas por dominio receptor: throttling conservador para Gmail durante warming, batch sizing distinto para Microsoft, back-off curves para Yahoo. Estos parámetros se ajustan según la respuesta del receptor y se documentan en logs.
5. Procesamiento de bounces y feedback loops. Cualquier respuesta del receptor — bounce duro o blando, queja de spam, deferral temporal — se captura, clasifica y expone vía panel de cliente o webhook si está configurado. Los bounces duros entran automáticamente en la lista de supresión del cliente para evitar reintentos.
6. Logging y observabilidad. Cada hop queda registrado con timestamps, IP de salida, código de respuesta del receptor y latencia. Logs retenidos por defecto 90 días, extensibles a 12 meses en planes Pro. Acceso vía panel web o vía export JSON para ingest en Datadog, Elasticsearch, S3-compatible o cualquier sistema de observabilidad.

Lo que viene incluido en cada plan — y lo que cuesta lo que no viene

La política de pricing es transparente: el precio publicado incluye lo que su aplicación necesita para operar en producción desde el primer día. Las únicas variables que pueden generar coste adicional son volumen muy por encima del incluido (facturado a tarifa preferente sin sorpresa), retención extendida de logs, y servicios opcionales como certificado VMC para BIMI.

Cuándo conviene este servicio — y cuándo no

La honestidad sobre encaje funciona en ambas direcciones. El Relay SMTP es la primera elección natural en algunos escenarios y la elección equivocada en otros. Vale la pena tenerlo claro antes de decidir.

Comparativa frente a SendGrid, Mailgun y Postmark

Las tres opciones americanas que más nos preguntan. Tomamos sus precios públicos consultados en marzo de 2026 — pueden cambiar, verifíquelos en sus páginas oficiales antes de decidir.

Lectura comercial honesta: para volúmenes muy bajos (menos de 50.000 mensajes/mes) cualquiera de estas opciones americanas es probablemente más barata. A partir de 100.000-500.000 mensajes/mes con necesidad real de IPs dedicadas, la propuesta de Authorize Hosting empieza a tener una ventaja clara — sobre todo cuando se cuenta el coste por IP adicional. Para volúmenes superiores a 5 millones/mes, la diferencia es tan grande que suele cerrar la conversación.