Tutorial

Correo profesional

Postal: plataforma SMTP autoalojada para agencias

Un cliente se queja de que los correos de confirmación desaparecen, otro ve sus facturas acabar en spam — y no tienes ningún registro para entender qué ocurrió. Postfix hace su trabajo en silencio, pero eso es exactamente el problema: es un relay ciego, sin interfaz, sin estadísticas, sin gestión de rebotes. Postal cambia la ecuación. Es una plataforma SMTP completa — interfaz web multiusuario, API REST, webhooks de rebote, estadísticas por servidor de envío — que despliegas en un solo VPS para gestionar toda la cartera de clientes de tu agencia, sin depender de Mailgun, Postmark ni SendGrid.

10 min de lectura7 pasos
Contenido· Por qué las agencias necesitan una plataforma SMTP completa1/9
  1. 01Por qué las agencias necesitan una plataforma SMTP completa
  2. 02Lo que Postal aporta a tu agencia
  3. 03Requisitos previos: VPS, puerto 25 e IPv4 dedicada
  4. 04Instalación de Postal en un VPS
  5. 05Configuración de un dominio remitente
  6. 06DMARC: la última pieza de la entregabilidad
  7. 07Gestión de rebotes y estadísticas
  8. 08Postal vs soluciones SaaS vs relay Postfix
  9. 09Una infraestructura de correo bajo tu control

Por qué las agencias necesitan una plataforma SMTP completa

Gestionar el envío de correo de una cartera de clientes solo con Postfix es navegar a ciegas. El MTA entrega o rechaza, pero no te dice por qué se produjo un rebote, qué campaña degradó la reputación de un dominio ni qué cliente consume más recursos de envío.

Para una agencia que gestiona 10, 20 o 50 dominios de clientes, esa opacidad es un riesgo operativo directo. Un solo cliente mal configurado puede provocar que la IP compartida acabe en listas negras y perjudique a toda la cartera. Y cuando el cliente llama para reportar un problema, no tienes nada que mostrarle.

Postal resuelve esto añadiendo una capa de control completa sobre el pipeline SMTP.

Lo que Postal aporta a tu agencia

  • Interfaz web multi-servidor: crea un servidor de envío aislado por cliente o proyecto, con sus propias credenciales SMTP y clave API.
  • Estadísticas por servidor de envío: volumen entrante y saliente y rebotes, en gráficos de 24 h, 48 h o 30 días — un servidor por cliente te da una vista por cliente.
  • Gestión de rebotes en tiempo real: cada fallo de entrega queda registrado y clasificado (SoftFail temporal, HardFail definitivo), cada rebote recibido se vincula al mensaje original, visible en la interfaz y enviado via webhook a tu aplicación.
  • API REST y webhooks: integra Postal con tu CRM, plataforma de e-commerce o herramienta de facturación.
  • Colas de mensajes: los envíos se ponen en cola y son trazables hasta el acuse de recibo o el error final, sin caja negra.
  • Aislamiento de clientes: cada servidor Postal puede recibir su propio pool de IP (opción use_ip_pools) y su propio límite de envío — con IP distintas, un cliente en dificultades no afecta a la reputación de los demás.
  • Licencia MIT: código abierto, sin coste por correo, sin dependencia de terceros.

Requisitos previos: VPS, puerto 25 e IPv4 dedicada

Postal v3.3.7 se instala mediante Docker. Los requisitos oficiales son:

Recursos: al menos 2 vCPU y 4 GB de RAM. La documentación recomienda encarecidamente un servidor dedicado a Postal, sin otro software. Reserva al menos 25 GB de almacenamiento SSD.

Sistema operativo: cualquier distribución que ejecute Docker Engine y el plugin Docker Compose (esta guía usa Ubuntu 24.04 LTS), con git, curl y jq.

Base de datos: MariaDB 10.6 o superior — la rama 10.6 ya no tiene mantenimiento comunitario desde julio de 2026, así que apunta a 10.11 o más reciente. MySQL no está soportado explícitamente.

Puerto 25: el punto crítico. El puerto 25 saliente debe estar abierto para que Postal pueda entregar mensajes a los servidores destinatarios. Muchos proveedores cloud lo bloquean por defecto — verifica esto antes de empezar.

rDNS: el DNS inverso de tu IPv4 debe apuntar al hostname de Postal (p.ej. postal.tu-agencia.com). Un PTR ausente o incorrecto hace que rechacen tus mensajes: desde febrero de 2024 Gmail exige un PTR válido para toda IP de envío.

Instalación de Postal en un VPS

  1. Preparar el servidor e instalar Docker

    Conéctate como root en tu VPS Ubuntu 24.04, actualiza los paquetes e instala Docker Engine y el plugin Compose:

    apt update && apt upgrade -y
    curl -fsSL https://get.docker.com | sh
    apt install -y git curl jq
    docker --version && docker compose version

    Verifica que el puerto 25 saliente esté abierto: nc -zv smtp.gmail.com 25. Si falla, contacta con tu proveedor para desbloquearlo.

  2. Configurar DNS para el servidor Postal

    Antes del bootstrap, crea los registros DNS para el dominio de tu instalación Postal (p.ej. postal.tu-agencia.com):

    - Registro A: postal.tu-agencia.com → IP del VPS
    - rDNS (PTR): configúralo en tu panel de control
    - SPF global (TXT en spf.postal.tu-agencia.com): v=spf1 ip4:<IP_VPS> ~all
    - Return path: rp.postal.tu-agencia.com con un registro A hacia la IP, un MX 10 postal.tu-agencia.com, un TXT v=spf1 a mx include:spf.postal.tu-agencia.com ~all y, tras el bootstrap, el DKIM que muestra postal default-dkim-record en postal._domainkey.rp.postal.tu-agencia.com

    Espera la propagación DNS (15 a 30 minutos) antes de continuar.

  3. Bootstrap de la configuración de Postal

    Clona el repositorio de instalación oficial, que proporciona el comando postal, y genera la configuración:

    git clone https://github.com/postalserver/install /opt/postal/install
    ln -s /opt/postal/install/bin/postal /usr/bin/postal
    postal bootstrap postal.tu-agencia.com

    Esto genera en /opt/postal/config los ficheros postal.yml, signing.key y Caddyfile, además de un docker-compose.yml (en /opt/postal/install) fijado en la última versión publicada. Abre postal.yml e introduce las credenciales de MariaDB, el SMTP de notificación y los nombres DNS de tu instalación (sección dns).

  4. Iniciar MariaDB e inicializar la base de datos

    Lanza un contenedor MariaDB dedicado, accesible solo en local y protegido por una contraseña generada, y luego inicializa el esquema de Postal:

    openssl rand -hex 24 > /root/postal-db.pass && chmod 600 /root/postal-db.pass
    docker run -d --name postal-mariadb \
      -p 127.0.0.1:3306:3306 \
      -e MARIADB_ROOT_PASSWORD="$(cat /root/postal-db.pass)" \
      -e MARIADB_DATABASE=postal \
      --restart always mariadb:10.11
    
    postal initialize

    Copia esta contraseña en las secciones main_db y message_db de postal.yml antes de ejecutar postal initialize.

  5. Crear el primer usuario administrador

    Crea tu cuenta de administrador para acceder a la interfaz web:

    postal make-user

    Introduce el correo electrónico, el nombre y la contraseña del administrador.

  6. Iniciar Postal y configurar el proxy inverso

    Lanza todos los servicios de Postal (web, workers, SMTP):

    postal start
    postal status

    Postal expone la interfaz web en 127.0.0.1:5000, inaccesible desde Internet. Coloca un proxy inverso (Caddy o nginx) delante para terminar TLS y accede a https://postal.tu-agencia.com.

  7. Crear una organización y el primer servidor de envío

    En la interfaz de Postal, crea una organización (tu agencia) y luego un servidor de envío para tu primer cliente. Cada servidor tiene sus propias credenciales SMTP, su propia clave API y sus propios dominios de envío — es la unidad de aislamiento por cliente.

    Anota el hostname SMTP, el puerto (25 por defecto, configurable con smtp_server.default_port) y las credenciales generadas: son los datos que deberás facilitar a la aplicación cliente.

Configuración de un dominio remitente

En cada servidor de envío de Postal, añade los dominios desde los que tus clientes enviarán correo. Para cada dominio, Postal genera automáticamente un par de claves RSA de 1024 bits y un selector DKIM único (formato postal-XXXXXX._domainkey).

Registros DNS a publicar para cada dominio de cliente:

SPF — añade include:spf.postal.tu-agencia.com en el registro TXT apex:

v=spf1 include:spf.postal.tu-agencia.com ~all

DKIM — publica el valor TXT mostrado en la interfaz en el subdominio generado:

postal-XXXXXX._domainkey.dominio-cliente.com  TXT  "v=DKIM1; t=s; h=sha256; p=<clave pública>"

Return Path (recomendado) — un CNAME que recibe los rebotes y alinea el SPF para DMARC:

psrp.dominio-cliente.com  CNAME  rp.postal.tu-agencia.com

Postal verifica estos registros automáticamente cada hora e indica en la interfaz si alguno falta o es incorrecto.

DMARC: la última pieza de la entregabilidad

Con SPF y DKIM configurados, añade una política DMARC en cada dominio de cliente. Empieza en modo monitorización (p=none) para recoger informes sin riesgo de bloqueo, luego endurece progresivamente hacia p=quarantine y p=reject:

_dmarc.dominio-cliente.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

El atributo rua envía informes agregados diarios a tu dirección. Postal firma cada mensaje con la clave DKIM del dominio en cuanto su registro está validado, y el return path psrp alinea el SPF: en dominios correctamente configurados, DMARC pasará desde el primer día.

Gestión de rebotes y estadísticas

Esta es la diferencia más visible entre Postal y un relay Postfix básico. En la pestaña Mensajes de cada servidor de envío, cada correo enviado se rastrea con su estado: Pending, Sent, Held, SoftFail, HardFail, Bounced.

Cuando una entrega falla o vuelve un rebote, Postal:
1. Registra el motivo exacto del rechazo en el log del mensaje (p.ej. 550 5.1.1 The email account does not exist)
2. Actualiza el estado de entrega en la interfaz (HardFail si el servidor destinatario rechaza durante la sesión SMTP, Bounced si llega un mensaje de rebote después)
3. Dispara un evento webhook (MessageDeliveryFailed o MessageBounced) hacia tu endpoint HTTP configurado

Esquemáticamente, un fallo de entrega se lee así (ejemplo simplificado):

[2026-10-15 09:14:22] Delivery attempt to mx1.example.com (203.0.113.10:25)
[2026-10-15 09:14:22] << 550 5.1.1 <[email protected]> User unknown
[2026-10-15 09:14:22] Message marked as HardFail (permanent)

Las estadísticas por servidor de envío muestran, en 24 h, 48 h o 30 días, el volumen entrante, el volumen saliente y los rebotes.

Postal vs soluciones SaaS vs relay Postfix

Desplace la tabla

CriterioPostal (autoalojado)Mailgun / PostmarkSMTP relay Postfix
VisibilidadInterfaz completa: log por mensaje, log de rebotes, estadísticas por servidor de envíoDashboard SaaS, retención de logs según el planSin interfaz — solo logs del sistema
CosteVPS + tiempo de administración (sin coste por correo)Facturación según el volumen de envío (consulta la tarifa de cada proveedor)Solo VPS (sin coste de software)
ControlTotal: IP, retención, política de rebotes, aislamiento por clienteParcial: políticas impuestas por el proveedor, IPs compartidas por defectoControl total de enrutamiento, cero visibilidad
Límite de envíoLimitado por recursos del VPS y reputación de IP — escalableCuotas según plan, escalado facturadoLimitado por VPS — sin gestión nativa de cuotas por dominio

Una infraestructura de correo bajo tu control

Postal es la herramienta que buscan las agencias cuando comprenden que Postfix solo ya no es suficiente para operar una cartera de clientes. La plataforma aporta la visibilidad que faltaba — logs estructurados, rebotes rastreados, estadísticas por servidor de envío — sin las restricciones de precio y dependencias de los SaaS.

Un VPS con 2 vCPU, 4 GB de RAM y una IPv4 dedicada es suficiente para empezar. El puerto 25 desbloqueado y un rDNS correctamente configurado son los dos requisitos previos que muchos proveedores no cumplen por defecto — verifícalos antes de contratar.

Los artículos SMTP relay Postfix en VPS y entregabilidad en VPS: puerto 25 y PTR completan esta guía para cubrir la entregabilidad en su conjunto.

Un VPS para tu plataforma SMTP

Postal requiere al menos 2 vCPU y 4 GB de RAM. Nuestros VPS incluyen IPv4 dedicada, acceso root, rDNS configurable y el puerto 25 desbloqueado bajo solicitud — los requisitos exactos para una instalación Postal en producción.