Correo electrónico: la reputación de salida se derrumbó — qué dejar de hacer de inmediato (y soluciones)

Deja de hacer esto de inmediato

1) Deja de “probar” disparando a toda tu lista

Si la reputación está bajando, el volumen amplifica el daño. Enviar más correo hacia mayores tasas de rebote y quejas enseña a los proveedores de buzones que eres un remitente del que deben proteger a los usuarios. Tu primer trabajo es dejar de alimentar el fuego.

Sustituye las pruebas masivas por muestras controladas a una lista de seed verificada y a un subconjunto pequeño de tus destinatarios más comprometidos (aperturas/clicks/respuestas recientes). Y si no puedes medir el engagement, eso no es razón para seguir enviando masivamente; es razón para reducir la velocidad.

2) Deja de enviar desde dominios nuevos “para arreglarlo”

“Enviemos desde otro dominio” es deuda de entregabilidad con interés. Los proveedores correlacionan infraestructura, URLs, contenido y comportamiento. Además pierdes la reputación buena que tuvieras. Arregla el problema; no lo renombres.

3) Deja de ignorar los rebotes y reintentar para siempre

Tu MTA reintenta con gusto respuestas 4xx. Eso es correcto para fallos transitorios, pero si recibes tempfails por throttling o por reputación, necesitas control de tasa y una estrategia de supresión, no optimismo infinito.

4) Deja de enviar correo que falla autenticación (o que “pasa más o menos”)

SPF pasa con DKIM fallido no es “aceptable”. DMARC pasa sin alineación no es “aceptable”. En 2026, los proveedores principales exigen más el correo autenticado y alineado. No necesitas perfección, pero sí dejar de enviar correo no autenticado o mal alineado como si fuera 2009.

5) Deja de mezclar mail marketing y transaccional bajo la misma identidad

Mezclar un boletín semanal con restablecimientos de contraseña en el mismo dominio e IP es como enseñar a Gmail que “tus códigos de acceso son del mismo estilo que tu oferta de invierno”. Segrega flujos: subdominios, selectores DKIM separados, y pools de IP distintos si eres lo bastante grande.

6) Deja de cambiar cinco variables a la vez

Cuando ajustas SPF, rotas DKIM, cambias el dominio From, migras de ESP y modificas plantillas en el mismo día, pierdes la capacidad de atribuir causa. Trata la entregabilidad como un incidente: un cambio, impacto medido, opción de rollback.

Broma corta #1: La reputación de email es como un puntaje crediticio: puedes arruinarla rápido, y disputarla tipeando con furia no ayuda.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el camino para “obtener señal en 30 minutos”. No resolverá todo, pero encontrará el cuello de botella rápido y evitará que adivines.

Primero: determina el modo de fallo (entrega vs colocación vs aceptación)

• Fallo de entrega: rebotes, deferrals, bloqueos, crecimiento de la cola, errores SMTP.
• Fallo de colocación: aceptado (250 OK) pero aterriza en spam/promociones/cuarentena.
• Aceptado pero no visto: reglas del usuario, cuarentena corporativa, journaling o problemas de enrutamiento.

Prueba rápida: elige 10 mensajes recientes, recopila logs de transacción SMTP y clasifícalos. No confíes en “el usuario dice que no lo recibió”. Los usuarios también dicen “no cambié nada”.

Segundo: revisa autenticación y alineación (SPF/DKIM/DMARC)

• ¿Está el dominio From: alineado con SPF (MAIL FROM / Return-Path) o con el dominio d= de DKIM?
• ¿Están presentes las firmas DKIM y verifican?
• ¿Existe política DMARC y estás viendo fallos?

La mayoría de las caídas repentinas de reputación se correlacionan con regresiones de autenticación tras un cambio de proveedor, un cambio DNS o una modificación en la cadena de herramientas de plantillas.

Tercero: mira tu perfil de rebotes y quejas

• Rebotes duros: usuario desconocido, dominio inválido. Estos deben suprimirse rápido.
• Rebotes suaves/throttles: limitación de velocidad, “inténtelo más tarde”, tempfails por reputación.
• Quejas: usuarios marcando como “spam”. Si no recibes feedback de quejas de tu ESP, igual tienes quejas—simplemente no recibes la nota.

Cuarto: aisla flujos y reduce volumen

El correo transaccional debe protegerse como una base de datos. Si tu flujo de marketing está generando picos de rebote, córtalo o muévelo a una identidad de envío separada. El objetivo es detener el daño colateral.

Quinto: valida la identidad de la infraestructura (rDNS, HELO, TLS)

Muchos bloqueos son simplemente señales de “esto parece infraestructura maliciosa”: registros PTR faltantes, HELO genérico, o TLS roto. Estos son victorias fáciles.

Cómo funciona realmente la reputación (las partes que la gente olvida)

La reputación es multidimensional, no una única puntuación

Los proveedores de buzón no guardan un número mágico para ti. Rastrean reputación en:

• Reputación de dominio (el dominio From: que ven los usuarios)
• Reputación de subdominio (news.example.com vs example.com)
• Reputación de IP (especialmente para IPs dedicadas)
• Reputación de URL (hacia donde apuntan tus enlaces, incluidos redireccionadores)
• Reputación de contenido y comportamiento (plantillas, asuntos, patrones de engagement)
• Reputación a nivel de destinatario (cómo se comporta tu correo para un proveedor específico)

Así que cuando alguien dice “nuestro dominio está quemado”, la primera pregunta es: ¿qué dominio, qué flujo, qué proveedor, qué ventana temporal?

Los proveedores optimizan por resultados de usuario, no por sentimientos del remitente

El objetivo del filtrado es “los usuarios no estén molestos ni sean phishingeados”. Tu objetivo es “mi correo empresarial se vea”. Esos objetivos coinciden solo si te comportas bien. Si la calidad de tu lista se degrada, ninguna magia DNS lo compensa todo.

La autenticación es requisito; la alineación es el juego real

SPF y DKIM son mecanismos de autenticación. DMARC es la capa de política e informes, y introduce la alineación: el dominio visible al usuario debe coincidir con el dominio autenticado. Muchos remitentes “pasan SPF” mediante un dominio de rebote del ESP, pero fallan DMARC porque el From: no está alineado.

La recuperación de reputación es como el modelado de tráfico tras una caída

Si te limitaron por tasa, no “pruebas” que eres bueno enviando más. Lo demuestras enviando consistente, a personas que quieren tu correo, con bajas tasas de rebote y queja. El warm-up es disciplina operativa, no optimismo de marketing.

Una cita (idea parafraseada): Gene Kim suele enfatizar que los sistemas fiables vienen de prácticas disciplinadas y repetibles más que de heroísmos. Lo mismo aplica a la entregabilidad.

Hechos interesantes y contexto histórico (lo que explica las reglas actuales)

1. SMTP precede al spam. El protocolo de correo original asumía una red amistosa; la autenticación y controles de abuso se añadieron después.
2. SPF y DKIM nacieron de dolores distintos. SPF trató de validar IPs de envío; DKIM trató de integridad del mensaje y responsabilidad del dominio.
3. DMARC puso la “alineación” en primera fila. Antes de DMARC, “pasar algo” era suficiente; DMARC hizo al dominio visible responsable.
4. Los sistemas de reputación responden a la escala. Cuando los proveedores empezaron a manejar miles de millones de mensajes, el allowlisting manual murió y filtrado estadístico tomó el relevo.
5. Greylisting fue moda en su día. Fallos temporales para forzar reintentos solían disuadir spam. Hoy castiga a remitentes mal configurados y MTAs frágiles.
6. Emails solo-imagen se volvieron un tropo de spam. Los spammers usaban imágenes para evadir filtros de palabras; los proveedores respondieron con mejor OCR y heurísticas.
7. Las IP compartidas crearon “riesgo de vecino”. El auge de los ESP hizo la infraestructura compartida normal, y un mal actor puede arrastrar a todo el pool.
8. Los proveedores mayores exigen cada vez más alineación para remitentes masivos. Con el tiempo, la barra subió de “alguna autenticación” a “autenticación alineada más prácticas de listas sanas”.
9. Los rebotes son una señal de reputación, no solo un fallo de entrega. Altas tasas de unknown-user parecen recolección de listas o datos obsoletos, y los filtros reaccionan en consecuencia.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estos son los tipos de comprobaciones que puedes ejecutar hoy. Cada tarea incluye: un comando, una salida de ejemplo realista, qué significa y la decisión que tomas.

Task 1: Check if the mail queue is exploding (Postfix)

cr0x@server:~$ mailq | tail -n 20
-- 2150 Kbytes in 124 Requests.
AB12CD34EF     2190 Thu Jan  4 10:11:12  sender@example.com
                                         (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later (in reply to end of DATA command))
                                         user@gmail.com

Significado: Mucho correo diferido, con tempfails 421. Eso suele ser throttling, reputación o limitación por parte del proveedor.

Decisión: Para envíos masivos, deténlos, implementa control de velocidad y céntrate en reputación/autenticación antes de que la cola se convierta en tu nuevo sistema de monitorización.

Task 2: Inspect recent SMTP status codes for patterns

cr0x@server:~$ sudo grep -E "status=(bounced|deferred)" /var/log/mail.log | tail -n 15
Jan  4 10:11:12 mx1 postfix/smtp[22107]: AB12CD34EF: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.200.26]:25, delay=12, delays=0.2/0/2/9.8, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later)
Jan  4 10:11:18 mx1 postfix/smtp[22111]: CD34EF56GH: to=<user@outlook.com>, relay=outlook-com.mail.protection.outlook.com[52.101.68.9]:25, delay=3.2, delays=0.1/0/0.7/2.4, dsn=5.7.1, status=bounced (host outlook-com.mail.protection.outlook.com[52.101.68.9] said: 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.)

Significado: Gmail está tempfailing; Microsoft está bloqueando con 5.7.1 y rechazo basado en IP.

Decisión: Remediación separada por proveedor. Para Microsoft necesitas mejoras de reputación IP/dominio y probablemente flujos de delisting; para Gmail, reduce volumen y arregla autenticación/higiene de listas.

Task 3: Verify your outbound IP address (what the world sees)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Significado: Esta es la IP pública que los proveedores asocian a tus conexiones SMTP.

Decisión: Usa esta IP para comprobaciones PTR, listas negras (internamente o vía portal del proveedor) y cualquier escalado con tu ISP/ESP.

Task 4: Confirm reverse DNS (PTR) exists and matches your mail identity

cr0x@server:~$ dig +short -x 203.0.113.10
mx1.mail.example.com.

Significado: El PTR existe. A continuación, asegúrate de forward-confirmed reverse DNS (FCrDNS): el hostname resuelve de vuelta a la misma IP.

Decisión: Si PTR falta o es genérico (como un nombre de instancia cloud), arréglalo con tu ISP/proveedor cloud. Un PTR faltante conduce rápido a puntuaciones de “host sospechoso”.

Task 5: Verify forward DNS for the PTR hostname

cr0x@server:~$ dig +short mx1.mail.example.com A
203.0.113.10

Significado: FCrDNS pasa. Bien.

Decisión: Si no coincide, corrige DNS para que PTR y A sean consistentes.

Task 6: Check HELO/EHLO name your MTA presents

cr0x@server:~$ sudo postconf -n | grep -E "myhostname|smtpd_banner|smtp_helo_name"
myhostname = mx1.mail.example.com
smtp_helo_name = mx1.mail.example.com
smtpd_banner = $myhostname ESMTP

Significado: HELO coincide con un hostname real y resolvible. Reduce la vibra de “botnet”.

Decisión: Si ves “localhost” o un hostname cloud aleatorio, arréglalo. Importa más de lo que la gente cree.

Task 7: Validate SPF record exists and isn’t a hand grenade

cr0x@server:~$ dig +short TXT example.com | sed -n '1,5p'
"v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Significado: SPF autoriza tu IP y Microsoft 365, y termina con -all (fail duro). Está bien si es preciso.

Decisión: Si SPF falta o termina en ~all mientras intentas aplicar DMARC, estrecha la política. Si incluye demasiados proveedores que ya no usas, elimínalos.

Task 8: Check SPF DNS lookup count (the silent failure)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null 2>&1 || true
cr0x@server:~$ spfquery -ip 203.0.113.10 -sender bounce@example.com -helo mx1.mail.example.com -debug | tail -n 8
policy result: pass
mechanism: ip4:203.0.113.10
explanation: (none)
received-spf: pass (example.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender)

Significado: SPF evalúa como pass para esta IP de envío y el remitente de sobre.

Decisión: Si ves permerror o “too many DNS lookups”, simplifica SPF (aplana includes, elimina servicios antiguos). Un permerror SPF suele tratarse como “fail” en la práctica.

Task 9: Confirm DKIM public key is published for the selector you’re using

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtY..."

Significado: La clave existe en DNS. Después, asegúrate de que tu correo saliente realmente firme con ese selector y que las firmas verifiquen.

Decisión: Si falta el registro, publícalo. Si rotaste claves, asegúrate de que los selectores antiguos permanezcan hasta que todos los sistemas de envío dejen de usarlos.

Task 10: Verify DMARC record and policy

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; fo=1"

Significado: DMARC existe, con alineación estricta para SPF y DKIM. Es una postura fuerte.

Decisión: Si fallas la alineación por la herramienta de un proveedor, o arregla la herramienta o relaja la alineación temporalmente. Alineación estricta mal configurada es auto-sabotaje vestido de seguridad.

Task 11: Inspect a real message’s Authentication-Results (from headers)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|From:" -n sample.eml | head -n 30
12:From: "Example Support" <support@example.com>
45:DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed;
88:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@bounce.example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@bounce.example.com;
       dkim=pass header.i=@example.com header.s=s1;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Significado: SPF y DKIM pasan individualmente, pero DMARC falla. ¿Por qué? SPF está autenticando bounce.example.com (el dominio del sobre), que no está alineado con example.com. DKIM pasa y está alineado (d=example.com), así que DMARC debería pasar—a menos que la firma DKIM no cubriera correctamente el header From, o el proveedor haya visto un resultado de firma distinto al capturado.

Decisión: Vuelve a capturar desde el buzón receptor con cabeceras completas, confirma la alineación DKIM y asegúrate de que ningún sistema intermedio modifique el mensaje (footers, reescrituras) después de firmar. Si tienes un conector M365 o un gateway que añade disclaimers, puede romper DKIM.

Task 12: Check whether a gateway or disclaimer is breaking DKIM

cr0x@server:~$ sudo grep -R "disclaimer\|footer\|append" /etc/postfix /etc/opendkim /etc/mail 2>/dev/null | head
/etc/opendkim.conf:# OversignHeaders From

Significado: No se encontró mucho localmente. Eso sugiere que la modificación podría ocurrir upstream (p. ej., gateway corporativo, tracker del ESP o appliance de seguridad downstream).

Decisión: Rastrear la ruta del correo. Si algo modifica cuerpo/headers después de la firma DKIM, corrige el orden (firmar al final) o configura “oversigning” apropiadamente. O mueve las modificaciones a la etapa previa a la firma.

Task 13: Measure bounce rate by reason (log sampling)

cr0x@server:~$ sudo awk '/status=bounced/ {print $0}' /var/log/mail.log | tail -n 500 | \
awk -F'said: ' '{print $2}' | sed 's/[()]//g' | cut -c1-80 | sort | uniq -c | sort -nr | head
  88 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.
  41 550 5.1.1 <user@domain.com>: Recipient address rejected: User unknown
  19 554 5.7.1 Message rejected due to content restrictions

Significado: El error principal es un bloqueo de reputación/IP en Microsoft, no un problema de contenido. En segundo lugar usuarios desconocidos (higiene de listas). Tercero rechazo por contenido.

Decisión: Prioriza: (1) remediación de reputación con Microsoft, (2) suprime usuarios desconocidos inmediatamente, (3) revisa contenido y URLs solo después de dejar de sangrar.

Task 14: Verify TLS support on outbound (signals legitimacy)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.mail.example.com
Verification: OK

Significado: STARTTLS funciona y el certificado valida. Esto ayuda con cierta puntuación de proveedores y evita extrañezas por downgrade.

Decisión: Si TLS falla, arréglalo. Una cantidad sorprendente de “parecemos sospechosos” viene de TLS roto y nombres no coincidentes.

Task 15: Confirm you’re not an open relay (yes, still happens)

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_recipient_restrictions|mynetworks|smtpd_client_restrictions"
mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/8
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Significado: Rechazas relay no autenticado a dominios no locales. Bien.

Decisión: Si ves reglas permit antes de reject_unauth_destination o un mynetworks demasiado amplio, corrígelo ahora. Un open relay arruinará tu reputación más rápido de lo que puedes decir “revisión de incidente”.

Task 16: Rate-limit outbound to reduce tempfails and throttles

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 1s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf default_destination_rate_delay smtp_destination_concurrency_limit
default_destination_rate_delay = 1s
smtp_destination_concurrency_limit = 5

Significado: Estás ralentizando las entregas por destino, lo que reduce el throttling del proveedor y evita comportamiento en picos.

Decisión: Manténlo conservador durante la recuperación. Si la latencia transaccional se vuelve inaceptable, separa un flujo dedicado (IP/subdominio distintos) en lugar de subir el dial a 11.

Tres micro-historias corporativas (anonimizadas, plausibles y dolorosamente familiares)

Micro-historia 1: El incidente causado por una suposición incorrecta

Migraron de un ESP a otro durante un fin de semana. El plan parecía limpio: añadir el nuevo proveedor al SPF, publicar nuevas claves DKIM, cambiar la API de envío y listo. El lunes por la mañana, los emails de restablecimiento de contraseña empezaron a desaparecer. No rebotaban. Simplemente… no llegaban.

La suposición equivocada fue pensar que “SPF pasa es entregabilidad”. Su nuevo ESP usaba un return-path diferente para rebotes, y aunque SPF pasaba para ese dominio de rebote, la alineación DMARC fallaba para el dominio From visible. En su anterior ESP, DKIM estaba alineado y estable. En la nueva configuración, un gateway de seguridad intermedio añadió un footer después de que el ESP firmara, rompiendo DKIM a su llegada.

Así que los usuarios veían “support@example.com”, pero ni SPF ni DKIM sobrevivían de forma que satisficiera DMARC. Algunos proveedores cuarentenaron; otros silenciosamente mandaron a spam. El equipo persiguió plantillas y asuntos porque eso es lo que marketing puede cambiar rápido. Mientras tanto, la solución real fue: cambiar el comportamiento del gateway (no modificar después de firmar), firmar en el último salto y validar la alineación con cabeceras reales desde buzones receptores.

La acción de postmortem que importó: cada cambio en la ruta del correo requería una prueba que asegurara DMARC pass con alineación para cada proveedor importante, no solo “mensaje aceptado por remoto”. Empezaron a tratar el correo como tráfico de producción en vez de un servicio mágico que “simplemente funciona”.

Micro-historia 2: La optimización que salió mal

Un equipo de growth quería entregar campañas más rápido. Estaban convencidos de que su MTA era “muy lento”, porque los tiempos de envío se extendían horas. Un ingeniero aumentó los límites de concurrencia y eliminó retrasos de tasa. Los mensajes salieron como confeti.

Durante unos 30 minutos pareció genial. Luego llegaron los deferimientos: tempfails 421, “try again later”, y luego bloqueos totales por un proveedor mayor. La cola se infló. Se activaron tormentas de reintentos. El sistema de correo pasó el día siguiente golpeando a los mismos proveedores, demostrando repetidamente que no podía comportarse con educación.

En la revisión del incidente, la “optimización” se reclasificó como “modelado de tráfico agresivo en la dirección equivocada”. Los proveedores no rechazaban porque el contenido fuera peor; rechazaban porque el comportamiento del remitente parecía una botnet: pico, implacable y ajeno a la retropresión.

Las soluciones fueron aburridas: bajar concurrencia, implementar límites específicos por destino y escalonar campañas. Pero la corrección real fue organizativa: dejar de tratar la entregabilidad como ancho de banda. El email no es un protocolo de transferencia masiva de datos; es un protocolo de confianza con SMTP como transporte.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una SaaS mediana separó correo transaccional y marketing años atrás. No por una crisis—porque un SRE insistió “el radio de blast es real”. El correo transaccional salía desde mail.example.com en un pequeño pool de IPs dedicadas, con DMARC estricto y una canalización de plantillas bloqueada. Marketing salía desde news.example.com a través de un pool compartido de un ESP.

Un trimestre, marketing adquirió una lista de un partner (opt-in… según ellos). Las tasas de queja subieron. El pool del ESP empezó a tambalearse. Algunos dominios limitaron. La entregabilidad de marketing bajó. Molesto, pero soportable.

La parte importante: los restablecimientos de contraseña, facturas y emails de alerta siguieron llegando. Las métricas del stream transaccional se mantuvieron limpias: pocos rebotes, volumen estable, destinatarios consistentes. Los proveedores continuaron confiando en él porque se comportaba predeciblemente y los usuarios interactuaban positivamente.

El momento que “salvó el día” llegó durante un ciclo de facturación. Si las facturas hubieran ido a spam habría sido un incidente de ingresos. Lo evitaron porque alguien hizo la arquitectura aburrida con antelación: segregación, alineación y un plan de warm-up medido para cualquier cambio. A la producción le gusta lo aburrido.

Broma corta #2: Si tu plan de entregabilidad es “enviar con más fuerza”, felicitaciones—has reinventado la tormenta de reintentos, pero para marketing.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Gmail acepta (250 OK) pero los usuarios reportan colocación en spam

• Causa raíz: Bajo engagement y/o decadencia de la lista; contenido promocional; picos de volumen inconsistentes; señales de alineación faltantes.
• Solución: Reduce volumen, envía solo a interactuantes recientes, elimina destinatarios inactivos, asegura DKIM alineado y mantén cadencia consistente por 2–4 semanas.

2) Síntoma: Microsoft rebota con 550 5.7.1 mencionando tu IP

• Causa raíz: Daño de reputación de IP (riesgo de vecino en pools compartidos o tu propio comportamiento de rebotes/quejas). A veces también PTR faltante o TLS débil.
• Solución: Confirma PTR/HELO/TLS, reduce tasa, mejora higiene y sigue flujos de remediación específicos con tu proveedor de envío. Si estás en IP compartida, pide otro pool o una IP dedicada con warm-up.

3) Síntoma: Fallos DMARC aumentaron justo después de un cambio DNS o de proveedor

• Causa raíz: Desalineación entre el dominio From y los dominios autenticados; selector DKIM equivocado; gateway que modifica mensajes tras firmar; permerror SPF por límite de búsquedas.
• Solución: Valida con cabeceras reales, asegúrate de que DKIM firme con d= alineado al From, corrige SPF y elimina modificaciones post-firma.

4) Síntoma: Aumento súbito de rebotes “Usuario desconocido”

• Causa raíz: Lista obsoleta, contactos importados, dominios con errores tipográficos o validación de signup rota.
• Solución: Supresión inmediata de rebotes duros; validación de direcciones en captura; poner en cuarentena segmentos viejos; re-permissioning solo a usuarios comprometidos.

5) Síntoma: La cola de correo crece y la latencia de entrega transaccional se vuelve minutos/horas

• Causa raíz: Cola compartida entre bulk y transaccional; throttling del proveedor causando backlog global; reintentos excesivos saturando conexiones.
• Solución: Separa flujos (MTAs o transportes distintos), impón límites por destino, prioriza colas transaccionales y pausa bulk temporalmente.

6) Síntoma: Todo “pasa” pero un destinatario empresarial específico nunca recibe correo

• Causa raíz: Cuarentena del lado del destinatario, filtrado personalizado, o tu dominio/URL está bloqueado internamente; a veces su gateway rechaza silenciosamente.
• Solución: Consigue que el admin del destinatario proporcione logs por ID de mensaje y timestamp. Proporciona tus logs SMTP. Si es necesario, cambia URLs (dominios de tracking) y asegura identificadores consistentes.

7) Síntoma: DKIM falla ocasionalmente, no siempre

• Causa raíz: Modificaciones multi-salto; claves de firma mezcladas entre servidores; sistema de plantillas inyectando espacios dinámicos/ajustes de wrap tras la firma; múltiples firmas DKIM y una rompe.
• Solución: Firma en el hop final, estandariza configuración de firma, usa canonicalization relaxed/relaxed y prueba con capturas completas de cabeceras en varios proveedores.

8) Síntoma: La entregabilidad está bien hasta que ejecutas una campaña, luego todo empeora

• Causa raíz: Identidad compartida entre marketing y transaccional; picos de volumen entrenan filtros para desconfiar de todo el stream.
• Solución: Divide dominios/subdominios, separa selectores DKIM y usa IPs distintas si es posible. Como mínimo, separa dominios de sobre y patrones de tráfico.

Listas de verificación / plan paso a paso

Fase 0 (hoy): Estabilizar y detener la hemorragia

1. Pausar el bulk. Congela envíos de marketing que no sean operacionalmente esenciales.
2. Proteger lo transaccional. Si no puedes separar inmediatamente, al menos prioriza el correo transaccional en la cola y reduce el volumen bulk casi a cero.
3. Habilitar supresión estricta. Rebotes duros suprimidos de inmediato; rebotes suaves repetidos suprimidos tras un umbral sensato.
4. Reducir concurrencia y añadir retraso de tasa. Compórtate con cortesía; acepta la retropresión.
5. Elegir una muestra de control. Un pequeño cohorte comprometido más una lista de seed propia en los proveedores principales.

Fase 1 (24–72 horas): Diagnosticar con evidencia, no con sensaciones

1. Clasificar el modo de fallo. Rebote vs aceptado-pero-spam vs aceptado-y-perdido.
2. Extraer cabeceras reales. Confirma resultados SPF/DKIM/DMARC tal como los ve el proveedor receptor.
3. Comprobar básicos de identidad. PTR, HELO, validez del certificado TLS, IPs de envío consistentes.
4. Cuantificar rebotes. Principales códigos SMTP y su distribución por proveedor/dominio.
5. Encontrar el punto de inflexión. ¿Qué cambió alrededor del momento en que la reputación cayó? DNS, proveedor, pipeline de plantillas, adquisición de listas, ajustes de concurrencia.

Fase 2 (1–3 semanas): Reparar la confianza con warm-up controlado

1. Segmentar por engagement. Comienza con quienes interactuaron recientemente. Si no rastreas engagement, empieza a recogerlo ahora y acepta que la recuperación será más lenta.
2. Calentar gradualmente. Aumenta volumen despacio, mantiene cadencia consistente y vigila deferimientos/quejas como vigilas la CPU de una base de datos.
3. Mantener contenido estable. No hagas A/B testing durante una crisis de reputación.
4. Estabilizar URLs. Evita rotar acortadores o dominios de enlaces durante la recuperación. Las cadenas de redirección sospechosas no ayudan.
5. Separar flujos permanentemente. Transaccional vs marketing y, idealmente, notificaciones de producto como tercer flujo.

Fase 3 (continuo): Prevenir la próxima caída

1. SLOs de entregabilidad. Mide tasa de rebote, tasa de deferimiento, proxies de queja y indicadores de colocación por proveedor.
2. Gestión de cambios. Cambios en DNS y en la canalización de correo requieren pruebas y rollback, como cualquier config de producción.
3. Gobernanza de listas. Define fuentes permitidas de direcciones. No hay “lista de partner” sin puertas de calidad y reglas de supresión.
4. Simulacros de incidentes. Practica el guion de diagnóstico rápido trimestralmente. Tu yo futuro agradecerá menos enojo.

Preguntas frecuentes

1) ¿Cuánto tiempo lleva recuperar la reputación del remitente?

Días a semanas, dependiendo de cuánto daño y si arreglas el comportamiento subyacente. Las correcciones de autenticación ayudan de inmediato, pero las mejoras de engagement/higiene tardan en notarse.

2) ¿Deberíamos cambiar de ESP para arreglar la entregabilidad?

Solo si tu proveedor actual no te da control o visibilidad (o estás en un pool compartido envenenado). Cambiar sin arreglar higiene de listas y autenticación solo mueve el problema y añade riesgo de migración.

3) ¿Una IP dedicada resuelve problemas de reputación?

Elimina el riesgo de vecinos, no tu propio riesgo. Si tu lista es mala, una IP dedicada te da un lugar privado para quemar reputación. Aún necesitas warm-up e higiene.

4) ¿Deberíamos poner DMARC a p=reject para probar legitimidad?

No durante un lío de configuración. Aplica DMARC cuando sepas que tus remitentes legítimos pasan la alineación. Si no, rechazarás tu propio correo y lo llamarás “seguridad”.

5) ¿Por qué vemos tempfails 421 en lugar de rebotes duros?

Los proveedores suelen throttlear antes que bloquear inmediatamente, especialmente si creen que podrías ser legítimo pero actualmente riesgoso. Trátalo como retropresión y reduce la tasa; no golpees más fuerte.

6) ¿Cuál es la causa más común de “empeoró de repente”?

Cambios no rastreados: actualizaciones DNS, cambios en el enrutamiento del ESP o gateways que empiezan a reescribir mensajes y rompen DKIM. Lo segundo es la adquisición/importación de listas que dispara unknown users y quejas.

7) ¿El tracking de enlaces puede perjudicar la entregabilidad?

Sí. Los dominios de tracking compartidos pueden heredar problemas de reputación, las cadenas de redirección parecen phishy y dominios no coincidentes reducen confianza. Mantén dominios de tracking estables y alineados con tu marca, evita acortadores sospechosos.

8) ¿Por qué el correo transaccional sufre cuando marketing lanza una campaña?

Porque los uniste: mismo From, misma IP, misma identidad DKIM, mismas colas. Separa flujos para que un equipo no pueda accidentalmente DDoS tu relación de confianza con los proveedores.

9) Nuestros emails son “aceptados”. ¿Por qué los usuarios igual no los ven?

Aceptación no es colocación en bandeja. El correo puede ser aceptado y luego filtrado a spam, puesto en cuarentena por herramientas corporativas o dirigido a otra carpeta por reglas de usuario. Necesitas evidencia de cabeceras y logs del lado receptor para diferenciar.

10) ¿Sobre qué métricas deberíamos alertar?

Tamaño de cola, tasa de deferimiento por proveedor, tasa de rebotes duros, tasa de unknown-user y tasas de fallo de autenticación (los informes agregados DMARC ayudan). Alerta por cambios de tendencia, no solo por umbrales absolutos.

Siguientes pasos que puedes ejecutar esta semana

1. Congela envíos bulk por 48 horas mientras recopilas evidencia: códigos SMTP por proveedor, comportamiento de la cola y cabeceras reales de receptores.
2. Confirma corrección de identidad: PTR/FCrDNS, HELO, TLS, IPs salientes estables. Arregla las señales baratas primero.
3. Haz que DMARC pase con alineación para tu dominio From principal. Valida con cabeceras capturadas desde receptores Gmail y Microsoft.
4. Implementa supresión de rebotes duros inmediatamente y pon en cuarentena segmentos cuestionables. Los rebotes unknown-user son un impuesto de reputación que pagas con interés.
5. Separa flujos transaccional y marketing (al menos subdominios y selectores DKIM separados). Trátalo como control de radio de blast.
6. Calienta deliberadamente: volumen diario consistente, primero destinatarios comprometidos, rampas lentas y monitorización cuidadosa de deferimientos y quejas.

Si solo haces una cosa: detén los picos de volumen y deja de enviar a gente que no lo pidió. La autenticación te abre la puerta; el comportamiento decide si puedes quedarte.