Correo: “554 spam detected” — limpia la reputación sin perder semanas

Qué significa realmente “554 spam detected” (y qué no)

SMTP 554 es una falla permanente. En la práctica significa que el servidor receptor decidió que tu mensaje no merece ser aceptado—a menudo por filtrado de spam, fallos de autenticación, comprobaciones de políticas, reputación, patrones de contenido o anomalías de tráfico. “Spam detected” es una explicación amigable; la razón subyacente puede ser desde una firma DKIM desalineada hasta un host comprometido enviando a direcciones inválidas.

554 no es una causa raíz, es un veredicto

Piénsalo como “HTTP 403 Forbidden”. Te dice que la solicitud fue denegada, no si fue por tus credenciales, la reputación de tu IP o tu comportamiento lo que activó la denegación. Algunos proveedores incluyen más detalle en el código de estado mejorado (como 5.7.1) y en la cadena de texto. Muchos no. Tu trabajo es correlacionar su rechazo con tu evidencia: registros, DNS, cabeceras, tasas, rebotes e informes de usuarios.

Qué no es

• No “el buzón del destinatario está lleno” (eso suele ser 552 o un reintento 4xx).
• No un pico de cola transitorio que puedas “simplemente reintentar para siempre”. Reintentar 5xx como si fuera 4xx es como convertir un problema de entregabilidad en un DDoS autoinfligido contra tu propia reputación.
• No se arregla comprando un dominio nuevo cada vez. Puedes hacerlo, pero entonces tus clientes te verán como la compañía que cambia el identificador de llamada semanalmente.

Y una broma, porque vamos a estar aquí un rato: la entregabilidad es como hidratarse—si esperas a tener sed, ya la cagaste.

Guía de diagnóstico rápido (chequeos primero/segundo/tercero)

Esta es la secuencia de “tengo 30 minutos para detener la hemorragia”. No improvises. No empieces por “reescribir la plantilla del correo”. Comienza con evidencia que separe identidad, reputación y comportamiento.

Primero: identifica qué se está rechazando (alcance)

• ¿Es un proveedor (solo Gmail, solo Microsoft), o todos ellos?
• ¿Es un flujo (marketing masivo) o todo (restablecimientos transaccionales)?
• ¿Es una IP (nodo nuevo) o todo el pool de salida?
• ¿Es un dominio (dominio de marca nuevo) o todos los dominios emisores?

Decisión: si es un proveedor, enfócate en la política y señales de reputación de ese proveedor. Si es todo el mundo, asume que tu autenticación o host de envío está fallando.

Segundo: verifica la alineación de autenticación (SPF, DKIM, DMARC)

• Confirma que el dominio en From: esté alineado con la identidad de SPF o DKIM (DMARC). La desalineación es la forma más rápida de parecer un suplantador.
• Confirma que el DNS sea correcto, público y no esté desactualizado en configuraciones de horizonte dividido.

Decisión: si la alineación falla, corrige DNS y firmas antes de cualquier otra cosa. Calentar una identidad rota solo enseña a los filtros a desconfiar más rápido.

Tercero: revisa señales de reputación e higiene de listas

• Busca picos en volumen, picos en rebotes y patrones de receptores sospechosos (cuentas role, listas cosechadas, dominios aleatorios).
• Revisa si estás en listas de bloqueo y si tu IP tiene un reverse DNS limpio y un HELO/EHLO estable.

Decisión: si los rebotes son altos o apareces en una lista negra importante, pausa el tráfico masivo y aísla el correo transaccional en la ruta más limpia posible.

Cuarto: solo entonces mira el contenido

El contenido puede importar, especialmente para plantillas de phishing, acortadores de URL y MIME extraño. Pero el contenido suele no ser la primera ficha en caer. Trátalo como un multiplicador, no como la raíz.

Datos e historia interesantes: por qué los proveedores de buzón actúan así

• Dato 1: SMTP precede a los controles modernos contra abuso; el correo temprano asumía una red amigable. El anti-spam se pegó después como motores de política y sistemas de reputación.
• Dato 2: Las primeras listas de bloqueo basadas en DNS surgieron a finales de los 90 como reacción a los relays abiertos—sistemas que reenviaban correo para cualquiera.
• Dato 3: SPF ganó tracción a principios de los 2000 como forma de decir “estas IP pueden enviar por mi dominio”, pero nunca autentificó el contenido del mensaje—solo la ruta del sobre.
• Dato 4: La gran idea de DKIM fue la firma criptográfica a nivel de dominio para que los proveedores pudieran construir reputación sobre una identidad estable aun cuando cambian las IPs.
• Dato 5: DMARC (era 2012) obligó a la industria a preocuparse por la alineación—no solo “SPF pasó en algún sitio”, sino “SPF/DKIM pasó para el mismo dominio que ve el usuario”.
• Dato 6: Muchos proveedores tratan las quejas de spam como señales más fuertes que los rebotes. Un clic en “Reportar spam” de un usuario enfadado puede valer más que docenas de entregas.
• Dato 7: Gmail y Microsoft usan modelos de comportamiento masivos: patrones de envío, engagement, tasa de quejas y reputación a través de dominios e IP relacionadas.
• Dato 8: La entregabilidad en IPv6 sigue siendo desigual; algunos receptores son más estrictos con IPv6 porque el abuso es más fácil de escalar cuando el espacio de direcciones es prácticamente infinito.

Los verdaderos modos de fallo detrás del 554

1) La autenticación está técnicamente “presente” pero operacionalmente rota

Los incidentes más dolorosos son aquellos donde SPF existe, DKIM existe, DMARC existe… y aún fallas la alineación por una pequeña descoordinación: selector incorrecto, canonicalización errónea, rotación de clave caducada, ruta de reenvío, o un proveedor que envía en tu nombre sin estar autorizado.

2) La reputación se hundió por comportamiento de tráfico, no por contenido

A los proveedores no les gustan las sorpresas. Una IP nueva que pasa de 0 a 50k/día parece una botnet. Una IP estable que de repente empieza a golpear muchos destinatarios inválidos parece compra de listas. Un host que reintenta 5xx agresivamente parece que no respetas políticas o estás roto.

3) Reacciones y retroceso por rebotes mal configurados

Si tu sistema genera informes de no entrega (NDRs) a remitentes forjados, estás enviando spam sin querer. Los receptores lo notan. No están contentos.

4) Desajuste de identidad de infraestructura (PTR, HELO, postura TLS)

Los servidores de correo son juzgados como viajeros sospechosos: nombre, documentos y relato deben coincidir. Si tu PTR dice una cosa, tu HELO otra, y tu certificado parece hecho en un sótano, tendrás más escrutinio.

5) Compromiso: una máquina, una credencial, un script “útil”

Lo clásico: un servidor web es comprometido, el atacante envía correo vía localhost o credenciales SMTP robadas, y tu dominio se convierte en el newsletter menos divertido del mundo. Verás picos, destinos extraños y rechazos enfadados. Trata esto primero como un incidente de seguridad.

Segunda broma (y última, por las reglas): nada aumenta tu aura “spammy” como enviar 30.000 restablecimientos de contraseña que nadie pidió.

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

A continuación hay tareas prácticas que puedes ejecutar en un host MTA típico Linux (ejemplos con Postfix, pero la mayoría de conceptos aplican). Cada tarea incluye: comando, qué significa la salida y la decisión que tomas.

Task 1: Confirmar el texto exacto del rechazo y el código de estado mejorado

cr0x@server:~$ sudo grep -E "status=bounced|status=deferred" /var/log/mail.log | tail -n 20
Jan 03 10:14:12 mx1 postfix/smtp[21844]: 3A1B012345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0.0/0.4/0.7, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.26] said: 554 5.7.1 Message rejected as spam (in reply to end of DATA command))

Significado: Esto es un fallo duro (5.7.1 política/spam). El “end of DATA” te indica que aceptó el sobre SMTP pero rechazó después de evaluar contenido/política.

Decisión: Deja de reintentar para estos destinatarios; pivota a comprobaciones de autenticación/reputación y aísla los flujos.

Task 2: Contar rechazos por dominio de destino (encontrar alcance rápido)

cr0x@server:~$ sudo awk -F'to=<' '/status=bounced|status=deferred/ {print $2}' /var/log/mail.log | awk -F'>' '{print $1}' | awk -F'@' '{print $2}' | sort | uniq -c | sort -nr | head
  412 gmail.com
  133 outlook.com
   58 yahoo.com
   21 icloud.com
    9 example-corp.com

Significado: La concentración en grandes proveedores sugiere problemas de reputación/autenticación. Si fuera mayormente un dominio corporativo, podrías enfrentar una política de gateway específica.

Decisión: Prioriza la remediación para Gmail/Microsoft y valida señales globales de identidad.

Task 3: Revisar la tendencia de volumen saliente (¿es un pico?)

cr0x@server:~$ sudo grep "postfix/qmgr" /var/log/mail.log | awk '{print $1,$2,$3}' | uniq -c | tail -n 5
   98 Jan 03 10:10:01
  101 Jan 03 10:11:01
  544 Jan 03 10:12:01
  610 Jan 03 10:13:01
  588 Jan 03 10:14:01

Significado: Un salto repentino de ~100/min a ~600/min es un riesgo de reputación, especialmente en una IP nueva.

Decisión: Limita la tasa ahora; si debes entregar correo crítico, aísla ese tráfico en una vía más lenta con listas limpias.

Task 4: Verificar la IP pública desde la que realmente envías

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

Significado: Confirma la IP de NAT/egreso. Muchos equipos depuran la dirección equivocada porque el egress cloud difiere de la IP de la instancia.

Decisión: Usa esta IP para PTR, comprobaciones de listas de bloqueo y herramientas de postmaster de proveedores.

Task 5: Validar reverse DNS (PTR) que coincida con tu identidad de envío

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

Significado: Tienes PTR. Bien. Ahora asegúrate de que el DNS directo de ese nombre apunte de vuelta a la misma IP (tarea siguiente).

Decisión: Si PTR falta o es genérico, arréglalo con tu proveedor. No tener PTR no siempre es fatal, pero es un multiplicador frecuente de “spammy”.

Task 6: Confirmar reverse DNS con forward-confirmed (FCrDNS)

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

Significado: PTR y registro A coinciden. Esta consistencia reduce la sospecha y evita algunas heurísticas del receptor.

Decisión: Si no coinciden, alinéalos. Evita tener PTR a un nombre y HELO a otro.

Task 7: Revisar tu nombre HELO/EHLO (debe ser real y resoluble)

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

Significado: Tu nombre HELO es estable y coincide con la identidad DNS. Si HELO es “localhost” o un nombre interno aleatorio, algunos receptores te penalizarán.

Decisión: Configura myhostname al nombre PTR y asegúrate de que resuelva.

Task 8: Confirmar el registro SPF para el dominio visible en From

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

Significado: SPF permite explícitamente tu IP de envío y tu proveedor. El -all es estricto (bueno cuando es correcto).

Decisión: Si tu IP no está autorizada, añádela (o corrige el ruteo para que envíes desde infraestructura autorizada). No dejes SPF como ~all por miedo—sé correcto.

Task 9: Comprobar que existe la clave pública DKIM (selector)

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

Significado: El selector DKIM s1 está publicado. Si rotaste claves y olvidaste el DNS, obtendrás fallos DKIM silenciosos.

Decisión: Si falta, publica la clave correcta y asegúrate de que tu MTA firme con ese selector.

Task 10: Inspeccionar una cabecera de mensaje entregado para resultados SPF/DKIM/DMARC

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature" -n sample-headers.txt | head -n 20
12: Authentication-Results: mx.google.com;
13:        dkim=pass header.i=@example.com header.s=s1 header.b=abc123;
14:        spf=pass (google.com: domain of bounce@example.com designates 203.0.113.45 as permitted sender) smtp.mailfrom=bounce@example.com;
15:        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
28: DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed; ...

Significado: Este es el estándar de oro: SPF pass, DKIM pass, DMARC pass. Si ves dmarc=fail mientras SPF/DKIM pasan, la alineación está rota (común con terceros que usan su propio dominio de rebote).

Decisión: Si DMARC falla, corrige la alineación: asegúrate de que DKIM d= coincida con el dominio From, o que el MAIL FROM de SPF esté alineado.

Task 11: Comprobar la política DMARC y direcciones de reporte

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=s

Significado: Alineación estricta (adkim=s, aspf=s) es excelente si eres consistente. Es doloroso si tienes sistemas heredados enviando desde subdominios o proveedores no alineados.

Decisión: Si fallas por alineación estricta, o arregla los emisores para alinear o relaja a r temporalmente mientras migras. No lo dejes relajado para siempre.

Task 12: Verificar la postura TLS presentada por tu servidor SMTP

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mx1.mail.example.com
issuer=CN = R3, O = Let's Encrypt, C = US
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar 10 23:59:59 2026 GMT

Significado: Un certificado válido con un CN sensato y fechas coherentes. Algunos receptores puntúan la calidad TLS. Más importante: TLS roto puede causar que la ruta de entrega se degrade o falle de formas extrañas.

Decisión: Si está caducado o desajustado, arréglalo de inmediato—esto es higiene de reputación fácil.

Task 13: Detectar backscatter (¿estás enviando rebotes a remitentes falsificados?)

cr0x@server:~$ sudo grep -E "postfix/bounce|postfix/local" /var/log/mail.log | grep -i "Undelivered Mail Returned to Sender" | tail -n 10
Jan 03 10:08:44 mx1 postfix/bounce[21201]: 9FEEA12345: sender non-delivery notification: 0ABCD12345
Jan 03 10:08:44 mx1 postfix/local[21202]: 0ABCD12345: to=<random.person@foreign-domain.tld>, relay=local, delay=0.1, dsn=2.0.0, status=sent (delivered to mailbox)

Significado: Estás generando NDRs. La cuestión clave es: ¿estos NDRs van a remitentes legítimos o a direcciones forjadas? Si tu sistema aceptó correo que no debía (relay abierto, sin validación de destinatario), provocarás backscatter.

Decisión: Si hay backscatter, endurece la política SMTP entrante y la validación de destinatarios. El backscatter puede desencadenar rechazos 554 en otros lados porque ahora eres “ese servidor”.

Task 14: Comprobar si tu servidor es un relay abierto (la forma más rápida de arruinarlo todo)

cr0x@server:~$ sudo postconf -n | grep -E 'smtpd_recipient_restrictions|mynetworks|smtpd_relay_restrictions'
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain

Significado: reject_unauth_destination está presente: bien. Si falta, podrías estar reenviando correo para extraños.

Decisión: Si las restricciones de relay están mal, arréglalas inmediatamente y rota cualquier credencial expuesta. Asume compromiso hasta probar lo contrario.

Task 15: Ver quiénes son las cuentas/aplicaciones que más envían (quién genera el correo)

cr0x@server:~$ sudo grep "sasl_username=" /var/log/mail.log | awk -F"sasl_username=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  902 app-prod@example.com
  117 crm-sync@example.com
   44 legacy-batch@example.com

Significado: Un principal es responsable de la mayor parte del tráfico. Si ese principal está comprometido o mal configurado, has encontrado el fuego.

Decisión: Limita la tasa o suspende al mayor ofensor; exige rotación de credenciales e investiga sus patrones de envío.

Task 16: Limitar la concurrencia de salida de Postfix (estabilizar comportamiento)

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 2s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf -n | grep -E "default_destination_rate_delay|smtp_destination_concurrency_limit"
default_destination_rate_delay = 2s
smtp_destination_concurrency_limit = 5

Significado: Has reducido la ráfaga. Los proveedores suelen tratar el tráfico más suave como menos sospechoso, y reduces daños colaterales mientras reparas la reputación.

Decisión: Mantén los límites mientras remdias. Luego, súbelos con cautela según tasas de aceptación y señales de queja.

Tres micro-historias corporativas (cómo se queman los equipos)

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

Una empresa SaaS mediana movió el correo saliente de un proveedor gestionado a “nuestro propio Postfix” para ahorrar costes. La suposición era simple y sincera: “El correo es solo SMTP; si sale de nuestra caja, ya está”. Actualizaron DNS para SPF. Incluso publicaron una clave DKIM. Entonces empezaron los 554s—primero en restablecimientos de contraseña, luego facturas, luego onboarding.

El equipo on-call persiguió el contenido. Quitaron enlaces. Reescribieron asuntos. Hicieron los correos más feos, que ya es un logro. Las reacciones continuaron. El problema real vivía en la plomería invisible: enviaban con From: example.com, pero su dominio de rebote (envelope MAIL FROM) era un subdominio de un proveedor usado por un sistema legado. SPF pasaba para el dominio de rebote, DKIM pasaba para un dominio diferente, y DMARC fallaba la alineación. Para los grandes proveedores, esto parecía suplantación de marca con disfraz.

Cuando sacaron cabeceras de algunos mensajes aceptados y las compararon con el flujo rechazado, el patrón surgió: la plataforma de marketing estaba alineada; el mailer de la app no. Arreglaron el remitente del sobre para alinear con el dominio From, resignaron DKIM con el d= correcto y actualizaron DMARC a estricto solo después de verificar todos los emisores.

El golpe reputacional no desapareció instantáneamente, pero la hemorragia paró en un día. La lección quedó: la entregabilidad no es “el correo sale del servidor”. Es “el correo llega con una identidad coherente”.

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

Una empresa retail tenía buena reputación y una IP saliente estable y aburrida. Entonces llegó el Black Friday y alguien hizo la optimización que sonaba sensata: aumentar concurrencia y quitar delays para “vaciar la cola más rápido”. El MTA pasó de un flujo constante a una manguera de incendios. Las campañas terminaron antes. Todos celebraron.

En horas, dominios Microsoft empezaron a responder con variantes 554 y 5.7.1. Gmail comenzó a diferir y luego a rechazar. Los dashboards internos mostraban “enviado con éxito” porque la app solo seguía la entrega al MTA. Los clientes no veían recibos. Soporte se encendió. Finanzas lo notó antes que ingeniería, lo cual siempre es una manera divertida de empezar el día.

El daño real no fue solo el volumen—fue la forma. Los proveedores vieron un cambio repentino en comportamiento: mismo emisor, misma familia de contenido, pero tasa y concurrencia radicalmente distintas. Sus modelos lo trataron como un emisor comprometido intentando disparar antes de ser apagado. La compañía había simulado accidentalmente a un atacante.

Revertir la concurrencia ayudó, pero la recuperación de reputación tomó más tiempo porque el estallido de envíos disparó picos de quejas (“¿por qué me llegan tantos correos a la vez?”). La solución fue poco glamorosa: restablecer límites, segmentar tráfico por importancia y programar oleadas de marketing para comportarse como un sistema maduro, no un becario en pánico con megáfono.

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

Una compañía de pagos tenía dos rutas salientes: una para marketing y otra para eventos transaccionales. Parecía redundante. Costaba un poco más. También evitó toda una categoría de fallos.

Una tarde, una integración CRM importó una lista sucia. Los rebotes se dispararon, y en horas la IP de marketing empezó a ver bloqueos. El flujo transaccional—restablecimientos, recibos, notificaciones de contracargo—siguió entregando porque usaba otra IP, otro remitente de sobre y una lista de permitidos más estricta de sistemas internos que podían enviar correo.

Como eran disciplinados, además tenían informes DMARC llegando a un buzón monitorizado y un pequeño script que resumía tasas de pass/fail. El equipo detectó un aumento de correo desalineado temprano y pausó la integración antes de que los bucles de retroalimentación del proveedor se enfadasen. Limpiaron la lista, corrigieron la ruta de envío de la integración y reanudaron con un programa de warmup.

Nadie escribió un postmortem viral. Ese es el punto. La práctica fue aburrida, correcta y silenciosamente rentable.

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

1) Síntoma: 554 solo en Gmail, todo lo demás mayormente OK

Causa raíz: Gmail es particularmente sensible a la reputación de dominio, engagement y alineación. A menudo es un problema de warmup de IP/dominio nuevo o de mala higiene de listas.

Solución: Reduce la velocidad de envíos, segmenta a los destinatarios más comprometidos primero, verifica alineación DMARC, elimina direcciones inactivas/no verificadas y mantiene el tráfico transaccional limpio y estable.

2) Síntoma: 554 comienza justo después de mover a un servidor/IP nuevo

Causa raíz: Reputación fría de IP. Los proveedores no tienen historial positivo y tu tráfico parece masivo o una máquina comprometida.

Solución: Haz warmup: inicia con bajo volumen, destinatarios de alta calidad, aumento gradual, identidad estable (PTR/HELO/TLS) y evita picos bruscos.

3) Síntoma: SPF pasa pero DMARC falla en cabeceras

Causa raíz: SPF pass es para el dominio del remitente de sobre, no alineado con el dominio From; o DKIM firma con un dominio distinto.

Solución: Alinea identidades: haz que DKIM d= coincida con el dominio From, o alinea el dominio MAIL FROM con el From y asegúrate de que SPF autorice la IP.

4) Síntoma: dominios Microsoft rechazan con 554/5.7.1 tras una campaña de marketing

Causa raíz: Tasa de quejas y tráfico en ráfaga. Microsoft es sensible a cambios repentinos y comportamiento “tipo campaña” desde infraestructura que normalmente envía transaccional.

Solución: Separa flujos. No envíes marketing desde infraestructura transaccional. Implementa throttling por dominio y monitoriza señales de queja/rebote.

5) Síntoma: muchos rebotes a destinatarios inexistentes y luego bloqueos por todas partes

Causa raíz: Mala higiene de listas o un emisor comprometido enumerando direcciones. Altas tasas de destinatarios inválidos son una fuerte señal de spam.

Solución: Deja de enviar a desconocidos. Suprime los hard bounces inmediatamente. Requiere doble opt-in o direcciones verificadas para correo masivo. Investiga compromiso.

6) Síntoma: rechazos dicen “HELO/EHLO” o problemas de “hostname”

Causa raíz: Nombre HELO no resoluble, PTR faltante o desajuste entre HELO y reverse DNS.

Solución: Configura myhostname a un nombre DNS con registro A que coincida con la IP de envío y asegura que PTR apunte de vuelta. Manténlo estable.

7) Síntoma: de repente eres “spammer” pero no cambiaste los correos

Causa raíz: Alguien cambió el comportamiento: una integración nueva, un bucle de reintento, una re-reproducción de cola o una credencial filtrada.

Solución: Identifica los mayores remitentes, congela cuentas sospechosas, rota credenciales y revisa logs de correo para patrones (destinos, tasas, errores).

8) Síntoma: “554 spam detected” después de activar un nuevo rastreo o acortador de enlaces

Causa raíz: Reputación de URLs. Algunos dominios de redirección son muy abusados y tu contenido hereda esa mancha.

Solución: Usa dominios de seguimiento de marca con DNS/autenticación sólida; evita acortadores dudosos; asegura que los dominios de destino tengan buena reputación y TLS.

Listas de verificación / plan paso a paso (volver a la bandeja de entrada)

Fase 0: Detener la hemorragia (primeras 1–2 horas)

1. Separa correo crítico vs no crítico. Pausa marketing/bulk. Mantén solo lo transaccional si está limpio. Si no puedes separar, pausa todo y usa temporalmente un proveedor confiable alterno.
2. Limita la tasa de salida. Tu objetivo es “predecible, baja queja” no “rápido”. Implementa delays por destino y límites de concurrencia.
3. Deja de reintentar hard bounces. Trata 5xx como terminal. Reintentar 5xx te hace parecer una máquina que no aprende.
4. Confirma que las señales de identidad sean coherentes. PTR, HELO, certificado TLS, SPF, DKIM, alineación DMARC. Arregla rupturas obvias inmediatamente.

Fase 1: Triage de evidencia (mismo día)

1. Extrae una muestra de logs rechazados y agrupa por proveedor y cadena de rechazo.
2. Saca cabeceras de mensajes entregados a cada proveedor mayor (cuentas seed ayudan). Compara resultados de autenticación.
3. Calcula tasa de rebote y lista de hard bounces. Si estás por encima de un bajo porcentaje de un dígito en masivo, asume problema de lista. Para transaccional, los hard bounces deben ser raros.
4. Identifica principales remitentes y rutas de código. Busca un ofensor: un job fuera de control, un loop, un token comprometido o un proveedor que rutea mal el correo.

Fase 2: Reparar identidad (1–3 días, a menudo más rápido)

1. Corrige SPF para que sea correcto y mínimo. Autoriza solo emisores reales. Mantén las búsquedas DNS bajo límites podando includes anidados.
2. Estandariza el firmado DKIM. Uno o dos selectores, rota claves según calendario, asegura que todos los sistemas firmen con d= alineado.
3. Usa DMARC con intención. Si no lo tienes, empieza con p=none para reportes y pasa a quarantine/reject tras comprobar alineación. Si ya tienes reject, no lo relajes por pánico salvo que sea necesario.
4. Estabiliza la identidad de infraestructura. rDNS, HELO, IPs de salida consistentes y TLS sensato.

Fase 3: Reparar reputación (días a semanas, pero puedes acortarlo)

1. Haz warmup en serio. Comienza con destinatarios comprometidos. Aumenta volumen gradualmente. Evita picos y campañas repentinas.
2. Limpia listas con agresividad. Suprime hard bounces de inmediato. Quita direcciones dormidas de envíos masivos. Prefiere opt-in confirmado para nuevas altas.
3. Separa flujos permanentemente. El correo transaccional no debe compartir IP/dominios con blasts de marketing. Si debes compartir dominio, al menos segmenta por subdominio y claves de firma.
4. Instrumenta la entregabilidad como producción. Sigue tasa de aceptación, distribuciones de razones de rebote, resultados por proveedor y delays en colas. “Lo enviamos” no es una métrica de éxito.

Fase 4: Prevenir recurrencias (continuo)

1. Gestión de cambios para email. Concurrencia, políticas de reintento, nuevas integraciones, cambios de plantilla—estos son cambios de producción. Revísalos.
2. Monitorización de abuso y compromiso. Alerta por anomalías de volumen, nuevos dominios destino y picos de destinatarios inválidos.
3. Runbook de rotación de claves. La rotación DKIM debe ser rutinaria, no un generador de outages anual.

Una cita de fiabilidad que aplica

La esperanza no es una estrategia — idea parafraseada frecuente en círculos de ingeniería y operaciones. Aplícala al correo también.

FAQ

1) ¿“554 spam detected” siempre trata sobre contenido?

No. El contenido puede activar filtros, pero la mayoría de eventos “554 súbitos” son identidad o comportamiento: alineación fallida, IP fría, picos de rebotes o tráfico en ráfagas.

2) ¿Debo cambiar a una IP nueva inmediatamente?

Solo si puedes arreglar también el comportamiento subyacente. Una IP nueva con la misma lista mala, la misma desalineación o el mismo patrón de ráfaga se quemará de nuevo—a menudo más rápido.

3) ¿Puedo “calentar” enviando a todas las direcciones que tengo?

Eso no es warmup; es quemar reputación. El warmup funciona cuando los destinatarios son reales, comprometidos y esperan tu correo. Comienza con la mejor cohorte.

4) ¿Cuál es la diferencia entre SPF pass y DMARC pass?

SPF pass significa que la IP de envío está autorizada para el dominio del remitente de sobre. DMARC pass significa que SPF o DKIM pasaron y se alinean con el dominio visible en From.

5) ¿Por qué veo “in reply to end of DATA command” en el rechazo?

Significa que el receptor esperó hasta ver cabeceras/cuerpo (y a veces ejecutó comprobaciones de contenido + reputación) antes de rechazar. Eso te apunta a política/reputación/contenido, no a la conectividad SMTP básica.

6) Si tengo DMARC p=reject, ¿causará rechazos 554?

Pueda que sí—si tus mensajes fallan la alineación. DMARC reject no causa rechazo por sí mismo; lo que causa rechazo es fallar DMARC. La solución es alinear emisores, no borrar DMARC.

7) ¿Cómo protejo el correo transaccional cuando marketing está bloqueado?

Separa infraestructura e identidades. Como mínimo: IPs separadas y credenciales de envío separadas. Prefiere subdominios y selectores DKIM distintos. Mantén el volumen transaccional estable y limpio.

8) ¿Por qué algunos destinatarios reciben correo mientras otros rebotan con 554?

Los proveedores personalizan filtrado. El historial de engagement, reglas a nivel de usuario y políticas locales varían. Por eso necesitas telemetría a nivel de dominio y pruebas seed, no anécdotas.

9) ¿Debo bajar el tamaño de la clave DKIM para “mejorar entregabilidad”?

No. Usa firmado moderno y seguro (típicamente RSA de 2048 bits donde se soporte). La entregabilidad no mejora debilitando la criptografía; mejora siendo consistente y digno de confianza.

10) ¿Cuánto tarda recuperar la reputación?

Si el problema es autenticación rota u otro fallo obvio, puedes mejorar la aceptación el mismo día. Si quemaste reputación con listas malas o picos de volumen, espera días a semanas, según cuán disciplinado seas.

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

Si estás viendo “554 spam detected”, tu ganancia más rápida no es una plantilla nueva ni un asunto nuevo. Es identidad coherente más comportamiento predecible:

1. Usa la guía de diagnóstico rápido: alcance → alineación → reputación/comportamiento → contenido.
2. Arregla la alineación SPF/DKIM/DMARC para que el dominio From esté autenticado tal como los receptores esperan.
3. Estabiliza la identidad de infraestructura: PTR, HELO, TLS, IPs de salida consistentes.
4. Limita la tasa y segmenta el tráfico. Pausa el masivo mientras proteges lo transaccional.
5. Limpia las listas como si tu trabajo dependiera de ello—porque depende.

Haz eso y dejarás de perder semanas discutiendo con filtros de correo. Aún tendrás que recuperar la confianza, pero lo harás deliberadamente—no cavando el pozo más profundo por accidente.