Postfix
Código abiertoEl MTA por defecto en Linux; cubre la inmensa mayoría de los envíos.
FortalezasGratis, estable y conocido por casi cualquier administrador.
Cuidado conEl modelado por ISP y el aislamiento a gran escala cuestan trabajo manual.
Infraestructura de email
Servidores KumoMTAMTA de código abierto, Rust + Lua, sin tarifa por mensajeServidores PowerMTACon licencia, pools VirtualMTA, soporte del proveedorEntregabilidadWarm-up, alineación DMARC, feedback loopsServidores
Bare metal — AMD EPYCInquilino único Turin / Genoa, hasta 192 núcleosServidores GPU e IANVIDIA Blackwell B200 / H200, PCIe Gen5VPSInstancias por núcleo sobre los mismos hosts EPYCCloud y red
CloudInstancias por horas, snapshots, NVMe Gen5Protección DDoSAbsorción en el borde incluida en cada servidorRed y regionesÁmsterdam · Fráncfort · Londres · AshburnInfraestructura de email
La infraestructura de email es el conjunto de capas que lleva tu correo desde la aplicación hasta la bandeja de entrada: el MTA que encola y envía, los pools de IP, la autenticación SPF, DKIM y DMARC, la red y la protección DDoS por debajo, y la monitorización que vigila la reputación. Alojamos y operamos KumoMTA y PowerMTA en servidores de inquilino único, y te damos consejo honesto de construir-o-comprar: incluso cuando un servicio gestionado o un simple Postfix es la mejor opción para ti.
En breve
Es la base técnica completa que mueve el correo a escala, y son cinco capas trabajando juntas. El MTA —el agente de transferencia de correo— encola los mensajes y los entrega. Las IPs y los pools deciden desde qué reputación sales. La autenticación, con SPF, DKIM y DMARC, demuestra a los proveedores de buzón que el correo es tuyo. La red y la protección DDoS por debajo mantienen el servicio accesible y limpio. Y la monitorización vigila la reputación del dominio y de la IP, las quejas y las listas negras antes de que un problema se note.
La pregunta que la gente confunde es creer que el MTA es lo decisivo. No lo es. Un MTA potente sobre una IP sucia y con autenticación rota cae en spam; un Postfix humilde sobre una IP limpia, bien autenticada y con los flujos separados, entrega. Por eso una buena infraestructura se juzga por cómo trata la reputación y la autenticación, no por la marca del motor de envío. En el mercado hispanohablante, donde Gmail, Outlook y Yahoo concentran la mayoría de los buzones, esas reglas las ponen ellos, cambian sin avisar y se aplican igual escribas en español o en inglés.
Vale la pena insistir en el orden: primero la reputación y la autenticación, después el motor. Un equipo que dedica semanas a elegir entre MTAs y descuida el calentamiento de su IP tendrá peor entrega que otro con un Postfix sencillo pero una reputación cuidada. El motor importa a gran volumen, pero se elige después de tener resueltas las capas que de verdad deciden la bandeja, no en su lugar.
Antes de elegir un producto hay una bifurcación, y se decide por el volumen y por si tienes a alguien que opere. Puedes dejar que un proveedor gestionado envíe por ti, donde el MTA, las IPs y la operación de entregabilidad llegan en una sola factura. Puedes correr tu propio servidor dedicado con una IP calentada cuya reputación es tuya, mientras un proveedor lleva la fontanería. O puedes auto-hospedar el MTA entero y ser dueño de cada parte, incluidas las que fallan a las tres de la madrugada.
La regla general es honesta: por debajo de unos 25.000 mensajes al mes, o sin personal técnico, un servicio gestionado casi siempre sale más barato cuando cuentas las horas. Desde unos 50.000 al mes con capacidad básica de operación, auto-hospedar empieza a compensar, y a gran volumen puede salir varias veces más barato por mensaje —siempre que alguien lo mantenga sano. El coste real de auto-hospedar nunca es el servidor: es el tiempo de operación, el calentamiento, la monitorización y el incidente ocasional. Quien lo olvida acaba pagando más que el servicio que quería sustituir.
Hay un matiz que conviene dejar claro: auto-hospedar no significa montarlo en soledad. El camino medio —un servidor dedicado con IP propia que opera un proveedor— te da la reputación en propiedad sin cargar con la guardia nocturna. Para muchas empresas hispanohablantes que han superado el plan compartido pero no quieren un equipo de entregabilidad propio, ese término medio es justo el punto correcto.
Conviene mirar de frente lo que implica el día a día, porque es donde se gana o se pierde la reputación. Calentar IPs nuevas lleva semanas, subiendo el volumen poco a poco para que los proveedores construyan confianza. La autenticación —SPF, DKIM, DMARC y el DNS inverso— hay que dejarla impecable y vigilarla. Las quejas y los rebotes se clasifican y se actúa sobre ellos a diario, y las listas negras se vigilan para salir de ellas rápido. No es trabajo de lanzamiento; es una disciplina continua.
Cuando alojas con nosotros, esas cinco capas dejan de ser tu problema de ensamblaje y pasan a ser nuestra operación. Por eso enmarcamos la decisión con números y no con adjetivos: si tu volumen y tu equipo dicen "gestionado", lo decimos; si dicen "auto-hospedado", lo operamos bien. La meta es correo que aterriza donde debe, medido en tu propio panel, no prometido en un folleto.
La ubicación en la bandeja la deciden la reputación y la autenticación, no la velocidad. Los grandes proveedores —Gmail, Outlook/Hotmail y Yahoo, que concentran los buzones del mundo hispanohablante— puntúan la IP y el dominio desde los que envías, comprueban que SPF, DKIM y DMARC concuerden, y sopesan cómo reacciona la gente: aperturas, marcas de spam, bajas. Desde 2024, además, exigen a los remitentes de gran volumen (a partir de unos 5.000 mensajes diarios a una misma marca) autenticación completa, DMARC y una baja en un clic.
Nada de eso lo gana el MTA por ti. Lo ganan una IP limpia, una autenticación impecable, un calentamiento con calendario y la separación de flujos para que una campaña no hunda tus recibos. Por eso la entregabilidad es una disciplina diaria —clasificar rebotes, atender quejas, salir rápido de las listas negras— y no una casilla de lanzamiento. La montamos contigo desde el primer día y la medimos en tu propio panel, no en un cuadro de marketing suavizado.
Los motores
La pregunta no es cuál es el "mejor" MTA en abstracto, sino cuál encaja con tu volumen, tu equipo y tu modelo de soporte.
El MTA por defecto en Linux; cubre la inmensa mayoría de los envíos.
FortalezasGratis, estable y conocido por casi cualquier administrador.
Cuidado conEl modelado por ISP y el aislamiento a gran escala cuestan trabajo manual.
MTA moderno de alto volumen, configurado como código en Lua.
FortalezasSin licencia, con modelado de tráfico y colas por inquilino integrados.
Cuidado conComunidad más joven; conviene tener operación de correo interna.
El estándar comercial establecido durante dos décadas.
FortalezasMaduro, con soporte del proveedor y el modelo VirtualMTA conocido.
Cuidado conLicencia recurrente; el futuro del soporte es incierto tras pasar a Bird.
Con frecuencia suficiente como para que lo recomendemos cuando encaja. Si envías volumen modesto, no tienes a nadie para operar un servidor, o necesitas una interfaz de marketing y plantillas más que control, un proveedor gestionado es la mejor opción —y preferimos señalártelo a venderte un servidor que no necesitas. En el mercado hispanohablante hay opciones sólidas; las de abajo no son nuestras para vender, están aquí para que la decisión sea honesta.
Plan gratis; planes de pago económicos
Ideal paraPymes en español: suite todo-en-uno, soporte y documentación en español, cumple el RGPD.
~10 €/100K, el más barato a escala
Ideal paraEquipos con desarrollo que ya usan AWS y buscan coste mínimo; la entregabilidad la llevas tú.
Por niveles según volumen
Ideal paraTodoterreno con funciones de marketing; IP dedicada en planes altos.
IP dedicada desde ~90 €/mes
Ideal paraEquipos técnicos que quieren una API fuerte y logs detallados.
Generoso gratis; ~0,84 €/1.000
Ideal paraTransaccional de bajo coste, sin límite diario de envío.
El patrón bajo todo esto: un servicio gestionado te vende capacidad y comodidad y te oculta el MTA; auto-hospedar te entrega el motor y la responsabilidad. Ninguno es una elección moral. Es una decisión operativa, y cambia según creces.
Cuando alojas con nosotros, las cinco capas se vuelven nuestras de operar. El MTA es KumoMTA o PowerMTA sobre hardware AMD EPYC de inquilino único, afinado a tu perfil de envío. Los pools de IP se disponen por flujo, cada uno atado a una dirección dedicada con DNS inverso correcto, y los calentamos contigo. La autenticación y la entregabilidad corren como disciplina continua, no como lista de lanzamiento. La red aporta rangos limpios y absorción de DDoS siempre activa. Y la monitorización lo ata todo, llevando los eventos de entrega, rebote y queja a tus propios sistemas para que tu vista coincida con la nuestra.
La monitorización merece una mirada de cerca, porque es donde se cazan o se escapan la mayoría de los problemas de reputación. Vigilamos Google Postmaster Tools y los datos de remitente de Microsoft para la reputación de dominio e IP, los feedback loops para las quejas, las listas negras por si aparece un listado temprano, y las señales de ubicación en bandeja para saber dónde llega de verdad el correo. Cuando un número se desvía, lo rastreamos hasta el flujo que lo causó en vez de responder con una ralentización brusca que castiga al correo que iba bien.
Arquitectura de referencia
Tu aplicación entrega el correo al MTA, que lo asigna a un pool por flujo, lo firma y marca el ritmo de entrega a cada proveedor. Los eventos vuelven a tus sistemas y a la monitorización. El principio que sostiene todo el diseño es el aislamiento de flujos: transaccional, marketing y frío nunca comparten reputación.
# diseño de referencia — aislamiento de flujos por reputación
dominios:
tx.ejemplo.com # transaccional · debe llegar
mail.ejemplo.com # marketing · alto volumen
reach.ejemplo.com # frío / reactivación · aislado
pools:
- nombre: transaccional
mta: kumomta
ips: [ 198.51.100.21 ]
nota: "pequeño, siempre caliente, nunca comparte con marketing"
- nombre: marketing
mta: kumomta
ips: [ 198.51.100.40, 198.51.100.41 ]
- nombre: reactivacion
mta: kumomta
ips: [ 203.0.113.10 ]
nota: "reputación separada; un mal día aquí no toca los recibos" Para que quede claro: alojamos y operamos infraestructura auto-hospedada —KumoMTA y PowerMTA en servidores de inquilino único— y no revendemos licencias de PowerMTA ni servicios gestionados como SES o SendGrid. Eso significa que ganamos cuando auto-hospedar te conviene, así que hemos intentado merecer tu confianza siendo igual de claros sobre cuándo no deberías venir a nosotros: con volumen modesto, sin equipo para operar, o cuando una interfaz de marketing pesa más que el control, un ESP es la mejor y más barata opción.
Donde creemos que aportamos valor de verdad es en el camino medio bien hecho: ser dueño de un MTA auto-hospedado sin cargar con toda la operación, sobre espacio de IP limpio y con aislamiento de flujos de fábrica, en la región que el RGPD o tus clientes te exijan. Si tus números dicen ESP, lo diremos; si dicen auto-hospedar todo, te señalamos las guías. La infraestructura correcta es la que encaja con tu envío, y a veces no somos nosotros.
En España y la UE, el envío comercial vive bajo dos marcos que conviene no ignorar. El RGPD rige el tratamiento de datos personales —y una dirección de correo lo es—, con base legal, minimización y el derecho a acceder, rectificar y suprimir. La LSSI-CE exige, por regla general, consentimiento previo para las comunicaciones comerciales por email y una forma sencilla y gratuita de darse de baja en cada envío. Cumplirlas no es solo cuestión legal: una lista consentida y limpia es, además, la que mejor entrega.
La infraestructura ayuda a cumplir. Correr sobre hardware de inquilino único en una región que eliges —la UE, por ejemplo— te da control sobre dónde residen los datos y cómo se tratan, algo que un servicio gestionado fuera de la UE complica. Mantenemos tuyos la configuración y los registros, colocamos los servidores donde el RGPD o tus clientes lo exijan, y dejamos el procesamiento de bajas y supresiones cableado en el MTA, no improvisado en el último momento.
La resolución más limpia rara vez es un extremo. Muchos remitentes mantienen el correo transaccional crítico —recibos, restablecimientos de contraseña, códigos— en un servicio premium por fiabilidad, corren el marketing de alto volumen en infraestructura auto-hospedada por coste, y aíslan el tráfico frío o de reactivación en una reputación aparte para que un mal día allí no toque nada importante. Operamos con gusto el lado auto-hospedado de un híbrido así, y te decimos qué dejar en gestionado.
Preguntas
Lo que se pregunta antes de comprometer una infraestructura de correo.
Es todo el stack que lleva el correo desde tu aplicación a la bandeja de entrada: el MTA que encola y envía, las IPs y pools desde los que sale, la autenticación SPF, DKIM y DMARC, la red y la protección DDoS por debajo, y la monitorización que vigila la reputación. Un servicio gestionado lo empaqueta todo en una factura; montar el tuyo significa ensamblar y operar cada capa.
Depende del volumen y de si tienes a alguien para operarla. Por debajo de unos 25.000 mensajes al mes, o sin personal técnico, un servicio gestionado casi siempre sale más barato cuando cuentas las horas. A partir de unos 50.000 al mes con capacidad básica de operación, auto-hospedar empieza a compensar, y a gran volumen puede salir varias veces más barato por mensaje, siempre que alguien lo mantenga sano.
Por debajo de unos 500.000 mensajes al día, un Postfix bien afinado lo lleva. De ahí a unos pocos millones al día, KumoMTA suele ser la mejor opción: código abierto, sin licencia, con modelado de tráfico y colas por inquilino integrados. Por encima, o donde se exija un contrato de soporte del proveedor, PowerMTA sigue siendo la opción comercial establecida. Alojamos y operamos KumoMTA y PowerMTA y te diremos con honestidad cuál encaja.
En rendimiento y modelado de tráfico, la distancia se ha cerrado: KumoMTA lo construyeron antiguos ingenieros del mundo del MTA comercial y lo iguala en la mayoría del trabajo de alto volumen. Las diferencias que quedan son madurez del ecosistema y modelo de soporte: PowerMTA tiene décadas de herramientas y una amplia red de socios, mientras que KumoMTA cambia parte de eso por acceso al código y cero coste de licencia.
Más que el servidor. Un VPS cuesta unos pocos euros al mes, pero el coste real es la operación: parches, monitorización, calentamiento y algún incidente. En torno a 1,4 millones de mensajes al mes, un montaje auto-hospedado bien llevado cuesta de forma realista unos pocos miles de euros al mes con todo incluido, la mayor parte el ingeniero a tiempo parcial que lo mantiene sano, no el software, que puede ser gratis.
Sí, y a menudo es lo más inteligente. Muchos remitentes mantienen el correo transaccional crítico en un servicio premium por fiabilidad, corren el marketing de alto volumen en infraestructura auto-hospedada por coste, y aíslan el tráfico frío o de reactivación en una reputación aparte. Operamos con gusto el lado auto-hospedado de un híbrido así.
No. Alojamos y operamos infraestructura auto-hospedada —KumoMTA y PowerMTA en servidores de inquilino único. Cuando un proveedor gestionado encaja de verdad mejor con tu volumen o tu equipo, te lo decimos con claridad, aunque no sea lo que vendemos.
Correr tu propia infraestructura en hardware de inquilino único en una región conocida te da control sobre dónde residen los datos y cómo se tratan, lo que importa bajo el RGPD y la LSSI-CE en España, y regímenes como PCI DSS y DORA. Colocamos los servidores en la región que necesites —la UE, por ejemplo— y mantenemos tuyos la configuración y los registros.
Una llamada corta, un dimensionamiento y una respuesta honesta —incluso cuando la respuesta es un ESP o gastar menos. Sin presión, sin licencias revendidas.