Para empresa con volumen alto que ya pasó el punto donde un ESP estandarizado tiene sentido económico, pero que no quiere construir un equipo de deliverability senior interno para operar el MTA. Servidor bare metal europeo (Intel Xeon o AMD EPYC con ECC RAM y NVMe) con el MTA elegido instalado y operado por nuestro equipo: configuración, optimización, parcheado, monitoreo continuo, gestión de IPs dedicadas con calentamiento incluido, integración con tu aplicación. Operamos PowerMTA desde 2009, KumoMTA en producción desde la beta de 2023, MailerQ para clientes con stack pesado en RabbitMQ. Pricing público a partir de €499 al mes para entry, €1.499 para operación profesional.
En breve
El umbral económico donde un MTA dedicado tiene sentido frente a ESP estandarizado se cruza alrededor de 5 a 10 millones de emails al mes. Por debajo, el ESP entrega valor (tooling de marketing, dashboards, soporte de developer, escalado automático) que justifica el coste por email. Por encima de ese umbral, el ESP se vuelve caro y el control técnico que ofrece es limitado. Las empresas que cruzan el umbral típicamente toman una de tres rutas. Ruta uno: contratar ingeniero senior de deliverability interno (€80.000 a €150.000 al año fully-loaded en mercado europeo) para operar PowerMTA, KumoMTA o MailerQ. Ruta dos: continuar con ESP aceptando el coste alto. Ruta tres: contratar el MTA totalmente operado por proveedor externo. Esta tercera ruta es donde encajamos.
El servicio incluye: hardware bare metal en datacenter europeo (entre los siete PoPs disponibles, el cliente elige según latencia objetivo y jurisdicción preferida), MTA instalado y configurado por nuestro equipo (KumoMTA por defecto en builds nuevos, PowerMTA cuando el procurement exige licenciamiento comercial, MailerQ cuando hay stack pesado de RabbitMQ), bloque IP dedicado con calentamiento incluido, configuración SPF/DKIM/DMARC para tu dominio, integración con tu aplicación vía API o cola de mensajes, monitoreo continuo de placement con alertas accionables, parcheado del SO y MTA, gestión de incidents 24/7 según tier. Lo que el cliente no necesita: contratar ingeniero senior de deliverability, tener pager rotation interno para incidents fuera de horario, mantener herramientas de monitoreo, gestionar relación con receivers (Gmail Postmaster, Microsoft Sender Support).
La audiencia hispanohablante donde el producto entrega valor mensurable son ESPs medianos hispanos (varias plataformas españolas y latinoamericanas con plataformas locales sirviendo cliente regional), SaaS B2C grandes con email transaccional crítico (e-commerce regional, plataformas de delivery, fintech con notificaciones masivas), agencias de email marketing operando varios clientes (varias agencias hispanas con cuentas grandes), plataformas de comunicación con email como canal secundario (CRM con notificaciones, plataformas de eventos con confirmaciones masivas).
Sobre la elección entre KumoMTA, PowerMTA y MailerQ. KumoMTA es la opción por defecto para builds nuevos: open-source, escrito en Rust por ex-ingenieros de PowerMTA, performance comparable a PowerMTA con feature set completo para el 95% de los flujos de envío. PowerMTA sigue ganando cuando el procurement del cliente exige licenciamiento comercial documentado o cuando hay integraciones específicas que solo PowerMTA expone. MailerQ encaja en stacks pesados con RabbitMQ donde la integración nativa con AMQP entrega beneficios operacionales. Operamos los tres porque las preferencias del cliente varían y dejamos elegir en lugar de imponer un único MTA.
Sobre el lado tributario, factura desde Viena en EUR. Para empresa española mecanismo de inversión del sujeto pasivo (autorrepercutes IVA al 21%, neutro). Para empresa LATAM, tributación local de importación. La carga total efectiva queda entre 16% y 30% sobre el valor de la factura.
Sobre cuándo este producto encaja. Por debajo de 5 millones al mes, ESP estandarizado o nuestro Email API EU son mejor encaje económicamente. Encajamos a partir de 10 millones al mes con perfil que requiere control técnico (configuraciones MTA específicas, segregación por canal, sub-cuentas múltiples). Por encima de 100 millones al mes, el cliente probablemente debería evaluar construir equipo interno con MTA operado in-house porque la economía cambia favorablemente para infraestructura propia. La frontera entre los segmentos la discutimos en la llamada de discovery.
Sobre el contexto del mercado europeo profesional para MTA dedicado en 2026 vale dar visibilidad. Hetzner sigue siendo opción competitiva por precio (servidores dedicados desde €70 al mes con buen hardware), pero sin operación profesional del MTA: el cliente recibe el bare metal y tiene que instalar y operar el MTA internamente. OVHcloud opera en concentración de Roubaix con riesgo de incidente histórico (incendio SBG2 en marzo 2021) que el procurement serio considera. Leaseweb ofrece bare metal profesional pero sin operación MTA tampoco; vendes hardware, el cliente opera. Nuestro encaje específico es el segmento donde el cliente quiere bare metal profesional con MTA totalmente operado, que pocas opciones cubren bien en el mercado europeo.
Sobre la operación cotidiana del MTA gestionado vale clarificar qué incluye. Operación significa: parcheado del SO (Debian, AlmaLinux, Ubuntu LTS según preferencia del cliente) cada mes con ventana de mantenimiento coordinada, parcheado del MTA (KumoMTA, PowerMTA, MailerQ) cuando hay versiones nuevas con fixes de seguridad o features relevantes, monitoreo continuo de queues con alertas ante backlog acumulado, gestión de IPs en blacklist con delisting proactivo, ajuste de configuración de virtual MTA según receivers que muestran resistencia, optimización de throughput cuando el cliente escala volumen, coordinación con receivers (Gmail Postmaster, Microsoft Sender Support) cuando aplica.
Sobre la decisión específica de KumoMTA vs PowerMTA en builds nuevos durante 2026 hay observación de mercado relevante. KumoMTA salió de beta a producción a mediados de 2024 y a partir de 2025 acumuló validación en producción de operaciones de gran escala. Cliente que arranca build nuevo sin restricción de procurement típicamente elige KumoMTA por dos razones: licencia open-source que evita el coste fijo anual de PowerMTA (€30.000-€80.000 según volumen), y velocidad de desarrollo del proyecto KumoMTA que aceptó features y fixes a ritmo más alto que el desarrollo de PowerMTA en los últimos años. PowerMTA sigue ganando en clientes con procurement que exige licencia comercial documentada, integraciones específicas que solo PowerMTA expone, o continuidad operacional con setups PowerMTA legacy donde el coste de migrar no se justifica.
Sobre el modelo de operación gestionada vs operación interna en empresa hispanohablante mediana hay cálculo económico que vale documentar. Operación interna de MTA dedicado requiere: ingeniero senior de deliverability con experiencia previa (mercado europeo €80K-€150K anuales fully-loaded, mercado LATAM €40K-€80K equivalente), cobertura 24/7 con guardia rotativa que típicamente requiere 2-3 ingenieros para no quemar al equipo, hardware bare metal o cloud público con configuración específica (€500-€2.000 mensuales según workload), licencias de software (PowerMTA si aplica, herramientas de monitoreo como Datadog), tooling operacional propio que el equipo construye y mantiene. Suma anual: €150K-€400K depende del tamaño de la operación. Operación gestionada nuestra a tier Pro sale €18K anuales (€1.499 mensuales × 12), 1/10 del coste interno mid-market, con cobertura 24/7 incluida. La economía favorece gestionado para volúmenes hasta 100M emails al mes; por encima, la decisión depende de factores específicos del cliente.
Sobre la observación específica del mercado europeo de MTA gestionado durante 2024-2025. Varios competidores que vendían 'managed MTA' como producto descubrieron que el coste operacional real (cobertura 24/7, parcheado del MTA, gestión de IPs) supera lo que el pricing competitivo permite cobrar. Resultado: empresas que ofrecían el producto descontinuaron o pasaron al modelo de instalación inicial sin operación continua. Nosotros operamos el producto desde 2018 con economía sostenible porque la base de clientes es coherente con el coste estructural y porque consolidamos operación de varios clientes sobre infraestructura compartida operacionalmente (no infraestructura compartida técnicamente, que es donde el cliente perdería el valor del MTA dedicado).
Sobre la integración con stacks observability modernos que muchos clientes piden. El MTA expone métricas en formato Prometheus accesibles vía endpoint scrape estándar para Grafana, Datadog, New Relic, Splunk Observability. Logs estructurados en formato JSON exportables a SIEM (Splunk, ELK, Sumo Logic, Datadog Logs). Para clientes con plataforma de observabilidad madura, la integración permite correlacionar métricas de email con métricas de aplicación, lo que ayuda en investigación de incidentes complejos donde el síntoma aparece en email pero la causa está en una capa anterior del stack. La integración es estándar (no requiere customización por cliente) y queda disponible desde el primer día del onboarding.
Sobre el tradeoff específico entre PowerMTA y KumoMTA en clientes con licenciamiento existente. Cliente con licencia PowerMTA vigente comprada antes de la transición a Vircom puede mantener la licencia y migrar a hardware nuestro sin coste de licencia adicional. Para clientes sin licencia existente que evalúan compra nueva, KumoMTA típicamente es la mejor decisión por economía y velocidad de desarrollo del proyecto. PowerMTA mantiene ventaja específica en algunos casos: clientes con auditoría regulatoria que exige licenciamiento comercial documentado, clientes con integraciones específicas a herramientas que solo PowerMTA expone (típico setups legacy con tooling propio del cliente), clientes con relación contractual con Vircom que prefieren mantenerla por motivos comerciales.
Sobre la operación específica con receivers regionales europeos que algunos clientes priorizan. Free.fr en Francia, GMX y web.de en Alemania, Strato en DACH, Mail.ru en países bajos rusos europeos, ProtonMail con base en Suiza, Fastmail con base en Australia pero con clientes europeos relevantes. Cada uno tiene políticas de aceptación específicas que el MTA gestionado conoce y aplica. Free.fr requiere coordinación específica para volumen alto. GMX/web.de prefieren origen de IP europeo cercano (que ofrecemos). Mail.ru tiene sistema de reputación opaco que requiere validación con cuentas seed propias. ProtonMail acepta tráfico autenticado correctamente sin tooling especial. Esta cobertura granular de receivers regionales es trabajo continuo del equipo de deliverability que el cliente con MTA self-hosted típicamente no consigue mantener.
Sobre el análisis específico de operación de virtual MTAs por cliente o canal que es feature relevante para ESPs y agencias multi-tenant. KumoMTA y PowerMTA soportan nativamente la configuración de varios virtual MTAs sobre el mismo MTA físico, cada uno con su propio pool de IPs, su propia política de retry, sus propias métricas, su propio rDNS. Para ESP regional con varios clientes finales, esta capability permite segregar reputación entre clientes para que el problema de uno no contagie al otro. Para agencia con varios clientes en outbound, mismo beneficio. La configuración la hacemos durante onboarding según el modelo del cliente: cuántos virtual MTAs, qué IPs por cada uno, qué política de retry y throttling, qué métricas separadas. La operación queda transparente para el cliente que ve un dashboard con sub-cuentas pero técnicamente opera sobre infraestructura segregada que protege la reputación.
Sobre el patrón específico de migración hacia operación gestionada que vemos durante 2024-2025. Empresa con MTA propio operado internamente durante años llega a punto donde el equipo de deliverability se vuelve cuello de botella: rotación de personal con conocimiento específico, dificultad de mantener cobertura 24/7 sin quemar al equipo, dependencia de un único ingeniero senior que es riesgo operacional. La migración hacia operación gestionada nuestra libera al equipo interno para enfocarse en producto y desarrollo, mientras que la operación del MTA queda con proveedor especializado con redundancia humana (varios ingenieros con conocimiento del setup, no dependencia de individuo). Plazo de migración: 4-6 semanas con período de transición donde ambos equipos coordinan. Después del cierre, el equipo interno del cliente puede reducirse a un único ingeniero supervisor que coordina con nuestro equipo según necesidad.
Sobre la observación específica del modelo económico que diferencia operación gestionada profesional de self-managed durante 2024-2025. Self-managed con equipo interno: ingeniero senior de deliverability €100K-€150K anuales fully-loaded en mercado europeo, equipo de cobertura 24/7 con guardia rotativa que requiere 2-3 ingenieros (€250K-€400K anuales fully-loaded), licencias de software y herramientas (€20K-€60K anuales según stack), hardware bare metal (€10K-€30K anuales), tooling operacional propio que el equipo construye y mantiene (coste oculto significativo). Suma: €280K-€490K anuales para operación de un MTA dedicado mid-market. Operación gestionada nuestra a tier Pro €18K anuales (€1,499 mensuales × 12), aproximadamente 1/16 del coste self-managed mid-market. El cliente accede a equipo profesional con redundancia humana (varios ingenieros con conocimiento del setup, no dependencia de individuo) sin asumir el coste estructural completo.
Sobre la observación específica del impacto que tienen las certificaciones operacionales en procurement empresarial. Cliente enterprise post-2024 evalúa certificaciones del proveedor: ISO 27001 (gestión de seguridad de información), ISO 27018 (privacy en cloud), SOC 2 Type 2 (controles operacionales auditados continuamente), opcionalmente ISO 22301 (continuidad de negocio) y certificaciones específicas según vertical (PCI DSS para procesamiento de pagos, HIPAA equivalente europeo para healthcare). No tenemos hoy ISO 27001 ni SOC 2 propias, pero operamos los controles que esas normas auditan y entregamos evidencia pre-certificación (mapeo de controles, configuración y registros auditables). Para clientes con procurement enterprise estricto, esa evidencia documentada reduce el ciclo de evaluación frente a tener que crearla desde cero para el auditor del cliente. El valor de los controles auditables es operacional y no se limita al marketing.
Sobre el caso específico de cliente que opera ESP propio (regional o vertical) y necesita upgrade hacia infraestructura profesional. Patrón típico: empresa que construyó ESP propio durante 2018-2022 con setup ad-hoc en cloud público o servidor compartido, creció hasta volumen donde la infraestructura inicial no escala, necesita upgrade hacia bare metal profesional con MTAs commercial-grade (KumoMTA o PowerMTA según preferencia). La migración entrega valor inmediato: placement mejor por reputación de IPs nuestras vs IPs cloud público con histórico mixto, throughput superior por hardware bare metal vs containers compartidos, SLA contractual vs disponibilidad nominal del cloud público.
Sobre el caso específico de cliente con MTA propio operado durante años que llega buscando consolidación profesional sin perder configuración acumulada. Patrón observable: empresa con PowerMTA o KumoMTA operado internamente durante 5-10 años con configuración custom acumulada (virtual MTAs específicos por cliente final, queue management custom, integraciones con sistemas legacy del cliente), decide consolidar a partner profesional pero quiere preservar la configuración. La migración hacia operación gestionada nuestra incluye replicación exacta de la configuración existente en hardware nuestro con validación de funcionamiento idéntico antes del cutover. Plazo de migración: 6-10 semanas (mayor que migración estándar de 4-6 semanas) por el trabajo adicional de replicar configuración legacy. El cliente conserva inversión acumulada y gana operación profesional.
Sobre el caso específico durante 2025-2026 de empresas que evalúan KumoMTA Cloud (versión SaaS multi-tenant) vs nuestra operación gestionada de KumoMTA. KumoMTA Cloud es producto del equipo de KumoMTA que ofrece operación SaaS sobre infraestructura compartida del proveedor. La diferencia con nuestra operación: KumoMTA Cloud es multi-tenant con segregación lógica pero no física (varios clientes comparten la misma instancia subyacente), mientras que nuestra operación gestionada usa hardware dedicado por cliente con segregación completa. Para clientes con requisito de aislamiento estricto (sectores regulados, alto volumen donde el aislamiento mejora performance), nuestra operación encaja mejor.
Abajo, los perfiles concretos donde el control técnico justifica el cambio.
ESP regional (varias plataformas en España, México, Argentina) con clientes finales que tienen volumen alto y requisitos específicos. Necesita capacidad MTA dedicada por cliente sin construir el equipo de deliverability interno.
E-commerce regional, plataforma de delivery, fintech con notificaciones masivas. Cualquier interrupción de placement reduce conversión inmediatamente. Volumen entre 20 y 100 millones al mes.
Agencia hispana con 5-20 clientes finales necesitando capacidad de envío segregada por cliente. MTA dedicado por cliente final con sub-cuenta del panel.
CRM, plataforma de eventos, sistema de gestión que envía notificaciones masivas. Volumen variable estacional con picos en eventos puntuales.
Empresa que migra de SendGrid o Mailgun por motivos de Schrems II y aprovecha la migración para tomar control técnico mayor con MTA dedicado en lugar de pasar a otro ESP.
Cliente con MTA propio operando en datacenter propio donde el equipo decidió que la operación interna no escala (rotación del equipo, falta de cobertura 24/7, dependencia de un único ingeniero senior). La consolidación a partner profesional con MTA totalmente operado libera al equipo interno para enfocarse en producto en lugar de infraestructura.
El cliente recibe acceso al panel y a la API. Lo demás lo opera el equipo.
Servidor Intel Xeon o AMD EPYC con ECC RAM (típicamente 64-256 GB según tier), NVMe SSD en RAID-1 o RAID-10, alimentación redundante. PoP a elección entre los siete: Londres, Amsterdam, Frankfurt, Estrasburgo, Viena, Dallas, Panamá. Networking 10 Gbps dedicado en tiers Pro y Business.
KumoMTA, PowerMTA o MailerQ instalado, configurado y optimizado por nuestro equipo según el perfil de tu envío (transaccional vs marketing vs cold, volumen, latencia objetivo). Parcheado del MTA y SO incluido. Upgrades coordinados con ventana de mantenimiento previa al cliente.
Bloque /29 (8 IPs) en tier Standard, /28 (16 IPs) en tier Pro, /27 (32 IPs) en tier Business. Calentamiento incluido en el setup inicial (proceso de 4 a 6 semanas con curva ajustada por receiver). IPs vetadas de blacklist antes de la asignación.
Setup completo de autenticación: SPF para tus dominios de envío, DKIM con autoridad gestionada o publicada en tu DNS según preferencia, DMARC con plan de avance hasta enforcement opcional, rDNS personalizado para cada IP del bloque apuntando a tu dominio. Sin lo cual los receivers penalizan placement inmediatamente.
Vía API REST con compatibilidad SendGrid v3 y Mailgun v4 si tu aplicación habla esos. Vía SMTP estándar si prefieres simplicidad. Vía cola RabbitMQ o Kafka para integración nativa con stack message broker. Vía webhook bidireccional para eventos de delivery.
Monitoreo 24/7 vía Gmail Postmaster Tools, Microsoft SNDS, Sender Score, 50+ blacklists. Alertas accionables con runbook documentado. Gestión de incidents según SLA del tier (24/5 en Standard, 24/7 en Pro y Business). Coordinación directa con receivers cuando aplica (Gmail Postmaster, Microsoft Sender Support).
Para clientes con varios canales o varios clientes finales sobre el mismo MTA físico, configuramos virtual MTAs separados con su propio pool de IPs, su propio rDNS, su propia política de retry, sus propias métricas. La separación virtual es nativa en KumoMTA y PowerMTA y permite segregación de reputación con eficiencia operacional sobre un solo MTA físico. Útil para ESPs y agencias.
El MTA expone métricas en formato Prometheus que se pueden ingestar en sistemas de observabilidad del cliente (Grafana, Datadog, New Relic). También logs estructurados en formato JSON exportables a SIEM (Splunk, ELK, Sumo Logic). Para clientes con plataforma de observabilidad madura, la integración permite correlacionar métricas de email con métricas de aplicación, lo que ayuda en investigación de incidentes complejos.
Pricing escala con volumen mensual incluido y nivel de SLA. Compromiso mínimo de 6 meses dado el coste hundido del calentamiento inicial.
Para volumen 5-15M al mes con SLA estándar.
Ideal para
SaaS B2C escalando desde ESP, agencia con cliente único de volumen alto.
Tier que la mayoría de operaciones profesionales contrata.
Ideal para
ESP regional, SaaS B2C grande, agencia con varios clientes de volumen alto.
Para volumen 50M+ con requisitos contractuales personalizados.
Ideal para
Operación enterprise, ESP grande, plataforma con compliance regulado.
Precios mensuales antes de IVA. Compromiso mínimo 6 meses. Anual con 15% descuento. Para empresa española IVA al 21% mediante inversión del sujeto pasivo. Setup fee one-time de €999 a €2.999 según tier para cubrir el calentamiento inicial.
Para builds nuevos, KumoMTA. Es open-source, escrito en Rust, construido por ex-ingenieros de PowerMTA, y a esta altura tiene las features completas para el 95% de los flujos de envío. PowerMTA sigue ganando cuando necesitas integraciones comerciales específicas o el procurement exige licenciamiento pagado documentado. MailerQ encaja si estás en stack pesado de RabbitMQ. Operamos los tres. La respuesta honesta para la mayoría de equipos en 2026 es KumoMTA, salvo que tu procurement requiera específicamente licencia comercial.
Para algunos equipos esa es la respuesta correcta. Si tienes equipo de operaciones MTA y ya construiste el tooling operacional alrededor de tu stack, correr en AWS o Hetzner es bien. Donde ganamos es el espacio IP: AWS y la mayoría de cloud providers no te dan IPs dedicadas limpias que no hayan sido usadas para email marketing por el inquilino anterior, y el coste de reputación de empezar desde un bloque contaminado es significativo. Hetzner es mejor que AWS para IPs de envío pero las IPs todavía vienen sin validación de histórico. Nuestras IPs están vetadas antes de que las recibas, nuestra red opera más de 100.000 IPs en varias asignaciones y nunca tuvo un solo bloque listado en Spamhaus, y el equipo operacional que corre encima es el diferenciador.
Standard: 4 semanas. Setup técnico inicial 1 semana, calentamiento 3 semanas. Pro: 6 semanas. Setup 1 semana, calentamiento 4 semanas, validación 1 semana. Business: 8 a 12 semanas según complejidad. Plazo coordinado con cliente con kickoff técnico documentado al inicio.
DPA sí, firmado en onboarding para todo cliente bajo alcance del RGPD. Incluye cláusulas contractuales tipo CE, lista de sub-procesadores, mecanismos de notificación. Para empresa hispanohablante addendum con cláusulas locales (LFPDPPP México, Habeas Data Colombia, Ley 25.326 Argentina, etc). BAA para clientes adyacentes a healthcare con datos PHI sí, requiere estructura contractual personalizada y suma 1-2 semanas al onboarding.
Tier Standard: SLA 99.9%, monitoreo continuo, alerta al equipo de guardia, MTTR mediano de incidente bajo 12 minutos en los últimos 18 meses. Tier Pro: SLA 99.95%, mismo proceso con prioridad alta, integración PagerDuty con tu equipo. Tier Business: SLA 99.99%, Slack Connect dedicado, escalación inmediata a arquitecto de soluciones. Sin primera línea externalizada; quien responde es ingeniero senior con autoridad de cambio.
Sí. La migración es servicio aparte (producto Migración) que cubre exportar configuración del PowerMTA actual, reinstalación en hardware nuestro con preservación de configuraciones de virtual MTA, IP rotation, queue management, integración con tu aplicación. Plazo típico de migración: 4 a 6 semanas. Coordinación con cutover sin downtime para clientes que requieren continuidad.
Llamada de discovery de 45 a 60 minutos donde discutimos perfil de envío actual, volumen, MTA preferido, integración con tu aplicación, plazo, requisitos de procurement. Salida es propuesta concreta con tier recomendado y plazo de onboarding, o recomendación honesta de proveedor distinto si tu caso encaja mejor en otro segmento.
Política de rotación bajo control. Si una IP individual del bloque del cliente sufre listing persistente o degradación severa de placement irrecuperable, la sustituimos por otra IP limpia del pool nuestro con calentamiento previo coordinado. La rotación no es transparente para el cliente porque cambia el rDNS y SPF de esa IP específica, lo que requiere coordinación de DNS. La política es minimizar rotaciones (preferimos remediar la IP existente) y solo rotar cuando la causa raíz hace que la remediación no sea viable.
Sí, en tier Pro y Business. La configuración multi-tenant (varios virtual MTAs sobre el mismo MTA físico, cada uno con su pool de IPs, su rDNS, su DKIM, sus métricas separadas) es nativa en KumoMTA y PowerMTA. Para ESPs y agencias con varios clientes finales, esta capacidad permite segregar reputación entre clientes para que el problema de uno no contagie al otro. La configuración la hacemos durante onboarding según el modelo del cliente.
El MTA gestiona throttling automáticamente con backoff exponencial. Cuando un receiver responde con 421 (temporary throttle) o 451 (server busy), el MTA pausa envío hacia ese receiver, espera el período indicado, y reintenta con volumen reducido. El sistema mantiene quese de mensajes pendientes durante el throttling sin pérdida. Para receivers que aplican throttling persistente (típico Gmail con cuenta nueva sin warmup completo), el MTA aplica curva conservadora hasta que el receiver levanta restricciones.
PowerMTA self-managed es viable si tu equipo tiene experiencia previa con MTAs commercial-grade y disponibilidad para operarlo. El coste de licencia PowerMTA está en el rango de €30.000 a €80.000 anuales según volumen, más el coste de equipo de operaciones (1-2 ingenieros senior dedicados parcial o totalmente al MTA). El nuestro consolida licencia + hardware + operación en mensualidad predecible. Para empresa con volumen muy alto (más de 500M al mes) y equipo de operaciones existente, self-managed puede tener mejor economía. Para mid-market, gestionado es mejor.
Tier Standard: respuesta en menos de 90 minutos en mediana fuera de horario laboral europeo, sin garantía formal contractual fuera de horario. Tier Pro: respuesta en menos de 30 minutos vía PagerDuty 24/7 con guardia rotativa. Tier Business: respuesta en menos de 15 minutos vía Slack Connect dedicado 24/7 con ingeniero senior asignado. La diferencia entre tiers refleja el coste de mantener guardia 24/7 con gente capacitada técnicamente.
Tier Standard: 90 minutos en mediana fuera de horario laboral europeo, sin garantía formal contractual. Tier Pro: 30 minutos vía PagerDuty 24/7 con guardia rotativa de ingenieros senior. Tier Business: 15 minutos vía Slack Connect dedicado 24/7 con ingeniero senior asignado. La diferencia entre tiers refleja el coste de mantener guardia 24/7 con personal técnicamente capacitado para tomar decisiones operacionales sobre el MTA en producción del cliente.
El MTA en sí corre en bare metal por motivos de performance y control de IPs. Para clientes con stack Kubernetes que necesitan integración (la aplicación del cliente corre en K8s y se comunica con el MTA externo), exponemos endpoints API y SMTP que cualquier cliente Kubernetes alcanza vía service externo o ingress. La integración no requiere correr el MTA dentro de K8s; el cliente mantiene su stack y conecta con nuestro MTA como servicio externo.
Sí, parte del scope de Migración. Cliente con configuración custom de PowerMTA o KumoMTA con virtual MTAs específicos, queue management custom, integraciones con sistemas legacy del cliente, podemos replicar la configuración exacta en hardware nuestro y mantener funcionamiento idéntico al setup actual. El plazo de migración es mayor (6-10 semanas en lugar de 4-6) por el trabajo adicional de replicar configuración legacy. Útil para clientes que no quieren modernizar configuración pero necesitan migrar la operación.
Sí, en tier Business. Configuración multi-PoP donde el MTA opera en una ubicación principal pero con IPs de envío configurables por PoP geográfico. Cliente con audiencia mixta UE + EE.UU. + LATAM puede configurar IPs en Frankfurt para audiencia europea, Dallas para audiencia US-East, Panamá para audiencia LATAM, todo desde el mismo MTA central con routing geográfico. Mejora placement porque receivers prefieren IPs originadas geográficamente cerca.
Discutimos tu volumen, MTA preferido, plazo, integración. Salida con propuesta concreta o recomendación honesta de proveedor distinto.
