¿Por qué el email transaccional es un problema distinto al del marketing?
Los mensajes transaccionales —restablecimientos de contraseña, OTP de doble factor, confirmaciones de compra, avisos de envío, alertas de cuenta, recibos electrónicos, prompts SCA bajo PSD2— deben llegar en segundos desde el evento que los dispara, todos los días, sin importar la hora ni el volumen instantáneo del día. El destinatario está delante de la pantalla esperando. La tasa de inbox importa menos que la latencia de entrega y la fiabilidad del SLA. Un retraso de 30 segundos en un OTP genera un ticket de soporte. Un retraso de 5 minutos provoca una baja. Es un problema operativo distinto al del marketing y conviene tratarlo como tal: cola separada, IPs separadas, alertas separadas, equipo de guardia con umbrales de paginado específicos.
¿Por qué los equipos transaccionales migran desde AWS SES?
SES es el punto de partida más habitual porque tiene el precio por mensaje más bajo del mercado (€0,10 por mil). Los equipos que crecen suelen abandonarlo por tres razones que se acumulan en paralelo. Primero, el calentamiento de IP es íntegramente DIY: la mayoría de los equipos lo subestima y termina con throttling en Gmail y Outlook el día del primer lanzamiento serio o de un Black Friday. Segundo, cuando algo se rompe a las cuatro de la mañana, llegar a un humano de AWS que entienda de email pasa por Business Support de pago y por una cola que no está optimizada para el caso en que la respuesta hace falta en 30 minutos, no en 30 horas. Tercero, la carga operativa de monitorear deliverability por proveedor de buzón, parsear los informes DMARC, gestionar la reputación IP y responder a las quejas recae completa en el equipo cliente, que casi siempre tiene otras cosas que hacer. Esos tres puntos describen el mismo problema: SES vende un wrapper sobre SMTP a precio agresivo y deja todo el resto al cliente.
Qué se afina específicamente para tráfico transaccional.
Tres parámetros se configuran de forma distinta al marketing en nuestra plataforma. Primero, cola con prioridad de mensaje: los transaccionales saltan cualquier cola por lotes por cliente y van directos a la lane de despacho por IP, con un pool de rate limit separado del resto. Segundo, las IPs asignadas a pools transaccionales se calientan más rápido porque las señales de engagement son inequívocas —los destinatarios abren restablecimientos de contraseña y avisos de envío con tasas altas y casi inmediatas, lo que acelera la curva de confianza con Gmail y Outlook. Tercero, la rotación de guardia tiene umbrales de paginado específicos para anomalías de latencia transaccional: si la mediana supera los 3 segundos para un cliente concreto durante más de 5 minutos, el ingeniero de guardia recibe la alerta sin importar el estado global de la plataforma. Ese tercer punto es el que más echa de menos quien viene de un proveedor que solo pagina ante outage global.
¿Qué cambia bajo PSD2 y la directiva SCA para una fintech UE?
Para una entidad financiera europea o una EDE/IPF con licencia, el email transaccional que entrega un código SCA bajo PSD2 (Directiva (UE) 2015/2366) cae directamente en el ámbito regulatorio. La SCA exige dos factores de autenticación independientes: posesión, conocimiento, inherencia. El OTP entregado por email se usa típicamente como factor de posesión, lo que convierte la entrega puntual en un requisito legal —no en un nice to have. Si el OTP no llega en una ventana razonable (suele fijarse en 60-120 segundos antes de que la operación quede sin aprobar), la entidad incumple su deber de prestar un servicio de pago bajo PSD2 artículo 73, lo que abre la puerta a reclamaciones de cliente y reportes al supervisor. Por eso los clientes fintech contractualizan SLA agresivos sobre la mediana de latencia; el percentil 99 de submission por sí solo no captura ese requisito. Nuestros contratos Enterprise para fintech incluyen una cláusula específica sobre latencia mediana sub-3-segundos a Gmail, Outlook y los proveedores corporativos europeos más comunes, con créditos de servicio si se incumple en más de 1 hora consecutiva.
El problema concreto que aparece con Microsoft 365 corporativo y los OTP.
Microsoft 365 representa una porción enorme del email corporativo europeo y trae un comportamiento que rompe los OTP con frecuencia: algunos tenants aplican políticas de cuarentena agresivas que retrasan incluso correos correctamente autenticados con SPF, DKIM y DMARC alineado, sumando 2-3 minutos extra al tiempo de llegada. Cuando esto sucede sobre un OTP con ventana de 60 segundos, el usuario nunca lo recibe a tiempo. La causa raíz suele estar en políticas de Defender for Office 365 mal calibradas en el lado del cliente final, no en nuestro lado, pero el resultado es el mismo: el usuario llama a soporte. Las dos vías de remediación que funcionan: (a) que el tenant añada nuestras IPs a una lista de remitentes permitidos (proporcionamos las IPs documentadas en el panel), o (b) enrutar los OTP de ese tenant por una IP dedicada con reputación específica establecida que el filtrado entrega sin demora. La opción (b) la activamos en cuestión de horas para clientes Enterprise; en Performance, en 1-2 días laborables.
¿Por qué la idempotencia es un requisito de producto?
Un endpoint transaccional que no soporta idempotency keys es un endpoint que algún día va a duplicar OTP o confirmaciones de pago durante un fallo intermitente de red. Nuestra API REST acepta una cabecera Idempotency-Key en POST /v2/send y guarda el response durante 24 horas: cualquier llamada repetida con la misma clave dentro de esa ventana devuelve el response original sin reenviar. Esto importa especialmente en arquitecturas con webhooks de pago y reintentos automáticos: el sistema de pago reintenta la confirmación al cliente porque no recibió 2xx, el webhook reentra a la lógica de envío, y sin idempotencia el destinatario recibe el recibo dos veces. Las pasarelas de pago europeas más comunes (Adyen, Stripe, Mollie, PayU para LATAM) reintentan webhooks con backoff exponencial durante horas o días: Stripe específicamente reintenta hasta unas 72 horas con backoff exponencial, lo que multiplica el riesgo de duplicado si la integración de email es ingenua. Sí, parte del trabajo lo debe hacer la aplicación cliente generando UUID v4 por evento, pero un proveedor serio expone la cabecera y la respeta.
BIMI y el logo verificado en el inbox: lo que cambió desde septiembre 2024.
BIMI (RFC 9495) es el estándar que muestra el logo verificado de la marca junto al nombre del remitente en Gmail, Yahoo Mail, Apple Mail (desde iOS 16, iPadOS 16 y macOS Ventura) y Fastmail. Microsoft Outlook no soporta BIMI todavía a principios de 2026 y ha indicado planes sin fecha. La barrera de entrada bajó drásticamente en septiembre 2024 cuando Gmail empezó a aceptar Common Mark Certificates (CMC) además de los Verified Mark Certificates (VMC) tradicionales: el CMC no requiere registro de marca pero sí evidencia de uso público continuado del logo durante 12 meses como mínimo. El precio orientativo está en torno a 650-1100 USD/año para CMC y 899-1668 USD/año para VMC, dependiendo de la CA (DigiCert, Entrust, Sectigo, SSL.com). Para mostrar el logo en cualquiera de estos proveedores hace falta DMARC en política p=quarantine o p=reject —p=none no basta—, alineación SPF y DKIM, y un SVG Tiny Portable Secure bajo 32 KB. Solo el VMC activa el checkmark azul de verificación en Gmail. En nuestro panel encontrarás validador de BIMI, generador del DNS record y handoff documentado con DigiCert y Entrust para la emisión del certificado.
¿Cómo se calcula el costo total real de un programa transaccional?
El número que importa no es €/mil mensajes. Es el costo total mensual del programa transaccional dividido por mensajes entregados con éxito en plazo SLA. Para un volumen de 5 millones de transaccionales mensuales con 4 IPs dedicadas, SES factura unos 500€ de mensajes pero la operación real le suma 2-3 ingenieros de plataforma a tiempo parcial (calentamiento, DMARC report parsing, gestión de quejas, soporte de incidentes), 1 herramienta SaaS de monitoring deliverability (Glock Apps, MailMonitor, 250+ ARM ID), 1 herramienta de DMARC reporting (dmarcian, Valimail, EasyDMARC, alrededor de 200-500€/mes según volumen). Llegamos a un equivalente real de 2500-5000€/mes una vez sumado el costo internalizado. En nuestro Plan Standard, el mismo volumen sale alrededor de 1900€/mes con todo incluido —IPs, plataforma, dashboards, monitoreo, DMARC, BIMI— y con SLA contractual. La razón por la que SES sigue ganando comparativas es que el comprador típico mira solo la línea de mensajes y no la línea de FTE oculto. Cuando el comprador es un CFO o un director de finanzas (no un ingeniero), el cálculo cambia al instante.
Patrones arquitectónicos que vemos repetir en clientes transaccionales serios.
Hay tres patrones que se repiten en arquitecturas transaccionales bien hechas. Primero, separación estricta de subdominios por flujo: orders.dominio.com para confirmaciones de compra y envíos, security.dominio.com para OTP y restablecimientos de contraseña, billing.dominio.com para facturas y recibos, y por supuesto news.dominio.com para marketing. Cada subdominio con su SPF, DKIM y DMARC alineados independientes. Segundo, retry queue idempotente del lado aplicación: el código que llama al endpoint /v2/send tiene su propia cola persistente con UUID v4 por evento, y en caso de fallo de red reintenta con la misma key. Esto suma cero ms al happy path pero blinda contra duplicados durante incidentes parciales. Tercero, monitoring por flujo no global: el dashboard del cliente debe mostrar la mediana de OTP por separado de la de avisos de envío, porque un degradado en OTP es operación crítica mientras que un degradado en avisos de envío es tolerable. Quien mira un único número agregado se entera demasiado tarde.