SPF/DKIM pasan pero aún van a spam: señales ocultas que corregir

Guía rápida de diagnóstico (encuentra el cuello de botella rápido)

Cuando ocurre “SPF/DKIM pasa pero igual va a spam”, la gente entra en pánico y empieza a recorrer el DNS al azar.
No lo hagas. Trátalo como un incidente. Triagén primero, arregla después.

1) Confirma que el problema es la colocación, no la aceptación

• Comprueba si el mensaje fue aceptado (250 OK) y dónde termina: spam vs promociones vs bandeja principal sigue siendo entrega, solo que con mal posicionamiento.
• Si ves diferimientos/bloqueos (4xx/5xx), tienes una puerta de reputación o política, no un “filtro anti-spam”. Otro conjunto de acciones.

2) Toma un mensaje real y lee los encabezados como un detective

• Autenticación: SPF=pass, DKIM=pass, DMARC=pass es necesario, no suficiente.
• Alineamiento: que DMARC “pase” no siempre significa lo que piensas si usas subdominios, múltiples identidades From o remitentes terceros.
• ARC: si el correo se reenvía (listas de correo, sistemas de tickets), ARC puede marcar la diferencia entre “pasa” y “parece forjado”.

3) Decide qué eje está fallando: identidad, infraestructura o comportamiento

• Identidad: desalineamiento, dominios From extraños, patrones Reply-To rotos, selectores DKIM inconsistentes.
• Infraestructura: rDNS, HELO, postura TLS, reputación de IP/dominio, vecinos en IP compartida, patrones de tasa, timeouts.
• Comportamiento: higiene de listas, tasa de quejas, engagement, picos súbitos de volumen, dominios “fríos”, huellas de contenido.

4) Arregla la palanca más grande primero

• Altas quejas y mala higiene de listas ahogan un SPF/DKIM perfecto.
• Un rDNS/HELO malo y un TLS dudoso pueden hundirte antes de que se evalúe el contenido.
• Un DMARC desalineado puede hacerte parecer un suplantador aun cuando las firmas son correctas.

Idea parafraseada de Werner Vogels: “Todo falla todo el tiempo; diseña para ello.” La entregabilidad es igual: asume desconfianza, luego gana confianza repetidamente.

Qué prueban realmente SPF/DKIM/DMARC (y qué no prueban)

SPF: “esta IP está autorizada a enviar para ese dominio”

SPF comprueba el remitente del sobre (MAIL FROM / Return-Path), no el encabezado From visible por humanos.
Que SPF pase puede coexistir con un dominio From que no tenga nada que ver. Por eso existe DMARC.

DKIM: “este dominio firmó este contenido”

DKIM valida que un dominio firmante (el valor d=) firmó ciertos encabezados y el cuerpo.
DKIM no dice nada sobre si los destinatarios te quieren o no.

DMARC: “el From visible se alinea con SPF o DKIM”

DMARC es la capa de política. Comprueba si el dominio que ve el usuario en From se alinea (estricta o relajadamente) con el dominio autenticado por SPF
o con el dominio firmante de DKIM.

Lo que no prueban

• Que tengas una buena reputación de envío.
• Que tu lista sea basada en permisos y con pocas quejas.
• Que tu contenido no sea spammy o con apariencia de phishing.
• Que tu infraestructura se parezca a un sistema de correo real (rDNS/HELO/TLS consistentes).
• Que tus patrones de envío parezcan estables y humanos.

La autenticación es como un pasaporte. Prueba que eres quien dices ser.
No prueba que seas divertido en las fiestas. A los proveedores de bandeja les importa la fiesta.

Hechos interesantes y contexto histórico (8 apuntes rápidos)

1. SPF data de principios de los 2000 y surgió de una era caótica de remitentes de sobre falsificados y “identificador de llamadas para correo”.
2. DKIM se estandarizó después tras la convergencia de DomainKeys e Identified Internet Mail en un único mecanismo.
3. DMARC vino de los operadores (grandes proveedores de buzones y remitentes) que querían una capa de política, no solo prueba criptográfica.
4. El alineamiento fue la innovación clave: DMARC hizo exigible el dominio From visible por humanos.
5. El reenvío rompe SPF por diseño porque la IP del reenviador no está autorizada en el registro SPF original.
6. Las listas de correo a menudo rompen DKIM al modificar asuntos o cuerpos (añadir pies de página), invalidando firmas.
7. Los sistemas de reputación existen antes de DMARC: los proveedores han usado puntajes de comportamiento de IP/dominio mucho tiempo.
8. TLS se convirtió en una señal de entregabilidad no por moda, sino porque la encriptación oportunista se correlaciona con remitentes legítimos.

Broma #1: La entregabilidad de email es el único deporte donde puedes hacerlo todo bien y aun así perder contra el botón “darse de baja” de otra persona.

Señales ocultas que deciden bandeja vs spam

1) Reputación de dominio y reputación de IP son separadas, y ambas importan

Los proveedores te puntúan en múltiples ejes: la IP desde la que envías, el dominio en el From visible, el dominio d= de DKIM,
el dominio del Return-Path y a veces los URLs que incluyes. Puedes tener un dominio impecable y una IP terrible (pools compartidos),
o una IP decente y un dominio nuevo que parece un teléfono precario.

Si estás en infraestructura compartida, el comportamiento de tu vecino puede salpicar sobre ti. Si tienes IPs propias,
el calentamiento y la consistencia importan más que la corrección DNS.

2) Que DMARC “pase” no garantiza cordura en la alineación de marca

DMARC puede pasar mientras tu mensaje sigue pareciendo sospechoso para las capas de contenido y UI. Ejemplo:
From: billing@yourbrand.com, pero Reply-To es otro dominio, y los enlaces van a un tercer dominio,
y el cuerpo parece un restablecimiento de contraseña. Técnicamente válido. Prácticamente aterrador.

3) Nombre HELO/EHLO, rDNS y consistencia son señales de confianza

Una cantidad sorprendente de correo se puntúa antes de evaluar completamente el cuerpo. Si tu saludo SMTP dice
localhost o un hostname aleatorio de la nube, y tu rDNS no coincide, has introducido fricción.
No siempre es fatal. A menudo es acumulativo.

4) Postura TLS: la encriptación no es obligatoria en todas partes, pero su ausencia huele mal

TLS oportunista es lo normal. No tener TLS, suites de cifrado obsoletas o cadenas de certificados rotas puede empujarte hacia la categoría de “remitente barato”.
Añade MTA-STS e informes TLS si vas en serio. No es solo teatro de seguridad; reduce riesgo de degradación y errores de enrutado.

5) La tasa de quejas vence tus intenciones siempre

Puedes jurar que tus destinatarios optaron por recibir. Los proveedores de bandeja creen el comportamiento del destinatario, no tu hoja de cálculo.
Las quejas son veneno; los rebotes son advertencias; la falta de engagement es muerte lenta.

6) Señales de engagement: las aperturas son menos fiables, pero la interacción importa

Los proveedores modelan si los destinatarios leen, responden, mueven a carpetas, eliminan sin leer o marcan como spam.
“Mi CEO lo abrió” no es una métrica. Segmenta por destinatarios comprometidos.

7) Huellas de contenido: plantillas, reputación de URLs y estructura “phishy”

Puedes ser marcado por tu propio sistema de diseño. Plantillas reutilizadas, frases repetidas de llamada a la acción,
acortadores de URL, dominios de marca que no coinciden y tipos de adjuntos activan modelos.
Además: la reputación de tus dominios de enlace importa. Si tu dominio de tracking es nuevo o ha sido abusado, heredas ese olor.

8) Unsubscribe y encabezados List-Unsubscribe son primitivos de entregabilidad hoy

Si los usuarios no pueden irse fácilmente, lo harán de manera brusca. Los proveedores lo notan.
Implementa un darse-de-baja con un clic cuando sea posible, y haz que funcione. No “funcione la mayoría de las veces”.

9) Manejo de rebotes y listas de supresión: aburrido, esencial

Si sigues enviando a direcciones muertas, pareces un spammer que compró una lista. Porque eso es exactamente lo que hacen los spammers.
Los rebotes duros deben suprimir rápidamente. Los rebotes suaves necesitan política (ventana de reintento, luego suprimir).

10) Patrones de envío: picos de volumen, cambios de horario y penalizaciones por “nuevo flujo”

Los motores de entregabilidad aman la predictibilidad. Picos súbitos, nuevos tipos de mensajes o cambiar de proveedor pueden parecer toma de control de cuenta.
Calienta nuevas IPs, escala nuevos flujos y evita lanzar campañas masivas a listas frías.

Broma #2: Tu servidor de correo es como el portero de un club nocturno: no le importa cuán bonito sea tu registro SPF, le importa con quién llegaste.

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

Estas son comprobaciones de nivel operador. Ejecútalas, captura salidas, toma decisiones. No “sientas” la entregabilidad.

Task 1: Inspecciona el registro SPF y cuenta búsquedas DNS

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.mailvendor.net ip4:203.0.113.10 -all"

Qué significa: SPF existe y usa un include más una IP directa. Buen comienzo.
Decisión: Si ves muchos includes, aplana o simplifica. SPF tiene un límite de 10 búsquedas DNS; excederlo produce permerror y dolor silencioso.

Task 2: Evalúa SPF desde una IP específica de envío

cr0x@server:~$ spfquery --ip 203.0.113.10 --sender bounce@example.com --helo mail.example.com
pass (sender SPF authorized)

Qué significa: Esa IP está autorizada para el dominio del sobre.
Decisión: Si esto devuelve fail o softfail, arregla SPF antes de cualquier otra cosa. Si devuelve permerror, probablemente excediste búsquedas o hay sintaxis incorrecta.

Task 3: Comprueba que el selector DKIM existe y es sensato

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

Qué significa: El selector s1 publica una clave pública.
Decisión: Si no hay registro, DKIM fallará. Si el registro está dividido entre múltiples cadenas incorrectamente, algunos validadores fallan—publica correctamente.

Task 4: Verifica la política DMARC y el modo de alineamiento

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

Qué significa: DMARC está en quarantine con alineamiento relajado para SPF y DKIM.
Decisión: Si pasas SPF/DKIM pero aún vas a spam, la política DMARC no es la palanca. Úsala para asegurar que el alineamiento no esté fallando accidentalmente en algunos flujos.

Task 5: Comprueba rDNS (PTR) para tu IP de envío

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

Qué significa: PTR está configurado.
Decisión: Si falta PTR, es genérico o apunta a dominios no relacionados, arréglalo. Muchos receptores tratan la falta de PTR como señal de baja confianza.

Task 6: Verifica reverse DNS confirmado hacia adelante (FCrDNS)

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

Qué significa: El nombre PTR resuelve de vuelta a la misma IP.
Decisión: Si hacia adelante y hacia atrás no coinciden, alinéalos. Esto es higiene básica y elimina una excusa fácil para el filtrado.

Task 7: Inspecciona el banner SMTP/HELO desde el exterior

cr0x@server:~$ nc -v mail.example.com 25
Connection to mail.example.com 25 port [tcp/smtp] succeeded!
220 mail.example.com ESMTP Postfix

Qué significa: El banner es un hostname real, no localhost.
Decisión: Si el banner o HELO es raro, arregla Postfix smtpd_banner y myhostname. La inconsistencia grita “VM comprometida”.

Task 8: Verifica STARTTLS y la cadena de certificados

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK
Server Temp Key: X25519, 253 bits

Qué significa: STARTTLS funciona, TLS moderno, el certificado valida.
Decisión: Si la verificación falla, arregla la cadena de certificados. Si falta TLS, añádelo. Esto no te llevará mágicamente a la bandeja, pero evita una excusa fácil para degradarte.

Task 9: Comprueba si estás en listas negras DNS comunes (señal, no evangelio)

cr0x@server:~$ for z in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
  q=$(echo 10.113.0.203 | awk -F. '{print $4"."$3"."$2"."$1}'); \
  echo -n "$z: "; dig +short ${q}.${z} A; done
zen.spamhaus.org:
bl.spamcop.net:
b.barracudacentral.org:

Qué significa: No aparece en esas zonas (salida vacía).
Decisión: Si estás listado, investiga por qué: host comprometido, malas prácticas de listas o problemas de IP compartida. Deslistarse es papeleo; la prevención es ingeniería.

Task 10: Revisa la cola de Postfix por acumulación (el backlog puede parecer spamoso)

cr0x@server:~$ mailq | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A01234A*     2480 Mon Jan  4 10:12:01  bounce@example.com
                                         user1@gmail.com
                                         user2@outlook.com

Qué significa: Mensajes están en cola (el asterisco indica activo).
Decisión: Si la cola crece durante los envíos, puedes estar siendo rate-limited o greylisted. La entrega lenta puede agrupar reintentos y crear patrones sospechosos. Ajusta concurrencia y comportamiento de reintento con cuidado, no agresivamente.

Task 11: Inspecciona códigos de respuesta SMTP en logs (¿te están limitando?)

cr0x@server:~$ grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 5
Jan  4 10:14:22 mail postfix/smtp[22101]: 3F2A01234A: to=<user1@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=12, delays=0.1/0.02/5/6.9, dsn=4.7.28, status=deferred (host gmail-smtp-in.l.google.com[142.250.27.26] said: 421-4.7.28 [203.0.113.10] Our system has detected an unusual rate of unsolicited mail...)
Jan  4 10:14:25 mail postfix/smtp[22102]: 9ADBC1234B: to=<user2@outlook.com>, relay=outlook-com.olc.protection.outlook.com[52.101.73.8]:25, delay=8.2, delays=0.1/0.01/3.3/4.8, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[52.101.73.8] said: 451 4.7.0 Temporary server error. Please try again later.)

Qué significa: Te están limitando / apliando reputación (4.7.x).
Decisión: Deja de “enviar más fuerte.” Reduce volumen, segmenta a destinatarios comprometidos, arregla quejas, calienta IPs y asegura que no mezcles marketing con transaccional en la misma IP/dominio.

Task 12: Verifica alineamiento en un encabezado recibido real (resultados SPF/DKIM/DMARC)

cr0x@server:~$ sed -n '1,80p' sample-headers.txt
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=abc123;
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Qué significa: El alineamiento está bien: header.from coincide con el dominio DKIM y SPF mailfrom es del mismo dominio organizacional.
Decisión: Si DMARC falla o muestra desalineamiento, arregla la arquitectura de identidad o configura al proveedor para firmar con tu dominio y usar return-path alineado.

Task 13: Comprueba que existan encabezados List-Unsubscribe (y que no estén rotos)

cr0x@server:~$ grep -i "^List-Unsubscribe" -n sample-headers.txt
42:List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/unsub?u=abcd>
43:List-Unsubscribe-Post: List-Unsubscribe=One-Click

Qué significa: Ofreces mailto y un darse-de-baja con un clic.
Decisión: Si falta, impléméntalo. Si está pero tu endpoint es inestable, arregla la fiabilidad primero—un unsubscribe roto genera quejas.

Task 14: Confirma que tu dominio de envío no se usa para tracking web en un host “nuevo”

cr0x@server:~$ dig +short CNAME click.example.com
tracking.vendor-mail.net.

Qué significa: Tu click tracking usa un dominio de proveedor vía CNAME.
Decisión: Si ese dominio de tracking tiene mala reputación, puede arrastrar tu correo abajo. Considera desactivar el tracking de clics en flujos sensibles o moverlo a un subdominio reputado y con historial.

Task 15: Busca cambios súbitos de volumen analizando logs

cr0x@server:~$ awk '{print $1" "$2" "$3}' /var/log/mail.log | sort | uniq -c | tail
  88 Jan  4 10:12
  91 Jan  4 10:13
  96 Jan  4 10:14
 420 Jan  4 10:15
 110 Jan  4 10:16

Qué significa: Hay un pico a las 10:15.
Decisión: Si los picos correlacionan con colocación en spam, suaviza la tasa de envío, divide campañas y escala gradualmente. A la entregabilidad no le gustan las fiestas sorpresa.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana migró el correo transaccional de un proveedor a “Postfix interno en una IP limpia”.
SPF y DKIM pasaron ambas en pruebas. DMARC reportó pase. Todos chocaron manos y siguieron adelante.

En 48 horas, los correos de restablecimiento de contraseña empezaron a llegar a spam para una porción no trivial de usuarios.
Llegaron tickets de soporte con la clásica línea: “No estoy recibiendo emails.” Ingeniería comprobó: el correo era aceptado (250),
sin rebotes, sin bloqueos. ¿Entonces debe ser “error del usuario”, verdad?

La suposición equivocada fue creer que pasar autenticación y tener logs limpios equivale a colocación en bandeja. No es así.
Habían cambiado del espacio de IPs ya calentadas del proveedor a una IP nueva sin historial, y luego enviaron un gran pico durante un periodo de altas inscripciones.
Para los proveedores de buzones, eso parece menos “servicio fiable” y más “nuevo remitente intentando escalar rápido”.

La solución no fue más DNS. Fue operacional: ralentizar los envíos transaccionales (sí, duele), priorizar destinatarios comprometidos
y hacer calentamiento intencional. También separaron transaccional de marketing en subdominios e IPs distintos
para que uno no pudiera envenenar al otro. Tras un par de semanas de comportamiento estable, la colocación se recuperó.

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

Una compañía retail se volvió lista. Quisieron reducir el tiempo de procesamiento de rebotes y “mejorar el rendimiento”,
así que ajustaron su MTA para reintentar mensajes diferidos más agresivamente, aumentaron la concurrencia y acortaron tiempos de backoff.
En papel: entrega más rápida. En realidad: un desastre en cámara lenta.

Los grandes proveedores de buzones respondieron con más throttling. Sus logs se llenaron de diferimientos 4.7.x.
La cola empezó a oscilar: enormes picos de reintentos, luego más diferimientos, luego picos aún mayores.
Lo que parecía “reintentos eficientes” pareció a los receptores un remitente que no toma la pista.

La colocación en spam empeoró en todos los frentes, incluso para mensajes que antes tenían buen rendimiento.
No era el contenido. No era DKIM. Era comportamiento en la capa SMTP: el patrón de reintentos del remitente se volvió ruidoso y maquinal.

La reversión fue aburrida: restaurar cronogramas conservadores de reintento, reducir concurrencia e introducir limitación por dominio.
También empezaron a tratar 4.7.x como señal para reducir la velocidad, no como desafío a vencer.
La ironía: la entrega fue más rápida para los destinatarios importantes, porque dejaron de activar los throttles.

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

Una empresa relacionada con salud tenía requisitos estrictos de entregabilidad para recordatorios de citas.
Hicieron algo poco cool: ejecutaron tareas semanales de higiene de listas, procesaron rebotes en horas
y mantuvieron una lista de supresión que nadie podía omitir sin ticket y nota de auditoría.

Un trimestre, el equipo de marketing importó una “lista de reactivación” desde una exportación antigua de CRM.
No fue maliciosa. Solo estaba obsoleta. El primer envío produjo una ola de rebotes duros y un aumento notable de quejas.

Aquí las prácticas aburridas les salvaron: la supresión automatizada actuó de inmediato, eliminando direcciones muertas antes de una segunda ola.
Sus sistemas también marcaron el pico de quejas y pausaron más envíos hasta revisión. El correo transaccional siguió en infraestructura separada.

Las consecuencias fueron leves: una pequeña caída temporal en la colocación de mensajes de marketing, pero cero impacto en los recordatorios.
No hubo cambios DNS de emergencia, ni frenéticos “aplanados de SPF”, ni culpables del proveedor. Solo higiene disciplinada y separación de responsabilidades.

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

1) Síntoma: SPF/DKIM pasan, DMARC pasa, pero Gmail dice “mensajes similares fueron identificados como spam”

Causa raíz: mal engagement y/o quejas, a menudo por enviar a listas frías o mezclar flujos (transaccional + marketing).

Solución: segmenta a destinatarios comprometidos, pausa segmentos fríos, separa marketing y transaccional en subdominios/IPs diferentes, añade List-Unsubscribe y reduce frecuencia.

2) Síntoma: Outlook/Hotmail coloca correo en la carpeta de correo no deseado de forma intermitente

Causa raíz: señales de infraestructura inconsistentes (rDNS/HELO descoordinado, TLS inestable, IPs variables), más patrones de contenido que parecen phishing.

Solución: estabiliza IPs de envío, arregla rDNS y EHLO, asegura STARTTLS consistente, alinea From/Reply-To/enlaces, y evita tipos de adjuntos riesgosos.

3) Síntoma: Pruebas internas muestran bandeja, usuarios reales ven spam

Causa raíz: las pruebas con cuentas semilla no son representativas; el comportamiento real del usuario impulsa la reputación. Además, los buzones de consumidores difieren por historial.

Solución: instrumenta tasa de quejas, rebotes y engagement por dominio; prueba con segmentos reales; enfócate en destinatarios que optaron recientemente.

4) Síntoma: DMARC falla solo para correo reenviado

Causa raíz: SPF se rompe en el reenvío; DKIM rompe cuando intermediarios modifican contenido; ARC ausente.

Solución: asegura que DKIM sobreviva (firma encabezados estables, evita reescrituras), considera ARC en reenviadores que controlas, y acepta que algunos reenvíos serán con pérdida.

5) Síntoma: DMARC pasa pero la marca aún parece sospechosa

Causa raíz: “superficie de marca” desalineada (Reply-To o enlaces en dominios no relacionados; tracking intenso; acortadores).

Solución: mantén From/Reply-To/enlaces dentro de una familia de dominios consistente; minimiza redirecciones; usa un subdominio de tracking estable y con historial.

6) Síntoma: Colocabilidad cayó tras cambiar de ESP

Causa raíz: nuevo flujo de IP/dominio sin reputación; subida de volumen demasiado rápida; lista de supresión antigua no migrada.

Solución: calienta gradualmente, migra supresiones, empieza con destinatarios comprometidos y evita cambiar dominios From al mismo tiempo que infraestructura.

7) Síntoma: La entregabilidad iba bien y colapsa tras añadir una nueva plantilla

Causa raíz: huella de contenido disparada (frases, patrones de enlaces o un dominio en URLs con mala reputación).

Solución: dif vuelve a comparar plantillas, elimina frases riesgosas, verifica dominios de URL, reduce desequilibrio imagen-texto y evita adjuntos si no son necesarios.

8) Síntoma: Mensajes se retrasan mucho y luego llegan a spam

Causa raíz: throttling y tormentas de reintentos crean patrones de ráfaga; backlog de cola cambia el timing y la percepción de reputación.

Solución: implementa limitación por dominio, respeta diferimientos, reduce concurrencia y suaviza envíos.

Listas de verificación / plan paso a paso

Plan paso a paso para “auth pasa pero spam” (haz esto en orden)

1. Elige un mensaje representativo que fue a spam y guarda los encabezados completos.
   • Decisión: si no puedes reproducir con encabezados reales, estás depurando sensaciones.
2. Confirma el alineamiento DMARC para ese mensaje (header.from vs DKIM d= y SPF mailfrom).
   • Decisión: si está desalineado, arregla la arquitectura de identidad antes de cualquier otra cosa.
3. Revisa higiene de infraestructura: PTR, FCrDNS, HELO, TLS.
   • Decisión: arregla problemas de higiene obvios; son victorias baratas y reducen sospecha base.
4. Busca throttling/diferimientos en logs (4.7.x es tu canario).
   • Decisión: si estás throttleado, reduce velocidad y segmenta; no ajustes reintentos para “ganar”.
5. Separa flujos: transaccional vs marketing vs notificaciones.
   • Decisión: si los mezclas hoy, planifica la separación. Es uno de los cambios con mayor ROI.
6. Audita higiene de listas: rebotes, quejas, segmentos antiguos, campañas de reactivación.
   • Decisión: si no puedes medir quejas/rebotes rápido, arregla la instrumentación antes de escalar envíos.
7. Reduce “superficies sospechosas”: dominios desalineados, tracking agresivo, acortadores de URL, adjuntos.
   • Decisión: simplifica. No estás tratando de ganar un premio de tecnología de marketing; estás tratando de ser entregado.
8. Calienta y estabiliza: volumen consistente, horario predecible, rampas graduales.
   • Decisión: trata el calentamiento como un despliegue de producción, no como una tarea de configuración puntual.

Checklist operacional (semanal)

• Revisar tendencias de rebotes y quejas por dominio receptor.
• Confirmar que las supresiones se aplican en horas, no días.
• Rotar claves DKIM en un cronograma controlado (y mantener selectores antiguos durante la transición).
• Validar que rDNS y TLS sigan correctos tras cambios de infraestructura.
• Revisar dominios más clicados y cadenas de redirección usadas en plantillas.
• Comprobar profundidad de cola y diferimientos; afinar límites de tasa, no solo concurrencia.

Checklist de arquitectura (una vez, luego mantener)

• Separar subdominios de envío por flujo (p. ej., notify., billing., marketing.).
• Alinear DKIM d= con el dominio From (o subdominio alineado organizacionalmente) cuando sea posible.
• Usar una IP dedicada (o al menos pool dedicado) para mensajes transaccionales críticos.
• Implementar List-Unsubscribe y darse-de-baja con un clic para correo masivo.
• Asegurar que el manejo de rebotes sea automatizado y fiable.

Preguntas frecuentes

1) Si SPF y DKIM pasan, ¿por qué un proveedor aún me manda a spam?

Porque la autenticación solo prueba identidad e integridad del mensaje. La colocación está impulsada por reputación, comportamiento, engagement, quejas y patrones de contenido.
Pasar SPF/DKIM solo significa que eres un remitente verificado—no necesariamente bienvenido.

2) ¿Es DMARC obligatorio para la colocación en bandeja?

No universalmente, pero en la práctica sí si te importa la entrega consistente y evitar suplantaciones. DMARC también te obliga a limpiar el alineamiento,
lo que elimina toda una categoría de señales de “esto parece forjado”.

3) ¿Cuál es la mejora más rápida si vamos a spam?

Deja de enviar a destinatarios no comprometidos. Segmenta agresivamente: aperturas/clics/respuestas recientes (lo que puedas medir de forma fiable),
inscripciones recientes y destinatarios que han interactuado contigo. La reputación se recupera más rápido cuando dejas de molestar a la gente.

4) ¿Debemos pasar a una IP dedicada?

Si envías suficiente volumen para justificar el calentamiento y mantenimiento, sí—especialmente para flujos transaccionales.
Si tu volumen es bajo o irregular, una IP dedicada puede ser peor porque no puedes construir reputación estable.

5) ¿Realmente importa el contenido si nuestra reputación es buena?

Sí. La reputación te abre la puerta; el contenido decide si te dejan quedarte. Estructura phishy, URLs riesgosas,
tracking intenso y formatos extraños pueden hundir correos de remitentes con buena reputación.

6) Nuestro correo se reenvía a través de sistemas de tickets y luego falla. ¿Qué hacemos?

El reenvío rompe SPF y las modificaciones rompen DKIM. Si controlas el reenviador, considera implementar ARC.
Si no, enfócate en la robustez de DKIM (firmar encabezados estables) y acepta que algunos reenvíos reducen la confianza.

7) Añadimos más claves/selectores DKIM. ¿Podría eso dañar la entregabilidad?

No por sí solo. Lo que daña es la firma inconsistente (a veces firmado, a veces no), registros DNS rotos o selectores rotados sin periodo de transición.
Mantén selectores antiguos activos mientras el correo en tránsito aún puede referenciarlos.

8) ¿Debemos usar “p=reject” en DMARC para mejorar entregabilidad?

La aplicación de DMARC puede reducir suplantaciones y abuso de marca, lo que indirectamente ayuda la reputación.
Pero no arreglará mala higiene de listas o altas quejas. No trates p=reject como un botón de entregabilidad.

9) ¿Por qué las pruebas con seeds dicen “bandeja” pero usuarios reales ven spam?

Las cuentas seed no se comportan como destinatarios reales y no tienen el mismo historial. Los filtros se personalizan.
El comportamiento real de tu audiencia (eliminaciones, quejas, falta de lectura) es el suero de la verdad.

10) ¿Son las listas negras DNS la razón de que estemos en spam?

A veces, pero no suele ser toda la historia para bandejas de consumo. Las listas negras explican mejor bloqueos duros que colocación sutil en spam.
Úsalas como señal para investigar compromiso o malos patrones de envío, no como la única métrica.

Conclusión: próximos pasos que realmente mueven la aguja

Si SPF y DKIM pasan pero aún vas a spam, deja de tratar la entregabilidad como un rompecabezas DNS.
Es un sistema de confianza. La confianza se gana mediante identidad consistente, infraestructura limpia y comportamiento de envío respetuoso.

Haz esto a continuación, en orden:

1. Pide un mensaje que fue a spam, guarda encabezados completos y confirma alineamiento DMARC y consistencia de dominio (From/Reply-To/enlaces).
2. Arregla higiene de infraestructura: rDNS, FCrDNS, HELO y STARTTLS con certificados válidos.
3. Revisa logs por throttling (4.7.x). Si lo ves, reduce velocidad y segmenta inmediatamente.
4. Separa flujos transaccional y marketing por subdominio y, idealmente, por IP/pool.
5. Implementa y prueba darse-de-baja con un clic; ajusta manejo de rebotes y suprime rebotes duros rápidamente.
6. Calienta nuevas IPs/dominios como desplegarías un nuevo clúster de bases de datos: gradualmente, con observabilidad y planes de rollback.

Las señales ocultas no son realmente ocultas. Simplemente no están en tu archivo de zona DNS.
Están en tus logs, en el comportamiento de tu audiencia y en la aburrida consistencia de tus sistemas.