El objetivo: transformar “no llega” en un diagnóstico verificable

El primer error común es tratar la incidencia como un problema binario: “enviamos / no enviamos”. En realidad, hay varias etapas: generación del evento (la app decide enviar), entrega al proveedor (ESP o SMTP), aceptación (el destino dice “OK”), procesamiento (spam, cuarentena, reglas), y visibilidad (aparece en bandeja o no). Cada etapa puede fallar de forma distinta.

Desde producto, la meta es simple: instrumentar y exponer lo suficiente para que el equipo pueda responder con hechos: “El correo fue aceptado por el proveedor de destino a las 10:41, con id X” o “Nunca salió de nuestra cola por límite de envío”. Eso baja la ansiedad del usuario y acorta el ciclo interno.

Una historia realista: el caso del “código de acceso fantasma”

Un martes por la tarde, el equipo lanza una campaña de reactivación. A los 20 minutos, soporte recibe 40 tickets: “Me llega el SMS, pero el correo de verificación no”. El dashboard de envíos dice “sent”. Producto ve caer la conversión en el paso de verificación y empieza el pánico: ¿bug? ¿bloqueo? ¿spam?

En este tipo de incidentes, el valor de producto no es “adivinar” el culpable. El valor es organizar el diagnóstico: segmentar por proveedor, detectar patrón temporal, comparar plantillas, revisar cambios recientes, pedir evidencias mínimas a soporte y activar mitigaciones con prioridad.

Checklist de triage (los primeros 15 minutos)

• ¿Es general o segmentado? ¿Afecta a todos o solo a Gmail/Outlook/Apple/empresas? Segmentar por dominio del destinatario suele revelar el patrón en minutos.
• ¿Qué tipo de correo falla? Verificación, reset de contraseña, recibos, marketing, alertas. Si falla solo uno, sospecha de plantilla, contenido o ruta de envío.
• ¿Hubo un cambio reciente? Dominio nuevo, IP nueva, contenido nuevo, proveedor de email cambiado, incremento de volumen, cambios en DNS (SPF/DKIM/DMARC), o nueva lógica antiabuso.
• ¿Qué significa “sent” en vuestro sistema? ¿Significa “lo pusimos en cola”, “el proveedor lo aceptó” o “el destino lo aceptó”? Alinear definiciones evita diagnósticos falsos.
• ¿Hay señales de bloqueos o limitación? Throttling del proveedor, rate limits internos, colas creciendo, tiempos de entrega subiendo.

Consejo de producto: en incidentes de email, la palabra “sent” sin contexto es enemiga. Si tu UI o logs internos dicen “sent”, exige que el evento esté ligado a una etapa concreta.

Mapa de causas: dónde se rompe normalmente

1) Nunca salió de vuestra casa (app/cola/proveedor)

Aquí el usuario no recibe porque, literalmente, el correo no se envió. Puede pasar aunque vuestro sistema marque “enviado” si ese estado significa “en cola”. Señales típicas: crecimiento de la cola, reintentos, errores de autenticación con el proveedor, credenciales expiradas, o límites de envío.

• Indicadores: backlog de cola, latencia de envío, ratio de reintentos, errores 4xx/5xx del ESP/SMTP.
• Acción rápida: forzar reintentos con backoff correcto, aumentar capacidad, revisar credenciales y límites.
• Mitigación de producto: permitir reenviar con cooldown y mostrar “puede tardar hasta X minutos”.

2) El proveedor lo aceptó, pero el destino lo rechazó o difirió

El ESP puede aceptar el mensaje, pero el servidor receptor puede devolver rechazo (bounce) o diferir (defer) por reputación, volumen o políticas antiabuso. Es frecuente tras subidas bruscas de tráfico o cambios de IP/dominio.

• Indicadores: aumento de bounces, códigos 4xx (defer) o 5xx (reject), caídas por proveedor destinatario.
• Acción rápida: revisar logs de SMTP/ESP con códigos exactos, reducir ritmo, separar transaccional y marketing.
• Mitigación de producto: fallback a un segundo canal (SMS o push) para flujos críticos.

3) Llegó, pero se fue a spam o cuarentena

Este es el gran clásico. El usuario dice “no lo recibo”, pero el mensaje está en spam, promociones o incluso bloqueado por reglas corporativas. Cambios mínimos en contenido (un enlace, una palabra “gratis”, un acortador) pueden disparar filtros.

• Indicadores: caídas en “inbox placement”, quejas, cambios de plantilla, enlaces nuevos, tracking agresivo.
• Acción rápida: probar con seed list, revisar contenido, reducir enlaces, evitar acortadores, ajustar tracking.
• Mitigación de producto: UI con guía: “revisa spam/promociones y añade a contactos”.

4) Autenticación del dominio (SPF/DKIM/DMARC) mal configurada

Aunque no siempre produce rechazo inmediato, una configuración débil o incorrecta aumenta la probabilidad de filtrado. Es crítico cuando envías desde tu dominio y no desde un subdominio dedicado.

• Indicadores: fallos de alineación, cambios recientes en DNS, uso de múltiples proveedores sin SPF bien armado.
• Acción rápida: revisar SPF, DKIM, DMARC y alineación; validar en entornos de prueba; corregir registros.
• Mitigación de producto: separar “from” transaccional (subdominio) y mantener consistencia.

5) Bloqueo por políticas internas del cliente (especialmente B2B)

Empresas con filtros estrictos pueden bloquear dominios nuevos, IPs sin reputación o mensajes con adjuntos/links. El usuario ve “no llega” y vosotros no tenéis visibilidad del firewall o gateway interno.

• Indicadores: incidencias concentradas en dominios corporativos, tickets de un mismo cliente/tenant.
• Acción rápida: proporcionar cabeceras, Message-ID, hora exacta y IP para que el cliente revise sus logs.
• Mitigación de producto: opción de cambiar correo o usar un dominio alternativo en el flujo.

Qué datos mínimos necesitas para investigar (sin marear a soporte)

Un error típico es pedirle al usuario “capturas, logs, todo”. Eso alarga la conversación y empeora la percepción. Mejor: define un conjunto mínimo de datos que soporte pueda recoger en 30 segundos.

• Email del destinatario (y su dominio).
• Tipo de correo (verificación, reset, confirmación, etc.).
• Hora aproximada del intento (con zona horaria si es posible).
• Si pulsó reenviar y cuántas veces.
• Si revisó spam/promociones (respuesta sí/no).

Internamente, producto debería poder cruzar eso con: event_id, message_id, proveedor, estado por etapa, y si existe: código de rebote o defer.

Diseño de estados: deja de usar “sent” como estado final

Si tu panel interno o tu UI solo muestran “enviado”, estás perdiendo la oportunidad de diagnosticar. Un modelo de estados más útil separa: Queued (en cola), Submitted (entregado al proveedor), Accepted (aceptado por el servidor destino), Delivered (confirmación si existe), Bounced (rechazado), Deferred (diferido), Complained (queja), Suppressed (suprimido).

No todos los proveedores dan “Delivered” real para todos los casos, pero casi siempre puedes mejorar mucho con Queued vs Submitted vs Bounced/Deferred. Producto gana claridad y soporte deja de “adivinar”.

Diagnóstico por segmentos: el truco que casi siempre funciona

Cuando tienes muchos tickets, no los mires uno a uno. Segmenta:

• Por dominio destinatario: gmail.com, outlook.com, icloud.com, yahoo.com, dominios corporativos.
• Por tipo de email: verificación vs marketing vs notificación.
• Por ventana temporal: antes/después de un deploy o de un pico de tráfico.
• Por plantilla o contenido: versión de template, idioma, enlaces incluidos.
• Por ruta de envío: proveedor A vs proveedor B, IP pool, subdominio.

Si ves que “solo Gmail falla” y coincide con un cambio de dominio o un pico de volumen, tienes una hipótesis fuerte: reputación/rate limit/filtrado. Si “solo verificación falla”, sospecha de plantilla, links o lógica de generación.

Mitigaciones de producto que salvan conversiones

Aunque ingeniería investiga, producto puede activar medidas para reducir daño:

• Reenviar con control: botón de reenviar con temporizador (por ejemplo, 30–60s) para evitar abuso. Incluye alternativa: “cambiar correo”.
• Canal alternativo: en flujos críticos, ofrecer SMS o autenticación por app. No como “plan A”, sino como red de seguridad.
• Mensajería clara: “Puede tardar unos minutos”, “Revisa spam/promociones”, “Añade el remitente a contactos”. Evita culpar al usuario; sé neutral y orientado a acción.
• Detección inteligente: si el usuario reintenta varias veces y el dominio es corporativo, sugiere cambiar a un correo personal o pedir a su IT que permita el dominio.
• Autoobservabilidad: mostrar un estado del envío más granular en pantalla (“solicitado”, “procesando”, “enviado al proveedor”).

Cómo comunicar a soporte (y al usuario) sin quemar confianza

En incidentes de email, el usuario quiere dos cosas: certeza y alternativa. Si no puedes prometer “llega seguro”, al menos ofrece un camino para seguir.

Plantilla de respuesta útil (en tono humano)

Hemos solicitado el envío del correo y puede tardar unos minutos en aparecer. Por favor revisa también la carpeta de spam/promociones. Si en 5–10 minutos no llega, puedes reenviar desde aquí o cambiar la dirección de correo. Si usas un correo corporativo, algunos filtros pueden bloquearlo y en ese caso recomendamos probar con otra dirección.

Nota de producto: lo importante no es el texto exacto, sino que incluya expectativa de tiempo, acciones concretas, y alternativa.

Acciones preventivas: lo que debes construir antes del próximo incidente

La prevención no es solo “mejorar entregabilidad”. También es diseñar el sistema para que el diagnóstico sea rápido. Algunas inversiones de alto impacto:

• Eventos por etapa (cola, proveedor, bounce/defer) y trazabilidad por usuario.
• Dashboards por dominio destinatario y por tipo de email.
• Separación de tráfico: transaccional y marketing en rutas, dominios o IP pools distintos.
• Control de contenido: versionado de plantillas y posibilidad de rollback rápido.
• Listas de prueba (seed accounts) para Gmail/Outlook/iCloud con checks rutinarios.
• Política antiabuso que no rompa UX (rate limit inteligente y mensajes claros).

A nivel de producto, estas medidas convierten el email en un componente observables y controlable, no en una caja negra.

Conclusión: el enfoque de producto que reduce el caos

“Enviado pero no recibido” no es un bug único; es una categoría. La diferencia entre un equipo que sufre y un equipo que resuelve está en cómo estructura el problema: segmentación rápida, estados claros, evidencias mínimas, mitigaciones de UX y comunicación honesta. Cuando haces eso, incluso si el fallo está fuera de tu control (filtros del destinatario), puedes mantener la confianza y proteger tus métricas críticas.

Si tu producto depende de emails de verificación o recuperación, este tema no es “infra”: es core del negocio. Trátalo como tal: mide, instrumenta, comunica y mejora iterativamente.