Email transaccional: diagnóstico rápido de entregas fallidas

Publicado el

← Volver
Editor de código con sintaxis en tema oscuro, mostrando logs y archivos de servidor en pantalla
Foto de Harshit Katiyar en Unsplash

Un email de recuperación de contraseña que nunca llega. Una confirmación de compra que aparece en spam tres horas después. Un registro que nadie valida porque el correo de bienvenida se perdió en algún punto del camino.

El email transaccional tiene un contrato implícito con el usuario: llega, llega rápido y llega al inbox. Cuando ese contrato se rompe, el fallo no suele estar en un solo sitio. Está en la combinación de DNS mal configurado, reputación de IP comprometida, contenido que activa filtros o bounce handling que nunca se implementó.

Este post es un checklist diagnóstico estructurado. El objetivo es que, antes de escalar el problema o cambiar de proveedor, hayas descartado sistemáticamente cada capa.

1. Antes de diagnosticar: entiende dónde puede estar el fallo

El recorrido de un email transaccional pasa por cuatro capas, y el problema puede estar en cualquiera de ellas:

  1. Plataforma de envío — Tu ESP o servidor SMTP (Postmark, SendGrid, SES, Mailgun, tu propio Exim/Postfix…).
  2. Infraestructura y DNS — SPF, DKIM, DMARC, FCrDNS, reputación de IP.
  3. Contenido del mensaje — Asunto, cuerpo HTML, enlaces, ratio texto/imagen.
  4. Servidor receptor — Políticas del proveedor de buzón del destinatario (Gmail, Outlook, servidores corporativos).

El error más común al diagnosticar es saltarse capas. Alguien mira los logs del ESP, ve “delivered”, y asume que el problema está en el cliente de correo del usuario. Pero “delivered” en el contexto del ESP solo significa que el servidor receptor aceptó la conexión SMTP, no que el mensaje llegó al inbox.

2. Empezar por los logs SMTP: los códigos de respuesta dicen la verdad

Antes de tocar configuración, lee los logs. El servidor receptor responde con códigos numéricos que clasifican el fallo:

  • 4xx — Fallo temporal. El servidor está diciéndote “ahora no, reintenta más tarde”. Son los soft bounces.
  • 5xx — Fallo permanente. Son los hard bounces: la dirección no existe, el dominio no responde, o has sido bloqueado.

Algunos códigos específicos que vale la pena conocer de memoria:

550 5.1.1  → La dirección del destinatario no existe
550 5.7.1  → Bloqueado por política del servidor receptor (reputación)
421 4.7.0  → Rate limiting: el receptor te pide que bajes el ritmo
554 5.7.5  → Rechazo por contenido (filtro de spam activado)

Si tu ESP no expone logs con códigos SMTP detallados, considera herramientas de diagnóstico como MXToolbox para analizar cabeceras de mensajes reales, o Red Sift Investigate para un test dinámico de tu infraestructura de envío.

3. Checklist de autenticación DNS

La autenticación DNS es la capa que más se rompe en migraciones de servidor. En 2024–2025, los principales proveedores de buzón endurecieron sus requisitos: Gmail y Yahoo exigen SPF, DKIM y DMARC como mínimo para remitentes de volumen, y Microsoft sumó sus propias restricciones en mayo de 2025. Si envías sin autenticación correcta, el mensaje puede llegar directamente a spam o ser rechazado.

Los tres registros a verificar:

SPF — Declara qué IPs o servicios están autorizados a enviar en nombre de tu dominio. El límite es 10 lookups DNS en la evaluación. Si tu registro incluye demasiados include: anidados, puedes superar ese límite y provocar un PermError que hace que el SPF falle aunque todo lo demás esté bien.

DKIM — Firma criptográfica del mensaje. Verifica que el mensaje no ha sido alterado en tránsito. El selector publicado en DNS debe coincidir con el que usa tu servicio de envío, y la clave debe ser de al menos 1024 bits (2048 recomendado). Un error frecuente en migraciones: el servicio anterior firmaba con un selector que ya no existe en DNS.

DMARC — Orquesta SPF y DKIM e indica al servidor receptor qué hacer si alguno falla. Sin DMARC, incluso con SPF y DKIM correctos, no recibes informes de fallos. El valor mínimo es p=none (monitorización), pero para proteger realmente el dominio conviene avanzar hacia p=quarantine o p=reject una vez que los informes confirman que no hay falsos positivos.

# Comprobación rápida en terminal
dig TXT tudominio.com          # busca el registro SPF
dig TXT selector._domainkey.tudominio.com   # DKIM
dig TXT _dmarc.tudominio.com   # DMARC

Verifica también el FCrDNS (forward-confirmed reverse DNS): la IP de envío debe tener un PTR que resuelva de vuelta al mismo nombre de host. Muchos servidores corporativos rechazan conexiones sin FCrDNS válido, y es un fallo que pasa desapercibido porque no aparece en los logs del ESP.

4. Checklist de reputación de IP y dominio

La autenticación te da credenciales. La reputación es la confianza acumulada que los proveedores de buzón tienen en esas credenciales.

Verifica si tu IP o dominio está en listas negras. Una IP que comparte infraestructura con un sender que envió spam puede arrastrar tu reputación. MXToolbox tiene un comprobador de blacklists que consulta más de 100 listas. Si apareces en alguna, busca el proceso de eliminación específico de esa lista (cada una tiene el suyo).

Google Postmaster Tools y Microsoft SNDS son herramientas gratuitas que muestran la reputación de tu dominio según el proveedor. Si tienes volumen significativo hacia Gmail o Outlook respectivamente, actívalas. Son la señal más directa de cómo te ven por dentro.

Separación de flujos de envío. Si usas el mismo dominio o IP para email marketing y email transaccional, un pico de quejas en una campaña puede contaminar la reputación del transaccional. La práctica recomendada es usar subdominios distintos (transaccional.tudominio.com vs marketing.tudominio.com) y, si el volumen lo justifica, IPs separadas. Para volúmenes bajos o irregulares, un ESP con IP compartida bien gestionada es suficiente y más seguro que una IP dedicada sin calentar.

5. Checklist de contenido y cabeceras del mensaje

Los filtros de spam no miran solo la infraestructura. Analizan el mensaje en sí: cabeceras, asunto, cuerpo HTML y comportamiento de los enlaces.

Cabeceras técnicas obligatorias:

  • From con nombre y dirección real (Nombre App <no-reply@tudominio.com>). No uses direcciones de dominios genéricos ni no-reply sin nombre.
  • Reply-To configurado si esperas respuestas o si el From es una dirección sin buzón real.
  • Message-ID generado por tu servidor (no dejes que el ESP lo omita).
  • Para newsletters o bulk, List-Unsubscribe con el mecanismo one-click (RFC 8058). Gmail y Yahoo lo requieren para senders de volumen.

Contenido que activa filtros:

  • Exceso de imágenes con poco texto (ratio texto/imagen desequilibrado).
  • URLs acortadas o redirigidores de terceros en los enlaces. Usa URLs directas.
  • ALLCAPS en el asunto o en el cuerpo.
  • Palabras de urgencia comercial en el asunto de un email transaccional (innecesarias y contraproducentes).
  • Versión de texto plano ausente cuando el mensaje es HTML. Incluye siempre el text/plain alternativo.

Verifica los enlaces antes de enviar. Un enlace roto o que redirige a un dominio diferente al del remitente es señal de alarma para muchos filtros.

6. Bounce handling: el fallo silencioso que acumula daño

El bounce handling es la parte que más proyectos omiten hasta que el problema es grave. Los conceptos básicos:

  • Hard bounce (5xx): fallo permanente. La dirección no existe o el servidor la rechaza definitivamente. Suprime esa dirección inmediatamente. Reintentar sobre un hard bounce daña tu reputación porque los proveedores de buzón lo interpretan como comportamiento de sender descuidado o abusivo.
  • Soft bounce (4xx): fallo temporal. Permite reintentos. Si una dirección acumula varios soft bounces consecutivos sin entrega exitosa, trátala como hard bounce y suprímela.

La mayoría de los ESPs gestionan esto automáticamente, pero si envías desde tu propio servidor SMTP o procesas webhooks, asegúrate de que tu aplicación:

  1. Escucha los eventos de bounce del ESP (webhook o polling de la API).
  2. Actualiza el estado del usuario en tu base de datos.
  3. No reintenta envíos a direcciones con hard bounce.
  4. Tiene alertas cuando la tasa de bounces supera umbrales razonables.

7. El escenario de migración de servidor

Si el problema aparece justo después de una migración a un nuevo servidor o nuevo proveedor de hosting, el checklist de diagnóstico tiene un orden específico:

  1. Verifica que el SPF del dominio incluye el nuevo servidor o ESP, y que el antiguo servidor (si ya no envía) ha sido eliminado del registro.
  2. Comprueba que el DKIM del nuevo servidor está publicado en DNS con el selector correcto. Si migraste a un hosting que configura DKIM automáticamente, puede que el selector generado no coincida con el que publican por defecto en tu panel de DNS.
  3. Revisa que el DMARC sigue recibiendo informes (rua=) y que no hay fallos de alineación que antes no existían.
  4. Confirma el FCrDNS del nuevo servidor.
  5. Si cambias de IP, ten en cuenta que la nueva IP empieza sin historial. Algunos servidores receptores pueden diferir los primeros mensajes hasta verificar la reputación. Los primeros días puede haber más delays de lo normal.

8. Herramientas de diagnóstico de referencia

Sin inventar URLs ni servicios que no haya verificado, estas son las herramientas más utilizadas en el diagnóstico de entregabilidad:

HerramientaPara qué sirve
MXToolboxBlacklists, análisis de cabeceras, lookup SPF/DKIM/DMARC
Google Postmaster ToolsReputación de dominio e IP según Gmail
mail-tester.comPuntuación rápida de un mensaje concreto
Red Sift InvestigateTest dinámico: envía un email real y analiza autenticación en tránsito
Panel de tu ESPLogs de entrega, tasas de bounce, eventos de spam

El diagnóstico más útil siempre parte del mensaje real: analizar las cabeceras completas de un email que llegó a spam o no llegó. Gmail permite ver las cabeceras completas en “Mostrar original”; Outlook tiene una opción equivalente. Esas cabeceras muestran el recorrido completo del mensaje y los resultados de SPF, DKIM y DMARC tal como los evaluó el receptor.

Si después de este checklist el problema persiste o necesitas revisar la configuración de entregabilidad de un proyecto en producción, cuéntame en qué punto estás y lo miramos.