Solucionamos problemas de entrega de correo

Las cuatro categorías de problema

Hemos hecho troubleshooting a cientos de programas de email a lo largo de los años. La causa raíz casi siempre cae en una de cuatro categorías. No son mutuamente excluyentes — un programa con problema serio suele tener síntomas en varias — pero entender en cuál está la causa primaria ahorra semanas de trabajo persiguiendo el efecto en lugar de la causa.

• Autenticación rota o incompleta. SPF que no autoriza la IP de envío, DKIM que falla la verificación, DMARC que no está alineado, registros PTR ausentes. Esto se manifiesta como rechazo directo o ruteo sistemático a spam, especialmente en Gmail, Yahoo y los ISPs alemanes.
• Reputación de IP o dominio dañada. Tasa de queja por encima de threshold, hard bounces sin suprimir, IP en blacklist pública, dominio con historial sucio. Se manifiesta como deferrals (TS02 en Yahoo, throttling en Gmail) y placement degradado en bandeja de entrada.
• Contenido marcado por filtros. Subject lines que disparan filtros bayesianos, ratio imagen-texto desbalanceado, enlaces hacia dominios con mala reputación, adjuntos prohibidos. Se manifiesta como bloqueos por Spam Content (código bounceCat 52 en PowerMTA).
• Lista contaminada. Direcciones spam-trap, suscripciones sin opt-in real, datos antiguos de listas alquiladas o compradas, alta proporción de inactivos. Se manifiesta como hard bounces sostenidos sobre 2% y quejas que no bajan aunque se segmente el contenido.

El primer movimiento: distribución por ISP

Antes de mirar cualquier herramienta, abra el accounting log y cuente bounces y deferrals por dominio receptor en las últimas 24-72 horas. Este simple ejercicio ya divide el problema en dos:

Si el placement cae uniformemente entre Gmail, Outlook, Yahoo, GMX, T-Online y los demás: el problema es del lado del sender. Es algo que los receptores ven igual: autenticación, IP, dominio, o un cambio reciente en el contenido. La autenticación es lo primero a verificar porque es binaria (funciona o no funciona) y se arregla rápido.

Si el placement cae solo en uno o dos ISPs: el problema es de reputación localizada. Algo específico de esos receptores está marcando su tráfico. Aquí Postmaster Tools (Gmail) y SNDS (Microsoft) son las herramientas centrales. Yahoo es más opaco; Sender Hub ayuda pero la información es menos granular.

Si el placement cae súbitamente al mismo tiempo en muchos ISPs y la lista no cambió: mire blacklists públicas. Spamhaus SBL y CSS son los listados que más impactan a senders comerciales legítimos cuando entran. MultiRBL.valli.org agrega 100+ blacklists para una verificación rápida.

Verificación de autenticación, en orden

Las cuatro patas de la autenticación deben pasar todas. Una pata coja suele bastar para que un proveedor moderno mande el mensaje a spam o lo rechace directamente. Verifique en este orden:

1. SPF. El registro TXT del dominio debe autorizar todas las IPs desde las que envía. Compruebe con dig TXT su-dominio.com | grep spf. Si añadió IPs nuevas y no actualizó SPF, esto es lo primero que falla. Recuerde que SPF tiene un límite de 10 lookups DNS — un registro complejo puede romperse silenciosamente.
2. DKIM. Verifique que el selector que firma sus correos resuelve correctamente y devuelve la clave pública esperada. Mande un correo a check-auth@verifier.port25.com y revise el reporte que devuelve. La rotación de claves DKIM es una causa frecuente de fallos sigilosos: el selector se cambió pero el DNS no se actualizó.
3. DMARC alignment. El dominio del header From debe alinear con el dominio que firma DKIM o con el dominio del envelope From (usado para SPF). Si DMARC está en p=reject y la alineación falla, el correo se rechaza punta a punta. Use dig TXT _dmarc.su-dominio.com para confirmar la política activa.
4. PTR records (reverse DNS). Cada IP de envío debe tener un PTR válido apuntando a un hostname que resuelva de vuelta a esa IP. dig -x IP-de-envío. Microsoft es especialmente estricto con esto; un PTR roto en una IP es razón habitual de bloqueos en Outlook que se diagnostican mal como "problema de reputación".

Mapa de síntoma a causa más probable

Un atajo de diagnóstico cuando ya tiene los datos crudos. La columna de causa probable no es definitiva; es por dónde empezar a mirar.

Si está en una blacklist

No todas las blacklists son iguales. Spamhaus SBL/CSS es la que más afecta el placement en producción; estar listado ahí impacta directamente la entrega. Barracuda, SORBS, UCEPROTECT y las pequeñas tienen impacto variable y muchas son ruido. Antes de tramitar delistings:

• Identifique la causa raíz. El proceso de delisting de Spamhaus pide explicar qué cambió. Si solicita el delisting sin haber resuelto la causa, el listing vuelve dentro de horas y queda como sender reincidente.
• Tramite primero las blacklists que importan. Spamhaus, Microsoft (vía SNDS) y los listings privados de los ISPs grandes son los que afectan delivery real. UCEPROTECT3 y similares aparecen mucho en reportes pero rara vez tienen impacto operativo.
• Documente. Las blacklists tienen memoria: el segundo y tercer listing de la misma IP son progresivamente más difíciles de quitar. Mantenga un log de incidencias, causa, corrección, y fecha de delisting.
• El timing realista. Spamhaus suele resolver delistings en 24-72 horas si la causa está documentada. Microsoft puede tardar 1-2 semanas. Las blacklists pequeñas son impredecibles — algunas requieren contacto manual con el operador, otras se auto-purgan tras un periodo sin actividad.

Higiene de lista cuando es la causa

Cuando el problema es lista contaminada, los síntomas son tasa de hard bounces sostenida sobre 2%, queja sobre 0.1% que no baja con cambios de contenido, y open rate de inactivos por encima de 12 meses cercano a cero. La corrección es tan dolorosa como obvia: limpiar la lista significa borrar suscriptores que ya no aportan, lo que reduce el tamaño nominal pero mejora todas las métricas que importan.

Procedimiento que usamos en auditorías:

1. Suprimir hard bounces históricos no procesados. Si el pipeline de supresión estuvo roto, recupere los hard bounces de 12 meses atrás y aplíquelos.
2. Validar direcciones via SMTP-level check. Para listas grandes, herramientas como ZeroBounce, NeverBounce o Kickbox validan a nivel SMTP antes del envío. Caro pero efectivo. Calculado contra el coste de una caída de placement, suele compensar.
3. Suprimir inactivos sin engagement por 12+ meses. Decisión incómoda pero necesaria. Una lista de 100,000 activos supera a una de 1,000,000 mayormente-inactivos, tanto en placement como en revenue. Vea nuestro post de re-engagement para el patrón correcto antes de borrar definitivamente.
4. Verificar fuentes de adquisición. Si una fuente concreta de signups produce mayor proporción de quejas o spam-traps, suspéndala hasta entender qué pasa. El opt-in implícito vs explícito y los formularios sin double opt-in son focos comunes.

Cuándo escalar a auditoría externa

Una auditoría externa de entregabilidad cuesta dinero pero ahorra tiempo cuando el equipo interno lleva una semana sin avanzar. Los indicadores de que conviene escalar:

• Lleva más de 5 días aplicando cambios y las métricas no se mueven.
• El equipo interno no tiene visibilidad histórica de cómo se vio el mismo problema en otros senders.
• El revenue diario perdido por mal placement supera el coste de una auditoría en menos de 7 días.
• Hay desacuerdo interno sobre cuál es la causa raíz y cada facción presiona en una dirección distinta. Una opinión externa neutral con datos cierra el debate más rápido que más reuniones.

Lo que aporta una buena auditoría: una vista cruzada del setup actual contra patrones que el auditor vio en otros senders comparables, identificación de la causa raíz priorizada en orden de impacto, y un plan concreto de corrección con plazos. No vale como sustituto del trabajo operativo — alguien tiene que ejecutar las correcciones — pero recorta semanas del proceso de diagnóstico.