Servidor SMTP dedicado, listo para producción

Su aplicación necesita enviar correo de manera confiable. Recuperos de contraseña que llegan en 30 segundos, no en 3 minutos. Confirmaciones de pedido que aterrizan en bandeja, no en la pestaña de promociones. Alertas de seguridad que no se demoran por congestión en una cola de IPs compartidas. Un servidor SMTP gestionado sobre infraestructura dedicada se encarga de la capa de envío para que su equipo de desarrollo se concentre en la aplicación y no en la entregabilidad del correo.

Qué entrega un servidor SMTP gestionado

El SMTP relay es la capa entre su aplicación y el servidor de correo del destinatario. Su app se conecta a nuestro endpoint, autentica y entrega el mensaje. La infraestructura PowerMTA se ocupa del resto: enrutamiento al servidor destino correcto, gestión de límites de conexión por proveedor, procesamiento de bounces, manejo de retries en fallos temporales y log de cada evento de entrega.

La ventaja sobre un servidor SMTP autohospedado (Postfix o Exim) es la continuidad operativa. La entrega SMTP exige mantener relaciones con los proveedores, gestionar la reputación de IP, responder a listings en blacklists y mantenerse al día con los requisitos cambiantes de Gmail, Yahoo y Microsoft. Un servicio gestionado se encarga de eso.

La ventaja sobre un relay SMTP compartido (Mailgun, SendGrid, Postmark) es el aislamiento de IP. En infraestructura compartida, su correo transaccional comparte pools de IPs con miles de senders. Un evento de reputación de otro sender afecta su entrega. En infraestructura dedicada, solo su comportamiento determina la reputación de sus IPs.

API drop-in: migración desde Mailgun, SendGrid o Postmark

La migración desde un ESP compartido a infraestructura dedicada no requiere cambios de código en su aplicación. La capa de compatibilidad traduce las requests entrantes a instrucciones de entrega de PowerMTA, y traduce los eventos de PowerMTA al mismo formato de webhook que esperan sus handlers actuales.

El submission SMTP estándar (puerto 587 con STARTTLS) también está soportado para aplicaciones que prefieren SMTP directo en lugar de la API HTTP. Autenticación por credenciales SMTP con TLS obligatorio.

Arquitectura de entregabilidad para correo transaccional

El correo transaccional — recuperos de contraseña, confirmaciones de pedido, notificaciones de cuenta — tiene requisitos de entregabilidad distintos al marketing. El destinatario lo espera de inmediato y con urgencia alta. La ventana de tolerancia para una falla de entrega son segundos, no horas. Y a diferencia del marketing, el destinatario lo está esperando: las tasas de queja son naturalmente bajas y las señales de engagement son altas, lo que crea un entorno positivo de entregabilidad cuando la infraestructura está bien configurada.

La infraestructura está configurada específicamente para patrones transaccionales. Los pools de IPs dedicados a transaccional contienen solo envíos transaccionales — no se mezcla marketing en el pool. Esa composición transaccional pura mantiene la tasa de queja agregada y las señales de engagement estructuralmente altas, sosteniendo el placement entre 97% y 99% para correo correctamente autenticado.

La lógica de retry de PowerMTA está calibrada para la urgencia transaccional. En fallos temporales (421, 450), los mensajes transaccionales se reintentan en 2-5 minutos y no en las ventanas extendidas que sí son apropiadas para envío masivo. La latencia del primer intento contra Gmail, Yahoo y Outlook suele estar por debajo de 3 segundos desde la entrada del mensaje hasta la entrega.

Logs de entrega y monitoreo

Cada mensaje genera un log completo: la respuesta SMTP exacta del servidor receptor, timestamp de cada intento, IP usada y estado de la verificación DKIM. Cuando un destinatario reporta que no recibió un correo, la respuesta operativa correcta es recuperar el log del mensaje, ver qué devolvió el receptor y diagnosticar desde ahí.

Los eventos de entrega están disponibles vía webhook en tiempo real: delivered, bounced (hard y soft), deferred, opened (con tracking pixel) y clicked (con redirect). Los payloads son compatibles con el formato de webhook de Mailgun: los handlers existentes después de migrar siguen funcionando.

La interfaz de gestión permite buscar el historial de entrega por dirección de destinatario, message ID, dominio remitente o rango de fechas. Para casos de cumplimiento o de soporte al cliente, recuperar el registro completo de un correo específico por dirección de destinatario es básico — y lo entregamos sin los límites de retención de 7 días que aplican los relays compartidos en sus tiers estándar.

Para envíos masivos: usar también el mismo servidor SMTP

El mismo servidor SMTP funciona para envío masivo (newsletters, campañas) conectándolo a un EMS estándar como MailWizz, Acelle Mail o Interspire. La configuración del servidor varía: para masivo se ajustan los virtual MTAs con límites por proveedor más conservadores, se activa el FBL pipe de Yahoo y se configura el bounce processor del EMS para que se sincronice con la suppression list. Si su caso es exclusivamente envío masivo, las páginas de Servidores PowerMTA y Servidores para Correo Masivo tienen el detalle del montaje específico.

Los planes que aparecen abajo (Starter, Professional, Scale) sirven tanto para uso transaccional como masivo. El equipo de configuración pregunta el tipo de envío durante el setup y calibra los virtual MTAs en consecuencia.