El equipo de ingeniería de una startup construyó su aplicación para enviar emails directamente desde sus servidores web. Funcionaba bien en desarrollo. En producción, los emails empezaron a desaparecer. Gmail los rechazaba. Microsoft los limitó. Sus direcciones IP no tenían reputación, sus servidores no estaban configurados para la entrega de correo y estaban aprendiendo por las malas que enviar email es más difícil de lo que parece.
Se cambiaron a un servicio de relay de email. En un día, sus problemas de entrega desaparecieron. El relay gestionó la autenticación, la reputación de IP, el throttling y los reintentos, y en general hizo todas las cosas que sus servidores web no podían hacer bien.
Los relays de email existen porque enviar email de forma fiable es un problema especializado. La mayoría de las aplicaciones no deberían intentar resolverlo por sí mismas.
Lo que realmente hace un relay
Un email relay acepta email de un sistema y lo reenvía a otro. Tu aplicación envía el email al relay; el relay lo envía al servidor de correo del destinatario. El relay se sienta en medio, manejando la complejidad de la entrega real.
Puede sonar como una indirección innecesaria, pero el relay presta servicios cruciales. Mantiene relaciones con los principales proveedores de email. Gestiona la reputación de IP entre todos sus clientes. Maneja la autenticación (SPF, DKIM, DMARC) correctamente. Implementa una lógica de reintentos adecuada para fallos temporales. Gestiona la limitación de tasa para evitar saturar los servidores de los destinatarios.
Tu aplicación solo necesita entregar el email. El relay se encarga del resto.
El término "relay" puede referirse a distintas cosas en distintos contextos. Un SMTP relay es cualquier servidor que reenvía email. Un smart host es un relay que un servidor de correo configura para enrutar todo el email saliente a través de él. Los servicios de email transaccional como SendGrid, Mailgun o Amazon SES son esencialmente servicios de relay gestionados con funcionalidades adicionales.
Por qué las aplicaciones necesitan relays
Enviar email directamente desde los servidores de aplicación crea problemas que los relays resuelven.
La reputación de IP es el mayor problema. Los proveedores de email juzgan a los remitentes por el historial de sus direcciones IP. Una IP nueva sin historial se trata con sospecha. Una IP que ha estado enviando spam (incluso de inquilinos anteriores en un entorno cloud) se bloquea. Construir y mantener reputación de IP requiere volumen de envío consistente y buenas prácticas a lo largo del tiempo—no algo que la mayoría de las aplicaciones puedan proporcionar.
La configuración de autenticación es compleja. Los registros SPF deben autorizar tus IPs de envío. DKIM requiere generación de claves, registros DNS y firmas correctas. DMARC lo une todo. Hacer esto bien en servidores de aplicación, especialmente en entornos cloud dinámicos donde las IP cambian, es difícil.
La gestión de la entrega requiere sofisticación. Cuando un servidor destinatario devuelve un error temporal, debes reintentar con el backoff adecuado. Cuando te aplica limitación, debes reducir el ritmo. Cuando rechaza de forma permanente, debes dejar de intentar. Implementar esto correctamente no es trivial.
La monitorización y la depuración necesitan infraestructura. Cuando los emails fallan, necesitas saber por qué. Los relays proporcionan logs, analíticas y herramientas de debugging que sería costoso construir por tu cuenta.
Tipos de email relays
Diferentes configuraciones de relay sirven necesidades distintas.
Los servicios gestionados de email transaccional (SendGrid, Mailgun, Postmark, Amazon SES) son la opción más común para aplicaciones. Proporcionan APIs y endpoints SMTP, manejan toda la complejidad de entrega y ofrecen analíticas y herramientas de depuración. Pagas según el volumen.
Los relays autogestionados (Postfix, Exim configurados como relays) te dan control pero requieren experiencia. Tú gestionas los servidores, mantienes la reputación, configuras la autenticación. Tiene sentido para organizaciones con requisitos de cumplimiento específicos o volúmenes muy altos donde los costes del servicio gestionado se vuelven significativos.
Los relays del ISP o del proveedor de hosting a veces están disponibles como parte de paquetes de alojamiento. La calidad varía ampliamente. Algunos están bien mantenidos; otros se comparten con spammers y tienen una reputación terrible. Evalúa cuidadosamente antes de confiar en ellos.
Los relays internos dentro de organizaciones enrutan email entre sistemas internos y el mundo exterior. Pueden añadir cabeceras de cumplimiento, escanear datos sensibles o aplicar políticas. Normalmente reenvían a otro relay o directamente a los destinatarios.
SMTP relay vs API
Los servicios de email modernos ofrecen dos formas de enviar: SMTP relay y HTTP API. Ambos logran el mismo objetivo pero funcionan de manera diferente.
SMTP relay utiliza el protocolo tradicional de email. Tu aplicación se conecta al servidor SMTP del relay, se autentica y envía el email usando comandos estándar de SMTP. Esto funciona con cualquier sistema que pueda enviar email—aplicaciones heredadas, plugins de WordPress, dispositivos de red, cualquier cosa con soporte SMTP.
Las APIs HTTP son más modernas. Tu aplicación hace una petición HTTP POST con el contenido del email como JSON o datos de formulario. Suele ser más fácil de integrar en aplicaciones web, proporciona respuestas de error más ricas y puede ofrecer funcionalidades más allá del envío básico de email.
Para aplicaciones nuevas, las APIs suelen ser preferibles. Son más fáciles de trabajar, proporcionan mejor feedback e integran de forma natural con prácticas modernas de desarrollo. Para sistemas heredados o dispositivos que solo soportan SMTP, el acceso vía relay es esencial.
Muchos servicios ofrecen ambos, permitiéndote elegir según tus necesidades. Algunas funcionalidades pueden estar disponibles solo a través de una interfaz u otra.
Configurar aplicaciones para usar relays
La mayoría de las aplicaciones y frameworks tienen una configuración de relay sencilla.
Para SMTP relay, normalmente configuras: el hostname del relay, el puerto (usualmente 587 para submission con TLS), las credenciales de autenticación (usuario y contraseña o API key) y los ajustes de TLS. La aplicación entonces envía todo el email saliente a través de este relay.
Para integración vía API, usas el SDK del servicio o haces peticiones HTTP directamente. La configuración implica API keys y URLs de endpoints. La integración suele requerir más código pero proporciona más control y mejor manejo de errores.
La configuración específica por entorno es importante. Los entornos de desarrollo pueden usar un servicio como Mailtrap que captura emails sin entregarlos. Staging puede usar el relay de producción pero enviar a direcciones de prueba. Producción usa el relay real con entrega real.
La gestión de credenciales importa. Las API keys y contraseñas SMTP deben almacenarse de forma segura, no en hardcode. Usa variables de entorno o sistemas de gestión de secretos. Rota las credenciales periódicamente.
Cuándo usar tu propio relay
La mayoría de las aplicaciones deberían usar servicios de relay gestionados. Pero algunas situaciones justifican operar el tuyo.
Volumen extremo puede hacer que los servicios gestionados sean caros. Si envías cientos de millones de emails al mes, los costes por email se acumulan. Operar tu propia infraestructura puede ser más económico, aunque cambias dinero por complejidad operativa.
Los requisitos de cumplimiento a veces exigen control sobre la infraestructura de email. Organizaciones de salud, finanzas y gobierno pueden necesitar garantizar que los emails nunca pasan por sistemas de terceros, o requerir capacidades de auditoría específicas que los servicios gestionados no proporcionan.
Requisitos técnicos específicos pueden no estar cubiertos por servicios gestionados. Esquemas de autenticación personalizados, protocolos inusuales o integración con sistemas heredados pueden requerir una solución autohospedada.
Si operas tu propio relay, espera una carga operativa significativa. Necesitarás gestionar la reputación de IP, manejar problemas de listas negras, mantener la configuración de autenticación, monitorizar la entrega y mantenerte al día con los estándares de email en evolución. Es un conjunto de habilidades especializado.
Consideraciones de seguridad de los relays
Los relays son objetivos atractivos para el abuso. Un relay comprometido puede enviar spam que dañe tu reputación y potencialmente te ponga en listas negras.
La autenticación es esencial. Nunca ejecutes un open relay que acepte email de cualquiera. Requiere autenticación para todas las entregas. Usa credenciales fuertes y rótalas periódicamente.
La limitación de tasa previene abusos por credenciales comprometidas. Si un atacante obtiene un juego de credenciales, los límites de tasa contienen el daño mientras respondes.
La monitorización de anomalías detecta problemas temprano. Picos de volumen repentinos, patrones de destinatarios inusuales o envío a horas extrañas pueden indicar compromiso. Genera alertas sobre estos patrones.
La verificación de remitente asegura que solo direcciones autorizadas puedan enviar. Si tu relay debe enviar desde @yourcompany.com, rechaza intentos de envío desde otros dominios.
Frequently asked questions
¿Usar un relay es lo mismo que el reenvío de email?
No exactamente. El reenvío toma email recibido y lo envía a otro lugar. El relay toma email de una aplicación o servidor y lo entrega a los destinatarios. El relay forma parte del camino de envío, no del de recepción.
¿Usar un relay mejorará mi entregabilidad?
Por lo general sí, de forma significativa. Los buenos servicios de relay mantienen una fuerte reputación de IP, manejan la autenticación correctamente y gestionan la entrega de forma profesional. Esto casi siempre supera lo que los servidores de aplicación pueden hacer directamente.
¿Puedo usar Gmail u Outlook como relay?
Los servicios de email para consumidores tienen límites de envío estrictos y no están diseñados para uso de aplicaciones. Google Workspace y Microsoft 365 ofrecen funcionalidades de SMTP relay para sus clientes, pero con limitaciones. Para email de aplicaciones serio, usa un servicio dedicado.
¿Cuál es la diferencia entre un relay y un MTA?
Un MTA (Agente de Transferencia de Correo) es cualquier servidor que transfiere email. Un relay es un MTA específicamente configurado para reenviar email desde otros sistemas en lugar de ser el origen o destino final. Todos los relays son MTAs, pero no todos los MTAs son relays.