¿En qué tres cargas se reparte el email de un SaaS B2B?
Un remitente SaaS B2B típico tiene tres cargas de email diferenciadas: (1) transaccional — códigos de acceso, restablecimientos de contraseña, confirmaciones de acciones de cuenta, avisos de facturación; (2) ciclo de vida — secuencias de onboarding, resúmenes semanales, avisos de nuevas funciones; (3) notificaciones de eventos de producto — alguien compartió un documento contigo, tu build ha fallado, tu factura está vencida. Cada una tiene requisitos de latencia distintos, perfiles de volumen distintos y consideraciones de reputación distintas. Los clientes que las tratan como una sola carga acaban con una entrega mediocre en las tres. Los que las tratan como tres cargas separadas (pools de IP separados, estadísticas separadas, webhooks separados) consiguen colocación en inbox del cuartil superior en cada una.
¿Por qué el SaaS B2B es vuestro mayor segmento de clientes?
Una buena parte de nuestros clientes son SaaS B2B: empresas que venden software a otras empresas, con el email como superficie central de producto. La razón de que se concentre aquí es el cálculo coste-beneficio: en los volúmenes típicos de un SaaS B2B en crecimiento (500K-10M de mensajes al mes), el precio por mensaje de SendGrid Pro o Mailgun se acumula más rápido que un plan de infraestructura dedicada gestionada. El problema de reputación también se concentra aquí: los buzones B2B (Microsoft 365 y Google Workspace corporativos) son más estrictos que los de consumo, así que el trabajo de entregabilidad hay que hacerlo con más cuidado.
Los patrones de integración que hemos probado.
La mayoría de los clientes SaaS B2B integran vía API REST en lugar de SMTP, con receptores de webhook que retroalimentan su propio producto (marcar una notificación como entregada en la interfaz de la app, reintentar envíos fallidos con contenido distinto). Hemos validado integraciones con los SDK de Node.js, Python, Go, Ruby, PHP y Java, además del acceso directo a la API desde cualquier lenguaje. Frameworks de aplicación habituales ya integrados: Rails, Django/FastAPI, Express, NestJS, Spring Boot, Laravel. La entrega de webhooks va firmada con HMAC-SHA256 e incluye un buffer de reenvío de 7 días, de modo que una caída breve del servicio receptor no pierde eventos.
¿Por qué Microsoft es la parte que se rompe en el buzón B2B?
Alrededor del 61% de los destinatarios B2B leen el correo en un cliente Microsoft —Outlook, Exchange Online, Microsoft 365— frente a cerca del 35% en Google, según la medición de Validity de 2025. Ese solo dato rediseña el trabajo de entregabilidad. Microsoft filtra con más dureza que Gmail y filtra de forma inconsistente, porque cada tenant de M365 superpone su propia política encima de Exchange Online Protection: Mimecast, Proofpoint, Barracuda o un conjunto de reglas propio de Microsoft Defender. El mismo mensaje desde la misma IP con SNDS en verde puede llegar al inbox en Gmail, quedarse en "Otros" en el Outlook.com de consumo y caer en la cuarentena del tenant en una de las filiales de tu cliente. Microsoft empezó a rechazar de plano el correo de alto volumen no conforme en mayo de 2025 —un 550 5.7.515 en duro en lugar de un descarte silencioso a no deseados—, así que un SPF mal alineado o una firma DKIM ausente aparece ahora como un rebote, no como un impuesto lento a la reputación. Monitorizamos la colocación por configuración de los grandes tenants con cuentas semilla que imitan los montajes Defender empresariales habituales, ajustamos el contenido frente a los patrones de SmartScreen que disparan la cuarentena de M365 y mantenemos un escalado documentado para el caso que todo remitente B2B acaba encontrando: un tenant destinatario de alto valor poniendo en cuarentena tu correo transaccional mientras todos los demás receptores lo entregan al inbox.
¿Dónde os situáis frente a Postmark, Resend, SendGrid y SES?
Perdemos operaciones frente a cuatro proveedores, y te diremos cuándo uno de ellos es la mejor respuesta. Resend tiene ahora mismo la experiencia de desarrollador más limpia de la categoría —plantillas con React Email, un SDK de TypeScript que coincide con la API exactamente, un nivel gratuito permanente de 3.000 mensajes— y para un producto en fase temprana que solo necesita transaccional, es difícil de superar. También es una capa deliberadamente fina: sin relay SMTP, sin parsing de entrante, sin gestión de suscriptores. Te quedas pequeño respecto a su alcance, no a su calidad. Postmark se hizo un nombre con la fiabilidad transaccional a través de los Message Streams, que mantienen el tráfico transaccional y el de difusión en infraestructura separada para que un envío masivo de marketing nunca retrase un restablecimiento de contraseña; por debajo de unos dos millones de mensajes al mes y sin tráfico de ciclo de vida ni de eventos de producto que consolidar, ahí dirigimos a la gente y no intentamos ganar la operación. SendGrid cubre todo el espectro y pone el precio más bajo a los volúmenes más altos, con subusuarios para la separación multi-tenant, aunque el acompañamiento en entregabilidad se adelgaza conforme bajas en sus niveles de soporte. Amazon SES es la vía más barata a escala, a unos diez céntimos por cada mil, y lo operas todo tú. Nosotros somos la opción dedicada gestionada para la franja de 500K a 10M: donde el precio por mensaje cruza por encima de un plan de infraestructura plano, donde el trabajo con el buzón corporativo necesita a una persona que sepa qué hace una política Proofpoint a nivel de tenant, y donde la residencia de datos en la UE es un requisito de compra en vez de una preferencia.
El envío multi-tenant pone el problema del vecino ruidoso sobre tu reputación.
Si tu producto envía en nombre de tus propios clientes, las consecuencias de reputación de su comportamiento caen sobre tus dominios e IPs. Los proveedores de buzón pasaron a un modelo de reputación centrado en el dominio y en el usuario a lo largo de 2024 y 2025, lo que significa que un solo tenant con una lista sucia o una tasa de quejas alta arrastra la colocación de todos los demás tenants que comparten el pool. La solución es una gobernanza que tienes que ejecutar y un instrumental que la haga posible. Soportamos un modelo de dominio propio por tenant donde cada uno se autentica bajo su propio dominio, con su propia clave DKIM y su propio return-path, de modo que la reputación se acumula por tenant en vez de agruparse en una sola responsabilidad compartida. La estratificación de tenants es habitual entre nuestras cuentas SaaS más grandes: tenants de pago en un pool premium, tenants de nivel gratuito en uno separado, para que un pico de abuso del nivel gratuito no penalice a los clientes que te pagan. El etiquetado por tenant mediante la cabecera X-OSD-Tenant-ID alimenta una API de estadísticas que responde a consultas group_by=tenant_id —colocación en inbox, tasa de quejas y tasa de rebote por tenant—, que es lo que te permite encontrar al tenant que genera quejas antes de que lo encuentren los receptores por ti. Cuando lo haces, el portal te deja limitar o poner en cuarentena el envío de ese tenant sin tocar el de nadie más.
¿Por qué los límites de tasa por tenant de Microsoft son una restricción de diseño?
Exchange Online aplica límites que muerden en cuanto tus clientes retransmiten su propio correo a través de Microsoft 365, o cuando tú envías a tenants de M365 a volumen. El Tenant External Recipient Rate Limit topa un tenant entero en 5.000 destinatarios externos al día —por tenant, no por buzón—, así que cinco comerciales de tu cliente enviando mil mensajes externos cada uno lo agotan para todos en esa empresa. Un techo separado de 10.000 destinatarios diarios cuenta internos y externos juntos, y un límite de 30 mensajes por minuto gobierna las ráfagas automatizadas con independencia de la cifra diaria. Hay una trampa más silenciosa para los clientes que enrutan el saliente a través de un tercero para gestión de firmas o archivado y luego de vuelta a Exchange Online para la entrega final: Microsoft puede contar por duplicado esos destinatarios externos, y la mitigación documentada es una regla de flujo de correo basada en la cabecera References. Diseñamos el caudal de los pools y los límites por tenant en torno a estas cifras, de modo que un evento de producto que se abre en abanico hacia unos miles de destinatarios dentro del tenant de un cliente se acompasa por debajo del límite en lugar de dispararlo y dejar parado el resto del correo de ese tenant durante el día.
Tres cargas de trabajo, tres presupuestos de latencia, tres reputaciones.
La separación entre correo transaccional, de ciclo de vida y de eventos de producto no es una cortesía organizativa; las tres tienen características de operación incompatibles. El correo transaccional —códigos de acceso, restablecimientos de contraseña, confirmaciones de pago— necesita un paso de cola a envío por debajo del segundo y un p99 medido en segundos de un solo dígito, y no puede compartir IP con nada que envíe en masa, porque un pico de quejas de marketing nunca debe retrasar un código de autenticación. El correo de ciclo de vida —secuencias de onboarding, resúmenes semanales, anuncios de funciones— va por lotes y tolera minutos de latencia, pero carga el riesgo de quejas, así que se gana su propio pool donde un mal envío degrada solo a sí mismo. El correo de eventos de producto es el irregular: un build terminado, un documento compartido, una factura vencida, abierto en abanico como hasta unos cincuenta millones de eventos diarios impulsados por webhook en toda nuestra base B2B, con ráfagas que siguen el horario laboral de tus clientes y no el tuyo. El aprovisionamiento da a cada una de las tres su propio pool aislado y calentado de forma independiente, con su propio panel de estadísticas desde el primer día. Las cuentas que colapsan las tres en un solo pool para ahorrarse un día de configuración obtienen una colocación mediocre en cada tipo a la vez, y la conversación que sigue suele ser una migración para arreglar lo que un aprovisionamiento correcto habría evitado.
Somos la capa de envío de email, no una plataforma de orquestación de notificaciones.
Los orquestadores multicanal —Courier, Knock, el Novu de código abierto— se sitúan por encima de proveedores como nosotros y enrutan una sola notificación a través de email, SMS, push e in-app, gestionan plantillas y centros de preferencias, y hacen failover entre canales. Para un producto que necesita eso, los nombramos en vez de fingir que la API lo hace. Varios de nuestros clientes corren exactamente esa topología: Knock o un Novu autoalojado por encima, nosotros como proveedor de email por debajo, elegidos por la residencia UE y la economía del pool dedicado. La línea es nítida en procurement. Un centro de preferencias de notificaciones, el agrupamiento entre canales y el batching por canal son asuntos de orquestación, y nosotros integramos por debajo de ellos. El email que llega a un buzón Microsoft corporativo a dos millones al mes y más, bajo residencia de datos UE, con los datos por tenant para demostrar la colocación, es la parte que poseemos. Mecánicamente la integración es anodina, que es justo el punto: el orquestador llama a nuestro endpoint de envío con el mensaje renderizado y una etiqueta de tenant, nosotros devolvemos un ID de mensaje, y nuestros webhooks devuelven el estado de entrega para que el orquestador decida si escalar a otro canal. Estar por debajo de una capa de orquestación no cambia nada de la arquitectura de pools, la contabilidad de reputación por tenant ni las garantías de residencia UE: se mantienen tanto si la llamada se origina directamente en tu aplicación como en un flujo de Knock tres saltos más arriba. Mantener ese alcance es deliberado: un Novu autoalojado más nuestra API deja tanto la lógica de notificación como los datos de email en infraestructura que tú controlas, que es la configuración en la que suele aterrizar un comprador sensible a la privacidad.