MTA propio vs API de email: costos, control y vendor lock-in

Operar tu propio MTA (Postfix, Exim, un MTA a medida) te da control total sobre colas, reintentos, IPs y reputación, con el menor costo por mensaje a gran escala, pero exige experiencia en entregabilidad y operación continua. Una API de email te deja enviar en minutos y delega esa operación, a cambio de un precio por mensaje y de una dependencia del proveedor (vendor lock-in) en APIs, plantillas, eventos y, a veces, reputación. La elección depende de tu volumen, de tu equipo y de cuánto te cuesta cambiar de proveedor el día que lo necesites.

Lo que implica operar un MTA propio

Instalar Postfix y enviar un correo es fácil. Entregar millones de mensajes a la bandeja de entrada de forma sostenida no lo es. Un MTA de producción necesita:

Infraestructura

• IPs con buena reputación y PTR configurable. Las IPs recicladas de proveedores cloud pueden arrastrar historial.
• Puerto 25 saliente. AWS, Google Cloud y Azure lo bloquean o restringen por defecto en muchas cuentas; hay que solicitar la excepción, y no siempre se concede.
• IPv4 e IPv6 con autenticación y DNS inverso correctos en ambos caminos.
• TLS con certificados válidos y, si quieres ir más allá, MTA-STS y TLS-RPT para el correo entrante de rebotes.

Lógica de entrega

• Colas por dominio de destino con límites de concurrencia y de velocidad distintos para Gmail, Outlook, Yahoo y el resto.
• Reintentos con backoff ante respuestas 4xx, y expiración controlada.
• Interpretación de respuestas (enhanced status codes de RFC 3463) para separar rebotes duros, suaves y bloqueos por política.
• Firma DKIM por dominio, con rotación de claves.

Reputación y cumplimiento

• Warm-up de cada IP nueva.
• Procesamiento de rebotes asíncronos (DSN, RFC 3464) con VERP.
• Feedback loops (ARF, RFC 5965) y listas de supresión.
• Baja con un clic (RFC 8058) en el correo comercial.
• Monitorización de Postmaster Tools, SNDS y listas de bloqueo, con alertas.

Operación

• Guardias cuando una IP entra en una lista de bloqueo un viernes por la noche.
• Gestión de capacidad en picos.
• Actualizaciones de seguridad del MTA y del sistema.

Nada de esto es imposible; es trabajo constante que alguien tiene que hacer.

Lo que implica usar una API de email

curl https://api.proveedor.example/v1/emails \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"from":"hola@example.com","to":"ana@example.es","subject":"Bienvenida","html":"<p>Hola</p>"}'

En minutos estás enviando. El proveedor gestiona IPs, colas, reintentos, rebotes y, en mayor o menor medida, reputación. Tú configuras DNS y te integras con sus webhooks.

Comparativa de costos

No hay cifras universales, pero sí una estructura clara:

La pregunta útil no es "¿cuánto cuesta un mensaje?", sino "¿cuánto cuesta en total entregar bien un mensaje?". Una persona dedicada parcialmente a entregabilidad puede costar más que años de facturas de una API a volumen moderado. A muy gran escala, la ecuación se invierte.

Control: qué ganas con un MTA propio

• Políticas de reintento a tu medida, por destino y por tipo de mensaje.
• Prioridades de cola: el transaccional nunca espera detrás del marketing.
• Datos completos: cada respuesta SMTP, cada DSN, sin muestreo ni retención limitada.
• Decisiones de reputación propias: cuándo pausar, cuándo añadir una IP, cómo separar streams.
• Sin límites impuestos por terceros sobre tamaño, adjuntos o velocidad.

Vendor lock-in: dónde te atan

El lock-in rara vez está en la llamada HTTP de envío, que se cambia en una tarde. Está en lo que se acumula alrededor:

1. DKIM con el dominio del proveedor. Si la firma es d=proveedor.example, tu reputación de dominio no es tuya. Al cambiar, empiezas de cero.
2. IPs del proveedor. La reputación de IP construida con el proveedor se queda allí.
3. Listas de supresión. Si no puedes exportarlas, al migrar vuelves a enviar a direcciones que rebotaron o se quejaron, con el daño consiguiente.
4. Plantillas en formato propietario y lógica de personalización dentro del proveedor.
5. Webhooks con esquema y firma propios, que obligan a reescribir el código de recepción.
6. Historial de eventos que no puedes descargar.

Cómo mantener la portabilidad

Uses lo que uses, protege tu capacidad de cambiar:

• DKIM con tu dominio (d=example.com) y un return-path en un subdominio tuyo. La reputación de dominio te acompaña.
• Copia propia de la lista de supresión, alimentada por webhooks. Es tu activo más valioso al migrar.
• Una interfaz interna de envío (EmailSender.send(...)) para que el proveedor sea un detalle de implementación.
• Plantillas en tu repositorio, renderizadas por tu código.
• Webhooks estándar (como Standard Webhooks) para no reescribir verificaciones.
• Prueba la salida: exporta tus datos de vez en cuando para comprobar que realmente puedes.

Cuándo elegir cada opción

MTA propio si tienes volumen muy alto y constante, un equipo con experiencia en entregabilidad y operación 24/7, o requisitos de control o residencia de datos que ninguna API cubre.

API de email si tu prioridad es el producto, tu volumen es bajo o moderado, o no tienes a nadie para atender una IP bloqueada de madrugada.

Un punto intermedio es una plataforma que opera su propio MTA (sin revender un proveedor de envío de terceros) y te expone una API, con autenticación en tu dominio y datos exportables.

Errores comunes

• Subestimar la entregabilidad al montar un MTA: enviar es fácil, llegar a la bandeja no.
• Comparar solo el precio por mensaje sin contar ingeniería ni incidentes.
• Aceptar DKIM con el dominio del proveedor por comodidad.
• No guardar la lista de supresión fuera del proveedor.
• Acoplar el código de negocio a la API concreta de un proveedor.

El enfoque de Pidgely

Pidgely es ese punto intermedio: opera su propio MTA, sin depender de un proveedor de envío externo, y ofrece una API para desarrolladores con DKIM en tu dominio, return-path alineado y webhooks según Standard Webhooks, para que tu reputación y tus datos no queden atados a la plataforma.