Problemas de entrega en Gmail/Outlook: las comprobaciones que importan

octubre 25, 2025 • febrero 3, 2026 • Lectura: 23 min • Views: 10

¿Te fue útil?

Enviaste un correo perfectamente razonable. El cliente nunca lo vio. Soporte insiste en que “debe ser Gmail”, ventas asegura que “debe ser Outlook” y tu CEO reenvía capturas de pantalla de una bandeja de entrada vacía como si fueran una prueba forense.

Hoy en día, la entregabilidad tiene menos que ver con “si mi servidor SMTP habló el protocolo” y más con “si probé—criptográficamente, reputacionalmente y operativamente—que merezco estar en la bandeja de entrada”. Esta guía se centra en las comprobaciones que cambian resultados: qué mirar primero, qué es ruido y qué soluciones realmente permanecen en la siguiente campaña.

Guía de diagnóstico rápido (primeros 15 minutos)

Cuando la entrega a Gmail u Outlook “de repente” falla, hay una tentación de ajustar todo en pánico a la vez. No lo hagas. Necesitas encontrar el cuello de botella: autenticación, reputación, contenido o transporte.

0. Establece el modo de fallo (2 minutos)

Rebote: recibiste una NDR/DSN. Bien. Contiene pistas.
Retraso: respuestas 4xx; el correo se queda en la cola y “eventualmente” puede entregarse.
Spam: entregado pero marcado como basura; esto suele ser política + reputación.
Desaparición silenciosa: el sistema de envío dice “entregado”, el destinatario no lo encuentra. Podría ser spam/cuarentena, rechazos en el transporte o reglas de enrutamiento internas.

1. Comprueba primero la alineación de autenticación (5 minutos)

Hoy en día, pasar SPF o DKIM no es suficiente. La alineación con el dominio visible en From importa, especialmente para Gmail y Microsoft.

Obtén un mensaje real e inspecciona Authentication-Results.
Confirma DKIM=pass con tu dominio (o subdominio alineado).
Confirma SPF=pass y que el dominio SPF se alinea con From (o que DMARC con alineación relajada lo cubre).
Revisa DMARC=pass. Si DMARC falla, todo lo demás es una moneda al aire.

2. Luego revisa señales de reputación (4 minutos)

¿Pico repentino de rebotes, quejas o usuarios desconocidos? Eso es la muerte reputacional por hoja de cálculo.
¿IP de envío nueva o proveedor cambiado? El calentamiento importa. Sí, incluso si “solo envías recibos”.
¿Estás en una lista de bloqueo? No necesitas un doctorado: solo revisa los registros SMTP por rechazos tipo RBL.

3. Solo entonces revisa el transporte (4 minutos)

¿Estás fallando en la negociación TLS, en comprobaciones de MTA-STS, o te están limitando por tasa?
¿Tu cola crece y los reintentos retroceden?
¿Tus conexiones salientes provienen de la IP que crees que usan?

Si haces estos tres pasos en orden, evitas el incidente clásico donde todos discuten sobre el contenido mientras falta el selector DKIM en DNS.

Cómo falla la entrega hoy (y por qué parece aleatorio)

Gmail y Microsoft no evalúan tu correo como un humano. Lo puntúan como un riesgo de producción. La autenticación es condición mínima, pero sus sistemas también modelan historial del remitente, comportamiento del destinatario y patrones que parecen abuso—aunque tú “solo envíes facturas”.

La bandeja de entrada moderna está impulsada por políticas

Los requisitos de remitentes masivos de Gmail (y el filtrado cada vez más estricto de Microsoft) empujaron a la industria hacia una base: correo autenticado, higiene razonable de listas, gestión de quejas y infraestructura consistente. Eso no es “cosa de marketing”. Es higiene operativa. Tu sistema de correo es una API, y los proveedores de bandeja de entrada son la pasarela de API más exigente con la que te integrarás.

Cuatro categorías de fallo

Autenticación: SPF/DKIM/DMARC mal configurados, rotos por DNS o alterados por reenvíos/reescrituras.
Reputación: IP/domino nuevos, quejas por spam, muchos usuarios desconocidos, cuentas comprometidas o patrones repentinos.
Contenido y formato: URLs sospechosas, MIME malformado, falta de List-Unsubscribe, codificaciones raras o plantillas “demasiado perfectas”.
Transporte y políticas: errores TLS, aplicación de MTA-STS, límites de tasa, deferrals 4xx o bloqueos de red.

Aquí está la verdad incómoda: puedes pasar SPF, DKIM y DMARC y aún así ir a spam. Los proveedores tratan la autenticación como “prueba de identidad”, no como “permiso para la bandeja de entrada”.

Una cita para tener en la pared

La esperanza no es una estrategia. — General Gordon R. Sullivan

La depuración de entregabilidad tiene la misma regla. Si no puedes probarlo con cabeceras, registros y DNS, estás operando con vibras.

Datos interesantes y contexto histórico (edición entregabilidad)

SPF empezó como un mecanismo anti-suprfación, no como un impulso de entregabilidad. Se diseñó para reducir el spoofing vinculando “quién puede enviar” al DNS.
DKIM surgió de experimentos de firmado de dominio (incluyendo DomainKeys e Identified Internet Mail) y se convirtió en la forma de mantener integridad a través de saltos—hasta que intermediarios modifican mensajes.
DMARC formalizó la “alineación”: no basta autenticar; el dominio autenticado debe coincidir (alinearse) con el dominio From que ven los destinatarios.
Google y Microsoft aprendieron a desconfiar de “remitentes perfectos”: contenido inusualmente uniforme o patrones de interacción antinaturales pueden ser una señal de alarma, incluso para correo transaccional legítimo.
La reputación IPv4 se volvió un producto: las piscinas de IP compartidas y las IP dedicadas existen en gran parte porque los proveedores puntúan el historial de IP agresivamente.
ARC (Authenticated Received Chain) existe porque el reenvío rompe SPF y puede romper DKIM; ARC permite a los intermediarios preservar resultados de autenticación a través de saltos.
BIMI es una función de marca con peso: empuja a los remitentes hacia la aplicación estricta de DMARC porque la visualización del logo requiere una postura de política más fuerte.
Los filtros de spam pasaron de hacks por palabras clave a modelos de comportamiento: la interacción del usuario (aperturas, eliminaciones, respuestas, reportes de spam) influye en la colocación futura.
List-Unsubscribe se volvió un control operacional: los proveedores lo usan para reducir clics de “esto es spam” ofreciendo una baja limpia.

Broma #1: La entregabilidad del correo es como hacer dieta—todos juran que “hicieron todo bien”, pero los registros recuerdan lo que realmente pasó.

Cabeceras y códigos de rebote: deja de adivinar, empieza a leer

Si no estás leyendo las cabeceras crudas y las DSN, diagnosticas con los ojos vendados. Gmail y Microsoft incluyen suficiente metadatos para decirte qué falló—si sabes dónde mirar.

Cabeceras que importan

Authentication-Results: SPF/DKIM/DMARC pass/fail y a veces razones.
Received chain: confirma el host remitente y si un gateway reescribió el mensaje.
From, Return-Path, Sender: usados en la alineación y enrutamiento de rebotes.
Message-ID: útil para correlacionar con registros; también indica si tu aplicación genera IDs extraños.
List-Unsubscribe y List-Unsubscribe-Post: cada vez más importantes para correo masivo; la ausencia puede perjudicar.

Códigos de estado SMTP: lo que implican operativamente

5xx: rechazado. Esto no es un problema de reintentos. Arregla la causa.
4xx: diferido / temporal. A menudo limitación por tasa, bloqueos suaves por reputación o comprobaciones de política transitorias. La estrategia de reintentos importa.
2xx aceptado: aceptado por el MTA del destinatario, no necesariamente en bandeja de entrada. Para problemas de colocación en spam, enfócate en autenticación + reputación + contenido.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay tareas de grado producción que puedes ejecutar hoy. Cada una incluye: un comando, salida de ejemplo, lo que significa y la decisión que tomas a partir de ello. Asumen un host Linux con Postfix (común), pero el DNS y análisis de mensajes aplican en todas partes.

Task 1 — Identify your actual egress IP (not what you “think” it is)

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

Qué significa: Esa es la IP pública que ven los destinatarios (a menos que retransmitas vía un proveedor).

Decisión: Toda reputación, rDNS/PTR y listas blancas deben coincidir con esta IP. Si esperabas otra IP, detente: estás depurando la identidad de remitente equivocada.

Task 2 — Confirm reverse DNS (PTR) exists and matches your HELO strategy

cr0x@server:~$ dig +short -x 203.0.113.45
mail1.example.com.

Qué significa: La IP apunta a mail1.example.com.

Decisión: Configura Postfix smtpd_banner/myhostname y smtp_helo_name saliente para que HELO/EHLO sea un hostname válido que resuelva hacia la misma IP. Si no hay PTR, arréglalo—Microsoft en especial no gusta de rDNS ausente.

Task 3 — Check forward DNS for the sending hostname (A/AAAA)

cr0x@server:~$ dig +short mail1.example.com A
203.0.113.45

Qué significa: El nombre resuelve de vuelta a la IP.

Decisión: Si forward y reverse no coinciden, espera más throttling y problemas de colocación como spam. Arregla DNS antes de tocar el contenido.

Task 4 — Inspect SPF record and look for “too many DNS lookups” risk

cr0x@server:~$ dig +short TXT example.com | sed 's/" "/""/g'
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.45 -all"

Qué significa: SPF permite Google, Microsoft y una IP específica.

Decisión: Verifica que tus fuentes reales de envío coincidan con esto. Si tienes muchos include:, puedes exceder el límite de 10 búsquedas DNS de SPF. Si SPF ocasionalmente da “permerror”, simplifica SPF (aplana con cuidado o reduce includes).

Task 5 — Validate SPF for a specific IP using a local checker

cr0x@server:~$ spfquery -ip 203.0.113.45 -sender bounce@example.com -helo mail1.example.com
result=pass
smtp.comment=domain of bounce@example.com designates 203.0.113.45 as permitted sender

Qué significa: SPF pasa para el dominio del remitente del sobre.

Decisión: Si esto falla, arregla SPF. Si pasa pero DMARC falla después, la alineación es tu problema (dominio del sobre != dominio From, o la alineación relajada no satisface).

Task 6 — Check DKIM selector records exist in DNS

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

Qué significa: El selector s1 existe y publica una clave pública.

Decisión: Si esto está vacío o truncado, arregla DNS (a menudo TXT partidos) y vuelve a firmar el correo. Un selector faltante es una forma segura de acabar en carpeta spam a escala.

Task 7 — Verify DMARC policy and alignment mode

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

Qué significa: DMARC está aplicando quarantine, la alineación DKIM es estricta, SPF alineación relajada.

Decisión: Si usas remitentes terceros, la alineación DKIM estricta (adkim=s) puede romperlos a menos que firmen con tu dominio. Decide si relajar la alineación o reconfigurar remitentes para usar DKIM alineado.

Task 8 — Pull a live message from logs (Postfix) and inspect the response from Gmail/Microsoft

cr0x@server:~$ sudo grep -E "to=|status=" /var/log/mail.log | tail -n 20
Jan  3 10:17:12 mail1 postfix/smtp[24177]: 8F2C02A1B3: to=, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.2/0.1/1.2/0.6, dsn=2.0.0, status=sent (250 2.0.0 OK  1704277032 x12-20020a1709032f4c00b003b7c2c1a8d3si1234567plb.123 - gsmtp)
Jan  3 10:18:44 mail1 postfix/smtp[24210]: 1B7D02A1C9: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=45, delays=0.3/0.2/10/34, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

Qué significa: Gmail aceptó; Microsoft diferió con un error temporal 4.7.0.

Decisión: Los problemas con Gmail probablemente son colocación en spam, no transporte. Para deferrals en Outlook, revisa limitaciones por tasa, reputación y si estás enviando picos. No “arregles” aumentando la frecuencia de reintentos; eso suele empeorar el throttling.

Task 9 — Inspect the Postfix queue for stuck or exploding mail

cr0x@server:~$ mailq | head -n 25
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
1B7D02A1C9      4123 Fri Jan  3 10:18:44  bounce@example.com
                                         user@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

-- 1 Kbytes in 1 Request.

Qué significa: Tienes mensajes diferidos esperando en Outlook.

Decisión: Si la cola crece rápido, necesitas limitar la concurrencia saliente a Microsoft, mejorar reputación o mover envíos masivos fuera de tu IP transaccional. Si es una cola pequeña con comportamiento normal de reintentos, no te alarmes.

Task 10 — Confirm you are signing DKIM on the messages you think you are

cr0x@server:~$ sudo postcat -q 8F2C02A1B3 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            38912            392
sender: bounce@example.com
*** MESSAGE CONTENTS ***
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
 t=1704277032; bh=7yQf...; h=from:to:subject:date:mime-version;
 b=Z1m...
From: Example Billing 
To: user@gmail.com
Subject: Your receipt

Qué significa: El mensaje está firmado con DKIM con d=example.com, selector s1.

Decisión: Si falta la firma DKIM en ciertos caminos de la app (restablecimientos de contraseña vs facturas), probablemente tienes múltiples rutas de salida. Consolida o asegura que todas las rutas firmen de forma consistente.

Task 11 — Verify TLS handshake and certificate presentation to recipient MTAs

cr0x@server:~$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com -tls1_2 </dev/null | sed -n '1,25p'
CONNECTED(00000003)
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1
verify return:1
depth=1 C=US, O=Google Trust Services LLC, CN=GTS CA 1C3
verify return:1
depth=0 CN=gmail-smtp-in.l.google.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

Qué significa: El destinatario soporta TLS moderno; tu lado también debería.

Decisión: Si tu MTA saliente negocia TLS antiguo o falla STARTTLS, verás más deferrals y fallos por política. Actualiza librerías y Postfix, y asegura que tu política de cifrado no esté anclada en 2014.

Task 12 — Check whether your domain is publishing MTA-STS and whether it parses

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20250101T120000Z"

Qué significa: Publicas un id de política MTA-STS.

Decisión: Si afirmas MTA-STS pero tu host de política está roto, puedes causar problemas de entrega entrante hacia ti (no saliente). Aún vale la pena comprobarlo porque los tickets de “el correo está roto” raramente especifican la dirección.

Task 13 — Check local DNS resolution health (because broken resolvers cause flaky SPF/DKIM)

cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 1.1.1.1

Qué significa: Tu MTA depende de estos resolvers para comprobaciones SPF/DKIM/DMARC.

Decisión: Si tienes fallos intermitentes de entregabilidad, revisa timeouts de resolutores y secuestro de NXDOMAIN. Usa resolutores fiables y considera cache local (unbound) con timeouts sensatos.

Task 14 — Confirm your HELO name (Postfix) is what you intend

cr0x@server:~$ postconf smtp_helo_name myhostname | sed 's/^/postfix: /'
postfix: smtp_helo_name = mail1.example.com
postfix: myhostname = mail1.example.com

Qué significa: Tu salida se identifica como mail1.example.com.

Decisión: Si ves un HELO genérico como localhost o un hostname interno, arréglalo. No siempre es fatal, pero grita “no gestionado” a los sistemas de reputación.

Task 15 — Spot high bounce/unknown user rates fast (log sampling)

cr0x@server:~$ sudo grep -E "status=bounced|5\.1\.1|User unknown" /var/log/mail.log | tail -n 15
Jan  3 10:10:02 mail1 postfix/smtp[23910]: 9A1F12A0D2: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=3.2, dsn=5.1.1, status=bounced (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 550 5.1.1 RESOLVER.ADR.RecipNotFound; Recipient not found (in reply to RCPT TO command))

Qué significa: Estás enviando a destinatarios inexistentes.

Decisión: Detén la hemorragia. Pausa envíos masivos, limpia listas y aplica verificación de direcciones en el momento de captura. Altas tasas 5.1.1 dañan reputación rápidamente, especialmente en Microsoft.

Task 16 — Confirm you include List-Unsubscribe headers for bulk mail

cr0x@server:~$ sudo postcat -q 7C0A12A19F | grep -i -E '^List-Unsubscribe:|^List-Unsubscribe-Post:'
List-Unsubscribe: , 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Qué significa: Los mensajes masivos ofrecen opciones de baja limpias.

Decisión: Si envías marketing o actualizaciones de producto sin esto, agrégalo. Reduce quejas por spam, y ese es un palanca de entregabilidad que sí puedes controlar.

Broma #2: Si tu registro SPF tiene 14 includes, no es “seguridad”, es danza interpretativa de DNS.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa SaaS mediana tenía una configuración “simple”: servidores de app enviaban restablecimientos de contraseña a través de un proveedor en la nube, e invoices iban por una caja Postfix on-prem que llevaba funcionando desde la pasantía de alguien.

Lanzaron un nuevo dominio de marca. Marketing actualizó el From: visible a billing@newbrand.example en todas partes. No tocaron el remitente del sobre, que siguió siendo bounce@oldbrand.example. SPF pasó. DKIM pasó (por el dominio antiguo). DMARC falló. Silenciosa, consistente y catastróficamente.

La suposición errónea fue sutil: “Si SPF y DKIM pasan, DMARC pasará”. No es así. DMARC se preocupa por la alineación con el From visible. La identidad visible cambió; la autenticada no.

Los síntomas fueron feos pero confusos: Gmail entregó a spam, Outlook difería algunos correos y marcaba otros como basura, y los stakeholders internos insistían en que era “contenido” porque la plantilla había cambiado esa semana.

La solución fue aburrida e inmediata: firmar DKIM con d=newbrand.example y alinear el remitente del sobre, o usar alineación relajada con una estrategia de subdominios controlada. Una vez DMARC pasó de forma fiable, la colocación se recuperó en días, no minutos. Los sistemas de reputación tienen memoria; no son peces dorados.

Microhistoria 2: La optimización que salió mal

Otra compañía intentó “optimizar costos” consolidando todo el correo saliente—transaccional, marketing, notificaciones de socios—por una IP dedicada. Una IP para gobernarlos a todos. Un panel. Unas reglas de firewall. Alguien incluso lo llamó “simplificación”.

Funcionó hasta el boletín trimestral. El engagement fue mediocre, las bajas subieron y una fracción pequeña marcó “Reportar spam” porque el correo les resultó desconocido. Al día siguiente, los restablecimientos de contraseña empezaron a caer en spam para usuarios de Gmail y a diferirse en Microsoft.

Habían creado un acoplamiento de reputación: la corriente de correos peor comportada envenenó la más crítica para negocio. El incidente fue caro, pero la lección valió oro: separa tráfico según riesgo.

El plan de recuperación no fue mágico. Dividieron los envíos: una ruta IP/dominio para transaccional y otra para marketing, con distintos límites de tasa y puertas de higiene más estrictas en marketing. También implementaron listas de supresión y dejaron de enviar a direcciones inactivas. La entregabilidad volvió gradualmente, y la rotación on-call dejó de tratar los días de campaña como temporada de huracanes.

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

Una gran plataforma B2B tenía la costumbre que parecía burocrática: cada cambio DNS para autenticación de correo requería una revisión por pares y una “comprobación canario” desde un dominio de staging. Nadie lo amaba. Todos cumplían.

Un viernes, un ingeniero bienintencionado intentó rotar claves DKIM y limpiar “selectores antiguos”. La revisión detectó que una app legacy todavía firmaba con selector s0 porque estaba fijado en un archivo de configuración dentro de una imagen de contenedor que nadie quería reconstruir.

La rotación de claves salió con ambos selectores activos. Programaron la eliminación de s0 solo después de confirmar—vía registros—que ningún mensaje se estaba firmando con él. El cambio fue anodino, que es el único resultado aceptable para cambios de autenticación.

Dos semanas después una rotación similar en una organización partner causó fallos generalizados porque borraron el selector activo primero y preguntaron después. El correo de la plataforma siguió fluyendo y nadie fue paginado. La salvación no fue genialidad; fue un proceso de cambios diseñado para la realidad de que los sistemas de correo son extensos e inconsistentes.

Listas de verificación / plan paso a paso

Checklist A — Si usuarios de Gmail reportan “no recibir”

Consigue un ejemplo real: message ID, timestamp, dominio del destinatario y si se buscó en “Todos” y en Spam.
Determina: rebote, diferido o entregado desde tus registros.
Extrae las cabeceras crudas de una muestra entregada y confirma paso y alineación de DMARC.
Revisa DNS del selector DKIM existe y es estable (sin NXDOMAIN intermitente).
Confirma estabilidad de la IP de envío: sin cambios sorpresa de NAT, sin nuevos relays.
Valida higiene de listas si es masivo: usuarios desconocidos y quejas te hundirán.
Segmenta flujos: mantiene transaccional aislado de marketing si valoras dormir.

Checklist B — Si Outlook/Microsoft difiere o rechaza

Lee el código de estado SMTP mejorado: 4.7.x (throttle), 5.7.x (política/autenticación), 5.1.1 (destinatarios malos).
Revisa rDNS y HELO: Microsoft no es sentimental con remitentes mal configurados.
Raciona y suaviza: envíos en ráfaga disparan deferrals; reduce concurrencia y sube gradualmente.
Busca cuentas comprometidas: los deferrals de Microsoft suelen coincidir con picos repentinos desde una identidad remitente.
Separa masivo vs transaccional por IP/dominio si no lo has hecho.
Confirma alineación DKIM/DMARC y que las cabeceras no sean reescritas por relays intermedios.

Checklist C — Línea base de autenticación para 2025 (hazlo una vez, luego monitorea)

SPF: includes mínimos; -all cuando estés seguro; mantener bajo 10 búsquedas DNS.
DKIM: claves 2048-bit donde sea posible; rota; documenta selectores.
DMARC: comienza en p=none para observar, luego quarantine y luego reject cuando los flujos alineados estén limpios.
Estrategia de alineación: decide si From usa dominio raíz o subdominio dedicado; mantén consistencia.
ARC: si manejas reenvíos (helpdesk, ticketing), implementa ARC para preservar confianza de autenticación.
List-Unsubscribe: incluye para masivo; soporta un clic si puedes.

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

Estos son los fallos que veo repetidamente en producción. No son glamorosos, pero son la razón por la que tu correo “funciona en staging” y está maldito en el mundo real.

1) Síntoma: Gmail acepta (250 OK) pero usuarios encuentran correo en Spam

Causa raíz: DMARC falla o pasa de forma inconsistente; reputación del remitente degradada; cabeceras masivas ausentes.
Solución: Haz que DMARC pase con SPF o DKIM alineado. Añade List-Unsubscribe para masivo. Separa marketing de transaccional. Deja de enviar a listas frías.

2) Síntoma: Outlook devuelve 451 4.7.0 error temporal para muchos destinatarios

Causa raíz: Throttling por reputación, tasa en ráfaga o mala higiene de IP (rDNS/HELO desajustado).
Solución: Suaviza envíos (menos concurrencia, cadencia consistente). Arregla rDNS y HELO. Separa flujos. Limpia conjuntos de destinatarios con muchos rebotes.

3) Síntoma: “SPF pasa” pero DMARC falla

Causa raíz: El dominio SPF es el del remitente del sobre, no alineado con From.
Solución: Usa un dominio return-path alineado (o subdominio) y asegura que SPF autorice la fuente real; o confía en DKIM alineado para que DMARC pase.

4) Síntoma: DKIM a veces falla solo en ciertos tipos de mensajes

Causa raíz: Múltiples caminos de salida; una ruta no firma, o un relay modifica cuerpo/cabeceras después de firmar.
Solución: Centraliza el firmado en el último hop de confianza. Asegura que la canonicalización sea apropiada. Evita intermediarios que reescriban contenido post-firma.

5) Síntoma: Colapso repentino tras una “limpieza” de DNS

Causa raíz: Borraron un selector DKIM activo; rompieron la cadena de includes de SPF; cambiaron la política DMARC demasiado agresiva.
Solución: Restaura selectores. Implementa DMARC gradualmente (pct, monitoriza reportes). Trata DNS de autenticación como configuración de producción, no como hobby.

6) Síntoma: Alta tasa de rebotes (5.1.1) y luego todo empeora

Causa raíz: Fallo en higiene de listas; listas antiguas; errores tipográficos; abuso de registros.
Solución: Implementa supresión, validación y doble opt-in cuando corresponda. Deja de enviar a direcciones que rebotan duramente—inmediatamente y automáticamente.

7) Síntoma: Mensajes desaparecen al reenviarse (especialmente a Gmail)

Causa raíz: El reenvío rompe SPF; DKIM se rompe por modificaciones; la política DMARC causa rechazo/cuarentena.
Solución: Fomenta reenvíos modernos que soporten ARC. Para tus servicios de reenvío, implementa ARC y evita reescrituras de contenido.

8) Síntoma: Pruebas internas funcionan, receptores externos fallan

Causa raíz: Pruebas contra MTAs internos permisivos. Proveedores externos aplican políticas y puntuaciones de reputación más estrictas.
Solución: Prueba con buzones externos reales, inspecciona cabeceras y estaciona cambios de autenticación con dominios canario.

Preguntas frecuentes

1) “No somos remitente masivo. ¿Importan las reglas de bulk de Gmail?”

Importan indirectamente. Los proveedores aplican cada vez más expectativas “tipo masivo” (autenticación, patrones de baja, control de quejas) a cualquiera que se comporte como masivo—incluso por accidente. Un remitente transaccional con una cuenta comprometida puede parecer masivo en minutos.

2) Si SPF pasa, ¿por qué Outlook aún nos limita?

Porque SPF es identidad, no reputación. El throttling suele deberse a patrones de tasa, usuarios desconocidos, señales de queja y higiene de infraestructura (rDNS/HELO). Pasar SPF no te garantiza carril rápido.

3) ¿Debemos poner DMARC en p=reject de inmediato?

Solo si estás seguro de que cada flujo legítimo se alinea (SPF o DKIM) y has observado los reportes el tiempo suficiente para detectar remitentes legacy raros. Si no, rechazarás tu propio correo y lo llamarás “seguridad”.

4) ¿Es DKIM o SPF más importante en 2025?

DKIM suele ser más robusto para la alineación DMARC porque SPF falla con reenvíos y algunos relays. La mejor práctica sigue siendo: publica ambos, asegura que al menos uno esté alineado y monitoriza resultados DMARC.

5) ¿Un cambio de contenido por sí solo puede causar colocación en spam?

Sí, pero el contenido suele ser el multiplicador, no la causa raíz. Si tu autenticación y reputación están sanas, los ajustes de contenido raramente causan una caída total. Si ya estás al límite, un cambio “inocente” (nuevo dominio de enlaces, acortadores, cambios de tracking) puede inclinar la balanza.

6) ¿Por qué algunos destinatarios reciben el correo y otros no?

Los proveedores hacen puntuación por destinatario y por dominio. Un remitente puede ser temporalmente limitado para ciertas regiones, clusters de buzones o cohortes de destinatarios. Además, tu propio sistema puede enrutar correo de forma diferente según el dominio del destinatario (relays y IPs diferentes).

7) ¿Cuál es el único artefacto más útil para pedir a un usuario?

Las cabeceras completas de un mensaje que aterrizó en spam, o el texto exacto del rebote/NDR. Las capturas son decorativas; las cabeceras son evidencia.

8) ¿Cambiar nuestra IP de envío ayuda?

A veces, pero también es una excelente manera de resetear tu reputación a “desconocida”, lo cual puede ser peor. Cambia IPs cuando la actual esté irremediablemente intoxicada o compartida con actores malos, y planifica un warm-up.

9) Usamos una plataforma de correo de terceros. ¿Qué podemos controlar realmente?

Más de lo que piensas: estrategia de dominio From, alineación DKIM, política DMARC, higiene de listas, segmentación (transaccional vs marketing), contenido/dominios de enlaces y cadencia de envío. También puedes elegir IPs compartidas vs dedicadas y cómo incorporarlas/realizar warm-up.

10) ¿Por qué los dashboards de “entregado” discrepan con la realidad?

Muchos dashboards significan “aceptado por el MTA del destinatario”, no “en bandeja de entrada”. La colocación en la bandeja es un resultado separado. Usa cabeceras, bucles de retroalimentación de destinatarios (cuando estén disponibles) y tus propios métricos de engagement para validar.

Conclusión: pasos siguientes que resisten la carga

Los incidentes de entregabilidad se sienten personales porque bloquean dinero y confianza. Pero las soluciones son mecánicas: prueba identidad (SPF/DKIM/DMARC alineados), protege reputación (higiene y segmentación) y mantén el transporte aburrido (rDNS, forward DNS, HELO, TLS, comportamiento de reintentos sensato).

Pasos siguientes que realmente mueven la aguja:

Elige un ejemplo fallido (destinatario + timestamp) y tracea de extremo a extremo usando registros y cabeceras.
Haz que DMARC pase consistentemente con alineación. No negocies este requisito.
Separa flujos transaccionales y masivos por IP y/o dominio, y aplica higiene más estricta en masivo.
Estabiliza la identidad de infraestructura: rDNS, DNS forward, nombre HELO y IP de salida consistente.
Añade guardarraíles operativos: revisión de cambios DNS, inventario de selectores DKIM, monitorización de colas, alarmas de tasa de rebote.

Los proveedores de bandeja no son tus amigos, pero son predecibles si tratas el correo como tráfico de producción. Mide. Verifica. Cambia una cosa a la vez. Y mantén los registros cerca.