Infraestructura email para plataformas SaaS que envían en nombre de miles de clientes
Cuando uno de tus tenants compra una lista, le hackean la cuenta o simplemente tiene mala higiene de envío, el daño debería quedarse en ese tenant — no extenderse a toda la plataforma. La mayoría de los setups con IPs compartidas falla esa prueba. Nosotros entregamos los primitivos de aislamiento por tenant que sí contienen el daño, con DPA en castellano y datos en la UE.
Las IPs compartidas se diseñaron para el caso donde un único remitente controla el contenido. SaaS multi-tenant nunca fue ese caso.
Tienes una plataforma SaaS. Quizás un software de facturación electrónica para autónomos en España, una herramienta de gestión inmobiliaria para administradores de fincas, una solución de help-desk para PYMEs en LATAM, una plataforma de citas para clínicas dentales. Tus clientes son pequeñas empresas que dependen de tu producto para enviar recordatorios de cita, notificaciones de factura, recuperaciones de contraseña, respuestas de soporte. El volumen agregado es relevante — un par de millones al mes es habitual — pero ningún cliente individual envía mucho. La tentación es enchufar SendGrid o Brevo, compartir un pool de IPs entre todos tus tenants, y dar el problema del email por "resuelto".
No lo está. Un pool de IPs compartidas significa una reputación compartida. Un spammer, una cuenta hackeada, un cliente que decide subir una lista comprada — contamina la reputación de envío de todo el resto de tu plataforma. La propia documentación de SendGrid lo afirma sin rodeos. Los incidentes reales están extensamente documentados: empresas que se levantan con sus IPs compartidas bloqueadas en Microsoft, tasas de entrega cayendo por debajo del 30%, y recuperaciones que se alargan semanas.
El caso de Instructure (Canvas) en marzo de 2026 ilustra el patrón a otra escala: una sola brecha en el vendor multi-tenant comprometió a 9.000 instituciones educativas simultáneamente, incluida la Universitat Oberta de Catalunya. La centralización del riesgo es estructural — no un accidente. Y antes, en enero de 2025, PowerSchool había expuesto datos de hasta 62 millones de estudiantes por la misma razón arquitectónica. La capa de email es el punto donde estas concentraciones de riesgo se manifiestan más rápido y de forma más visible.
El cambio de reputación basada en IP a reputación basada en dominio que llegó con el bulk-sender mandate de Gmail/Yahoo en 2024 (y las reglas paralelas de Microsoft en 2025) ayuda algo — el aislamiento por subdominio es ahora una palanca real — pero no resuelve el problema de fondo. Los receptores siguen agregando señales sobre infraestructura compartida. Y la mayoría de plataformas no había operacionalizado los controles a nivel de dominio que esos mandates exigen.
Para plataformas con presencia en España y LATAM hay un agravante regulatorio. La LOPD-GDD española (Ley Orgánica 3/2018), la LGPD brasileña y la LFPDPPP mexicana exigen niveles específicos de protección de datos personales y trazabilidad de transferencias internacionales. Cuando tu proveedor de email es un actor estadounidense que pasa los datos por sus regiones US-East, el ejercicio de cumplimiento no es trivial — y los procurement de tus clientes empresariales medianos te lo van a pedir documentado.
En agosto de 2025, AWS lanzó Amazon SES Tenants — aislamiento explícito por tenant con políticas de reputación que pueden pausar a un tenant problemático antes de que tumbe a los demás. El lanzamiento del producto validó el diagnóstico: la arquitectura existente era estructuralmente inadecuada para el envío SaaS-on-behalf, y los clientes habían cargado con el coste durante años. Brevo (Francia) es el referente europeo más maduro pero su modelo de subaccounts es menos granular. Postmark, Mailgun y SendGrid soportan sub-cuentas en distintos grados, pero la automatización de contención de abuso es desigual.
El coste de fallar es concreto y mensurable. La literatura de entregabilidad sugiere que cada 1% de correo filtrado a spam representa unos $1.200 de revenue perdido por remitente activo. La recuperación de un blocklisting serio está documentada en dos semanas a seis meses. Una semana de email caído para un equipo comercial de veinte personas que corre su outbound a través de una plataforma contaminada son más de $50.000 de pipeline. Multiplica eso por toda tu base de tenants si su email se cae por culpa del comportamiento de otro.
¿Cuánto cuesta realmente un tenant tóxico al resto de tu plataforma?
Mueve los sliders para modelar tu situación. Las matemáticas usan las cifras de revenue perdido y tiempo de recuperación publicadas en la literatura de entregabilidad; no es una garantía, pero es el orden de magnitud correcto.
Fórmula: volumen_por_tenant × tenants × spam_fold% × €0,04 (margen bruto medio por email entregado en SaaS transaccional) × (días_recuperación / 30). Es orden de magnitud — sustituye tu propio valor por email si lo conoces.
Una arquitectura con aislamiento por tenant limita esa cifra a la exposición individual del tenant afectado — típicamente dos o tres órdenes de magnitud menor. Ese es el argumento para diseñar la arquitectura bien antes del primer incidente, no después.
Tres patrones reales. Soportamos los tres. El correcto depende del mix de tu base de tenants.
No hay respuesta universal correcta, pero hay tres respuestas que vemos repetirse en plataformas SaaS hispanas — y la elección suele correlacionar con la madurez de los tenants, la exposición regulatoria (especialmente para fintech, salud y administraciones públicas) y cuánta varianza existe en el comportamiento de envío de tus clientes.
IPs compartidas entre tenants, segmentación por dominio
Todos los tenants comparten un pool. Subdominios y claves DKIM por tenant son el único aislamiento. Lo más barato de operar, lo más débil en contención.
- Ideal para
- SaaS early-stage, tenants de bajo volumen
- Coste
- El más bajo
- Daño máximo
- La plataforma entera
Un tenant tóxico tira el pool. Riesgo aceptable solo si puedes vetar tenants de cerca o tu volumen agregado es lo suficientemente bajo para sobrevivir una caída breve.
Tiered: tenants standard en pool, premium en IPs dedicadas
Tenants default comparten pool; los que pagan tier premium (o cruzan un umbral de volumen) reciben IP dedicada. El patrón dominante en el SaaS español maduro de 2026.
- Ideal para
- SaaS mid-stage con varianza de volumen
- Coste
- Moderado, escala con tenants premium
- Daño máximo
- Solo tenants en pool (premium aislados)
El aislamiento premium como feature pagada alinea el coste con quien lo valora. Los tenants en pool siguen compartiendo destino, así que la detección de abuso tiene que ser muy fina del lado del pool.
IP dedicada por tenant desde el tier de entrada — aislamiento completo
Cada tenant recibe su propia IP dedicada (o par) más subdominio propio más claves DKIM propias. El daño máximo de cualquier incidente es un solo tenant.
- Ideal para
- SaaS regulado (banca, salud, administraciones)
- Coste
- Más alto por tenant; más bajo por incidente
- Daño máximo
- Un solo tenant
El pricing tiene que absorber el coste por tenant. Solo funciona para SaaS que apunte a mid-market y arriba. Por debajo de unos $500/mes por tenant, las matemáticas se ponen incómodas.
Envío SaaS-on-behalf comparado, abril 2026
| Proveedor | Primitivo de aislamiento por tenant | Auto-pausa con tenant tóxico | Operador UE | IP dedicada desde |
|---|---|---|---|---|
| Authorize Hosting Stockholm, desde 2003 | Subcuenta + pool de IPs dedicadas por tenant, configurable desde 1 IP/tenant hasta N pools. Reputación aislada por IP y por subdominio. | Sí — equipo de operador más rate limiting automático sobre el tenant afectado solamente | Sí — Stockholm + Frankfurt. DPA en castellano disponible. | Plan de entrada (€399/mes, 10 IPs dedicadas incluidas) |
| Brevo (ex-Sendinblue) París, Francia | Subaccounts en planes superiores, segregación por dominio. Reputación a nivel de cuenta principal. | Reglas configurables a nivel cuenta, manuales a nivel subaccount | Sí — referente europeo, infra francesa, cumplimiento GDPR nativo | IP dedicada a partir del plan Business Custom (a consultar) |
| Amazon SES Tenants lanzado ago 2025 | Feature Tenants: hasta 10K (default) o 300K (a petición) tenants aislados por cuenta. Cada tenant con identidades, configuration sets, IP pools. | Sí — políticas Standard / Strict / None con pausa automática ante findings | Depende de la AWS Region. Hay regiones UE; AWS sigue siendo operador estadounidense legalmente. | $24,95/IP/mes add-on; recomiendan una IP por ~50K emails/día |
| SendGrid (Twilio) adquirido 2019 | Subusers (hasta 25K) y "teammates" con credenciales scoped | Manual desde dashboard; sin auto-enforcement a nivel subuser por defecto | No — operador estadounidense (Twilio) | Tier 100K+ ($89,95/mes) más IP add-on; free tier eliminado el 27 de mayo de 2025 |
| Mailgun (Sinch) adquirido 2021 | Subaccounts en plan Scale; segregación por dominio en otros tiers. Tiene región EU como producto separado. | Webhooks de complaints; el enforcement es del lado del operador | Región EU disponible — matriz sueca (Sinch), ops US | Plan Scale ($90/mes+) más $59/IP/mes |
| Postmark (ActiveCampaign) adquirido may 2022 | Arquitectura multi-server; los Message Streams aíslan transaccional de broadcast. Endpoint EU disponible. | Pre-aprobación estricta; perfiles broadcast y B2B detectados al vetting | Endpoint EU disponible — operador US (ActiveCampaign) | $50/IP/mes con mínimo 300K mensajes mensuales por IP |
Pricing y datos de feature verificados contra páginas de los proveedores en abril 2026. Detalles del producto SES Tenants tomados de los lanzamientos AWS (agosto 2025 y follow-up noviembre 2025). Eliminación del free tier de SendGrid anunciada y efectiva 27 de mayo de 2025. Pricing pay-as-you-go de Mailgun duplicado en diciembre de 2025. Brevo posiciona sus IPs dedicadas como add-on bajo cotización.
El stack real debajo de tu plataforma SaaS
El producto debajo de un engagement SaaS multi-tenant con nosotros es el mismo stack PowerMTA gestionado por operador que enviamos a cualquier otro cliente de infraestructura dedicada, configurado para el caso multi-tenant. Las piezas:
- Configuración vMTA por tenant Cada tenant mapea a uno o varios MTAs virtuales en PowerMTA. Cada vMTA tiene su propia asignación de IPs, su perfil de rate-limit por receptor, y su árbol de clasificación de bounces. La telemetría de reputación se recolecta por vMTA, no por cuenta — eso es lo que permite aislar un tenant sin afectar a los demás.
- Subdominio + clave DKIM por tenant Los tenants envían desde
acme.tu-plataforma-mail.como desde su propio dominio delegado a nosotros vía CNAME. Las claves DKIM se generan por tenant. El enforcement Gmail/Yahoo de 2024 y las reglas de Microsoft de 2025 se construyeron alrededor de señales a nivel dominio; la arquitectura va con esa corriente. - Motor de políticas de reputación Umbrales por tenant para complaint rate (objetivo 0,1% por defecto, 0,3% pausa dura), bounce rate, y listings DNSBL. Cuando un tenant cruza un umbral, ese tenant se pausa. Los demás tenants en tu plataforma no se ven afectados. La mesa de operador en Stockholm recibe la alerta inmediata.
- Ingesta de FBL por IP Yahoo, AOL, Hotmail, Microsoft 365, La Poste, Comcast feedback loops registrados por IP asignada. Los complaints se rutan al tenant originario — no se agregan globalmente — por lo que la detección de abuso tiene la señal correcta a la granularidad correcta.
- Monitoreo Spamhaus + DNSBL diario Cada IP asignada se chequea contra 50+ DNSBLs a diario. Las listings las remediamos nosotros, no tú. El trabajo de remediación — el ticket SBL, la solicitud CSS, el email a delisting@ — es lo que hacemos; tu equipo no necesita reconstruir esa capacidad internamente.
- DPA, soberanía de datos y compliance UE Contrato de encargado de tratamiento (DPA) según RGPD Art. 28, en castellano si tu equipo legal lo prefiere. Datos en Stockholm primario, Frankfurt secundario — sin transferencias a terceros países por defecto. Para clientes españoles, el DPA cubre la LOPD-GDD; para clientes de Brasil cubre la LGPD; para México cubre la LFPDPPP por extensión contractual.
- Canal de escalado a operador Cuando llega un incidente real — tenant comprometido, IP bloqueada en Microsoft, Spamhaus listando un /24 — hay un teléfono de Stockholm y un canal Slack que va a humanos que hacen esto para ganarse la vida. No una cola de tickets con SLAs que se ven bien en la página del contrato pero no en producción.
Cómo se cotiza un engagement SaaS multi-tenant típicamente
SMTP Relay base + IPs por tenant
El setup de partida para SaaS con un par de millones de volumen agregado. Nuestro SMTP Relay Pro base (€749/mes, 20 IPs dedicadas, 5 dominios) te da la infraestructura del operador; asignamos IPs contra tenants conforme onboardas.
Ver SMTP RelayPowerMTA Gestionado Pro
Donde aterrizan la mayoría de engagements SaaS multi-tenant. Tier Pro (€1.499/mes) incluye licencia PowerMTA, servidor Xeon Gold 6326, 64GB ECC, 20 IPs dedicadas, 150K msg/hr de throughput. Mapeamos tenants 1:1 o 1:N sobre vMTAs según el volumen.
Ver PowerMTA GestionadoEnterprise custom
Por encima de 50 millones agregados al mes, la conversación arranca por la distribución real de tenants: cola larga 80/20, distribución pareja, crecimiento rápido — esas formas llevan a estrategias distintas de asignación de IPs. Cotización custom basada en números reales.
Habla con un operadorLo que los equipos SaaS multi-tenant nos preguntan antes de mover
¿Atendéis en castellano? Nuestro equipo legal y de procurement no negocia bien en inglés.
+
Sí. Tenemos un operador de habla nativa española en el equipo (Latinoamérica) que conduce las conversaciones técnicas, comerciales y la negociación del DPA en castellano. La operación 24/7 sigue siendo en inglés — los incidentes a las 3am no esperan a ningún horario — pero todo el ciclo comercial, contractual y de architecture review se hace en tu idioma. Y si alguna vez tu equipo legal pide el DPA traducido y revisado, tenemos versión castellana lista.
¿Cómo gestionáis el cumplimiento RGPD/LOPD-GDD para nuestros tenants?
+
Nosotros somos el encargado de tratamiento (procesador); vosotros sois el responsable (controlador) frente a vuestros tenants. Si vuestros tenants tratan datos de sus propios usuarios finales, ellos quedan como responsables de esos datos y vosotros como sub-encargado. Nuestro DPA estándar está construido para esa cadena tripartita y cumple los requisitos del Art. 28 RGPD y la LOPD-GDD española. Para clientes brasileños lo extendemos a LGPD; para mexicanos a LFPDPPP; para Colombia, Argentina, Chile y Perú adaptamos las cláusulas a la regulación local. Centros de datos en la UE por defecto (Stockholm + Frankfurt). Sin transferencias a terceros países a menos que tu contrato lo opte explícitamente.
¿Podemos onboardear tenants programáticamente o cada uno es un paso manual?
+
Programático. La creación del tenant, la asignación de IPs dentro de un pool existente, la generación de claves DKIM, y el routing de subdominio se hacen vía nuestra API de control. Los primeros diez tenants se configuran junto con nuestro equipo para validar la forma de la integración. Después provisionas contra la API por tu cuenta y nos avisamos cuando el conteo cruza el siguiente umbral de asignación de IPs.
¿Qué pasa cuando un tenant tiene su reputación tirada un domingo a las 2am?
+
El rate limiting automático sobre la vMTA de ese tenant entra en pocos minutos — basado en los umbrales de complaint-rate, bounce-rate o DNSBL-listing que configuraste en onboarding. La rotación de on-call de Stockholm recibe el page con el ID del tenant, el trigger y el estado actual. Los demás tenants en tu plataforma no ven impacto.
Si el trigger es un blocklist transitorio (CSS suele resolverse solo en 24-48h), normalmente esperamos y documentamos la causa. Si es un incidente real de abuso — lista comprada, cuenta comprometida — trabajamos contigo en la remediación a nivel del tenant. Respuesta de operador, no un bot de tickets.
¿Cómo escala el pricing al sumar tenants? ¿Es un fee por tenant?
+
No hay fee por tenant. El pricing escala con la infraestructura: cuántas IPs, cuántos dominios, cuánto throughput PowerMTA. El plan Pro a €1.499/mes incluye 20 IPs dedicadas y 150K msg/hr; Enterprise a €2.799/mes incluye 30 IPs y 500K msg/hr. El precio no se mueve si esas IPs las distribuyes entre 50 o 500 tenants. Por encima de unas 30 IPs pasamos a cotización custom para conversar la forma de tu tenant base.
Estamos pensando entre Brevo y Authorize Hosting. ¿Cuándo conviene cada uno?
+
Brevo es excelente cuando lo que necesitas es una plataforma multi-canal — email + SMS + WhatsApp + CRM ligero — para tu propia operación o la de tus clientes vía API. Para SaaS multi-tenant que quiere primitivos de aislamiento finos (vMTA por tenant, IPs dedicadas desde la entrada, políticas de reputación granulares), nuestro stack PowerMTA gestionado da más control y mejor contención. Las dos cosas no compiten 1:1; muchas plataformas españolas usan Brevo para email marketing del propio SaaS y nos usan a nosotros para el envío transaccional de los tenants. Ese split funciona bien.
¿Pueden nuestros clientes usar sus propios dominios de envío?
+
Sí. Dominios custom delegados a nosotros vía CNAME (típico para provisioning de SPF y DKIM), con alineación DMARC completa. Muchas plataformas SaaS corren dos patrones simultáneamente: tenants en un subdominio propio de la plataforma para el caso casual, y tenants que les importa lo suficiente como para configurar su propio dominio para el caso premium. Ambos patrones funcionan; el pricing no cambia.
¿Cómo es la migración desde SendGrid Subusers o Mailgun Subaccounts?
+
Dos semanas en paralelo es lo típico. Semana 1: dual-send a través de ambos proveedores para los mismos tenants, comparando métricas de entregabilidad por receptor. Semana 2: mover los tenants fáciles dejando los más arriesgados (alto volumen, historial de mala reputación) en el viejo proveedor un ciclo más. Para la semana 3 la mayoría de plataformas ya están totalmente movidas y fuera del contrato anterior a final de mes. El warmup de IPs es lo que dicta el ritmo — IPs dedicadas nuevas necesitan 14 a 28 días antes de cargar volumen completo, y eso no se negocia con los receptores.
La conversación de arquitectura es el siguiente paso correcto
Cuéntanos tu conteo de tenants, tu volumen agregado, tu proveedor actual, y la forma aproximada de tu mix de clientes. Volvemos con una configuración dimensionada y un plan de migración, no con un placeholder de "contact sales".