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

> Comparativa entre operar tu propio MTA y usar una API de email: costos reales, control de la entrega, riesgos de vendor lock-in y cómo mantener la portabilidad.

Source: https://pidgely.com/es/blog/mta-propio-vs-api-de-email/ · Published: 2026-10-12 · Pidgely

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

```bash
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:

| Concepto | MTA propio | API de email |
|---|---|---|
| Costo por mensaje | Muy bajo (marginal) | Precio por volumen del proveedor |
| Costo fijo | Servidores, IPs, monitorización | Plan mínimo, a veces |
| Ingeniería inicial | Alta | Baja |
| Ingeniería continua | Media-alta (entregabilidad + operación) | Baja |
| Costo de un incidente | Lo absorbes tú | Lo gestiona el proveedor |
| Escalado | Planificado por ti | Incluido |

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.

## Preguntas frecuentes

### ¿Es más barato tener un MTA propio?

En costo por mensaje, a gran volumen, sí. Pero hay que sumar IPs, servidores, monitorización, gestión de reputación y horas de ingeniería. Con volumen bajo o moderado, una API suele salir más barata en total.

### ¿Qué es el vendor lock-in en email?

La dependencia de un proveedor que hace costoso cambiar: APIs propietarias, plantillas en su formato, listas de supresión y eventos que no puedes exportar fácilmente, y firmas DKIM ligadas a su dominio.

### ¿Puedo enviar desde una instancia cloud con mi propio MTA?

Muchos proveedores cloud bloquean o restringen por defecto el puerto 25 saliente. Necesitas solicitar el desbloqueo, IPs con buena reputación y PTR configurable.

### ¿Cómo reduzco el lock-in si uso una API?

Firma DKIM con tu propio dominio, mantén una copia de tu lista de supresión, abstrae el envío detrás de una interfaz interna y prefiere proveedores con webhooks estándar.