Email “550 rejected”: qué significa realmente y cómo desbloquearlo

Qué significa realmente “550 rejected” (y qué no)

Los códigos de estado SMTP son la versión del correo de «la computadora dice que no». 550 es un fallo
permanente en la capa SMTP: el servidor receptor no aceptará el mensaje tal como fue enviado. «Permanente» significa que el receptor te dice
«no reintentes como un robot; arregla algo».

Pero aquí está la trampa: 550 es un cubo. El número por sí solo casi no sirve. La parte importante es el
código de estado mejorado (como 5.7.1) y, aún más, el texto que viene después.
Los receptores usan 550 para todo, desde «usuario inexistente» hasta «tu IP huele a spam» o «tu HELO no tiene sentido».

550 vs 450/451: por qué «permanente» importa operativamente

Si ves 450 o 451, eso suele ser un fallo temporal: greylisting, limitación de tasa,
comprobaciones de política transitorias o que el receptor tenga un mal día. Tu MTA debería reintentar.
Con 550, reintentar normalmente te hace quedar peor: sigues martillando a un receptor que ya dijo «no».

Eso no significa «nunca reintentes un 550». Algunos receptores envían 550 incorrectamente para bloqueos de política temporales.
Pero trata el 550 como un incidente: pausa, inspecciona y aplica un arreglo dirigido.

Qué no es 550

• No es necesariamente un problema con tu proveedor de correo. A menudo es tu dominio, tu IP, tu autenticación, tu contenido o tu comportamiento de envío.
• No es prueba de que estás «listas negras en todos lados». Un receptor rechazándote puede arruinar tu día, pero rara vez es universal.
• No siempre está relacionado con spam. Puede ser usuario desconocido, correo mal enrutado, DNS roto o un relay mal configurado.

Una regla operativa: no dejes que el equipo de ventas defina la severidad del incidente por sensaciones.
La severidad viene del alcance: qué dominios están rechazando, qué flujos de correo están afectados (transaccional vs marketing),
y si estás perdiendo correos críticos para el negocio.

Datos interesantes y un poco de historia (porque el correo es antiguo)

• SMTP es anterior a la web. La especificación SMTP central se publicó en 1982. La mayoría de tus problemas «modernos» son añadidos posteriores.
• Los códigos de estado mejorados (como 5.7.1) se introdujeron más adelante para hacer los fallos menos ambiguos. Muchos sistemas todavía los tratan como opcionales.
• SPF nació como respuesta a las direcciones remitentes falsificadas a principios de los 2000. Ayuda, pero no es un sistema de identidad; es una pista de «quién puede enviar por este dominio».
• DKIM se hizo habitual para proteger la integridad del mensaje y proporcionar un dominio de firma estable incluso cuando se reenvía el correo.
• DMARC es el pegamento de política y reporte que dice a los receptores qué hacer cuando SPF/DKIM fallan y te da visibilidad mediante informes.
• El greylisting fue un truco contra el spam que se basaba en que los spammers no reintentaban. Los MTAs legítimos reintentan; muchos bots de spam no lo hacían. Algunos aún lo usan.
• Las RBLs (listas negras en tiempo real) surgieron porque SMTP no tiene un sistema de reputación integrado. Internet delegó la «confianza» a listas y feedback loops.
• IPv6 complicó la reputación al principio porque el espacio de direcciones es enorme; bloquear de forma ingenua puede ser inútil o devastador.
• Los buzones «postmaster» y «abuse» se convirtieron en estándares de facto porque los operadores necesitaban un humano al que avisar cuando un servidor se comportaba mal.

El correo es el sistema distribuido más antiguo y crítico que la mayoría de las empresas aún ejecutan. También es aquel que la gente asume que «simplemente debería funcionar»,
lo cual es adorable, como asumir que una impresora debería simplemente funcionar.

Broma #1: El correo es el único sistema donde un protocolo de 40 años todavía mueve la economía global, y nos sorprende que tenga sentimientos sobre DNS.

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

Primero: clasifica el rechazo en 60 segundos

1. Recoge la transcripción SMTP exacta o el texto del rebote. «550 rejected» no es suficiente. Necesitas el código mejorado y el texto de política.
2. Identifica la familia del receptor. Consumidor (Gmail, Microsoft) vs gateway corporativo (Proofpoint, Mimecast) vs Postfix/Exim personalizado. Sus modos de fallo difieren.
3. Comprueba el alcance: ¿es un único destinatario? ¿un dominio? ¿muchos dominios? ¿solo nuevos destinatarios? ¿solo adjuntos?

Segundo: decide si es identidad, reputación o enrutamiento

• Identidad/autenticación: fallo SPF, fallo DKIM, fallo DMARC, problemas de alineamiento, rDNS/PTR ausente, HELO/EHLO incorrecto, requisitos TLS.
• Reputación/política: reputación de IP o dominio, listado en RBL, tasa de quejas, limitación de tasa, filtrado de contenido, reputación de URL.
• Enrutamiento/destinatario: usuario desconocido, relay denegado, remitente no permitido, política del destinatario (bloqueo de remitentes externos), MX equivocado, puerto incorrecto, DNS roto.

Tercero: elige el camino más corto para desbloquear

1. Si es enrutamiento/destinatario: corrige direcciones, MX, relay o la política del destinatario; normalmente puedes resolverlo rápido.
2. Si es autenticación: corrige SPF/DKIM/rDNS/HELO y reintenta con una prueba controlada.
3. Si es reputación: detén la hemorragia (limita tasa, bloquea cuentas comprometidas, pausas marketing), luego trabaja en el deslistado y en el calentamiento.

La clave: no empieces cambiándolo todo. Perderás la capacidad de atribuir el arreglo y malgastarás tiempo discutiendo contigo mismo después.
Haz un cambio dirigido, prueba y luego continúa.

Descifra el rebote: las palabras que importan

Códigos de estado mejorados comunes que verás con 550

• 550 5.1.1: dirección del destinatario rechazada (a menudo «usuario desconocido»). Puede ser un error tipográfico o un buzón dado de baja.
• 550 5.1.10 (varía por proveedor): destinatario no encontrado o inválido.
• 550 5.2.0 / 5.2.2: buzón lleno o límite de almacenamiento/política (a veces mal usado).
• 550 5.7.1: entrega no autorizada / mensaje rechazado por política. Este es el más común: autenticación, reputación, contenido o política administrativa.
• 550 5.7.26: autenticación requerida o rechazo relacionado con DMARC (común en grandes proveedores).
• 550 5.7.0: estado genérico de seguridad/política.

Patrones de texto de política y lo que suelen implicar

• “SPF fail” / “SPF softfail”: tu IP de envío no está autorizada en SPF, o tu SPF está malformado/demasiado largo.
• “DKIM signature invalid”: la firma se rompió (a menudo reescritura de encabezados, selector equivocado o desajuste de clave).
• “DMARC policy reject”: SPF/DKIM fallaron el alineamiento según la política DMARC; el receptor está respetando tu postura publicada (o la suya).
• “blocked using …”: a menudo RBL o reputación interna. La lista nombrada importa.
• “reverse DNS required”: PTR ausente o desajustado; algunos gateways son estrictos.
• “HELO/EHLO rejected”: tu MTA se presenta con un nombre de host falso o un literal de IP que al receptor no le gusta.
• “Relay access denied”: intentas usar un servidor como relay abierto, o tu cliente no está autenticado/permitido.
• “Message content rejected”: reputación de URL, tipo de adjunto o heurísticas de contenido (incluyendo «demasiados enlaces» o «parece phishing»).

Trata el texto del rebote como líneas de log: ruidoso pero raramente aleatorio. Tu mejor movimiento es capturar varios rebotes en una ventana corta
y buscar redacción consistente. Si cada rechazo tiene la misma cláusula, esa cláusula es tu candidata a causa raíz.

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

Estas son las comprobaciones que hago en la primera hora. Cada tarea incluye: un comando, qué significa la salida y qué decisión tomar.
Ejecútalas desde un host con acceso de red a DNS e Internet (o al menos a tu resolutor).

Task 1: Extract the exact SMTP rejection from your logs (Postfix)

cr0x@server:~$ sudo grep -R "status=bounced" /var/log/mail.log | tail -n 3
Jan  3 01:10:12 mx1 postfix/smtp[22103]: 9C2D12A03F: to=<user@example.net>, relay=mx.example.net[203.0.113.10]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=5.7.1, status=bounced (host mx.example.net[203.0.113.10] said: 550 5.7.1 Message rejected due to policy restrictions (in reply to end of DATA command))

Significado: Tienes el código mejorado 5.7.1 y un rechazo de política después de DATA. Eso suele ser autenticación, reputación o contenido.

Decisión: No persigas «usuario desconocido». Ve directo a comprobaciones de auth/reputación/contenido.

Task 2: Verify the sending IP you actually used

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5      2140 Fri Jan  3 01:11:44  alerts@corp.example
                                         user@example.net

-- 1 Kbytes in 1 Request.

Significado: Existe una cola; necesitas ver qué transporte y qué IP de origen se usan para salida.

Decisión: Confirma NAT de salida o comportamiento multihomed; la IP de egreso «incorrecta» puede romper SPF y suponer problemas de reputación.

Task 3: Check your outbound public IP from the mail host

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

Significado: Esta es la IP que muchos receptores puntuarán por reputación y los mecanismos «ip4» de SPF.

Decisión: Usa esta IP al validar SPF, rDNS y estado en RBL.

Task 4: Look up the recipient domain MX records (routing sanity)

cr0x@server:~$ dig +short MX example.net
10 mx1.example.net.
20 mx2.example.net.

Significado: Sabes adónde entregas. Si esto está vacío o raro, puede que estés enviando al lugar equivocado.

Decisión: Si MX falta o apunta a hosts inesperados, arregla DNS/expectativas del destinatario antes de tocar auth.

Task 5: Open an SMTP session to see the rejection stage

cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP
EHLO mx.corp.example
250-mx1.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
MAIL FROM:<alerts@corp.example>
250 2.1.0 Ok
RCPT TO:<user@example.net>
550 5.7.1 Recipient address rejected: Access denied

Significado: Rechazado en RCPT TO: a menudo política de destinatario, listas de bloqueo, reputación del remitente o «remitente externo no permitido».

Decisión: Si RCPT falla, el contenido es menos probable. Enfócate en política, reputación y reglas de allow/block del destinatario.

Task 6: Check SPF for the envelope-from domain

cr0x@server:~$ dig +short TXT corp.example | grep -i spf
"v=spf1 ip4:198.51.100.25 include:spf.mailvendor.example -all"

Significado: SPF existe y explícitamente permite tu IP de salida.

Decisión: Si tu IP real de envío no coincide, actualiza SPF o arregla el enrutamiento de salida. Si SPF falta, añádelo ahora.

Task 7: Validate SPF evaluation with a local tool (quick-and-dirty)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null
cr0x@server:~$ spfquery -ip 198.51.100.25 -sender alerts@corp.example -helo mx.corp.example
pass

Significado: SPF pasa para esta combinación sender/IP/HELO.

Decisión: Si esto devuelve fail/softfail/permerror, trata SPF como sospechoso principal y arréglalo antes que nada.

Task 8: Check DKIM DNS selector record exists

cr0x@server:~$ dig +short TXT selector1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt0..."

Significado: La clave pública DKIM está publicada para selector1.

Decisión: Si falta, obtendrás DKIM=none o fail; publica el registro o corrige el selector en tu MTA/ESP.

Task 9: Confirm your outbound message is actually DKIM-signed

cr0x@server:~$ sudo apt-get -y install swaks >/dev/null
cr0x@server:~$ swaks --to user@example.net --from alerts@corp.example --server mx1.example.net --data "Subject: test

hello" --quit-after DATA
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<= 220 mx1.example.net ESMTP
=> EHLO mx.corp.example
<= 250-mx1.example.net
<= 250-STARTTLS
=> QUIT

Significado: Esta prueba no incluyó tu ruta de firma de producción; swaks es útil para sondear, pero la firma DKIM depende de tu canal de envío.

Decisión: Envía un mensaje real a través de tu MTA e inspecciona encabezados (tarea siguiente). No «pruebes» DKIM con un test que lo omite.

Task 10: Inspect a sent message’s Authentication-Results and DKIM headers

cr0x@server:~$ sudo grep -R "DKIM-Signature" /var/log/mail.log | tail -n 2
Jan  3 01:14:02 mx1 opendkim[1402]: 9C2D12A03F: DKIM-Signature field added (s=selector1, d=corp.example)

Significado: Tu MTA está añadiendo firmas DKIM para d=corp.example.

Decisión: Si ves «no signature data» o nada, arregla la integración opendkim/opendmarc o tu tabla de firma.

Task 11: Check DMARC policy and alignment expectations

cr0x@server:~$ dig +short TXT _dmarc.corp.example
"v=DMARC1; p=reject; rua=mailto:dmarc@corp.example; adkim=s; aspf=s"

Significado: DMARC es estricto: tanto DKIM como SPF tienen alineamiento «s» (estricto). Eso puede romper flujos legítimos como reenvíos, forwarding y remitentes terceros.

Decisión: Si estás bloqueado y configuraste recientemente p=reject con alineamiento estricto, confirma que todos los flujos de correo están alineados; relaja el alineamiento solo si comprendes el trade-off.

Task 12: Verify reverse DNS (PTR) for your outbound IP

cr0x@server:~$ dig +short -x 198.51.100.25
mx.corp.example.

Significado: PTR existe y apunta a mx.corp.example.

Decisión: Si no hay PTR, o el PTR apunta a algo genérico, arréglalo con tu ISP/proveedor cloud. Muchos gateways fallan duro sin rDNS.

Task 13: Confirm forward DNS matches your PTR (not required everywhere, but helps)

cr0x@server:~$ dig +short A mx.corp.example
198.51.100.25

Significado: RDNS confirmado hacia adelante (FCrDNS) es consistente.

Decisión: Si el registro A no coincide con la IP del PTR, espera desconfianza. Arregla nombres y mapeo IP donde sea posible.

Task 14: Check your HELO/EHLO name matches something real

cr0x@server:~$ postconf -n | grep -E "myhostname|smtp_helo_name"
myhostname = mx.corp.example
smtp_helo_name = mx.corp.example

Significado: Te identificas como mx.corp.example.

Decisión: Si HELO es «localhost» o un hostname interno, arréglalo. Algunos receptores rechazan de plano; otros te puntúan negativamente.

Task 15: Check if your IP is on common RBLs (DNS-based check)

cr0x@server:~$ for rbl in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
ip=198.51.100.25; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); \
ans=$(dig +short ${rev}.${rbl} A); \
echo "$rbl: ${ans:-not-listed}"; \
done
zen.spamhaus.org: not-listed
bl.spamcop.net: not-listed
b.barracudacentral.org: 127.0.0.2

Significado: Listado en una RBL (ejemplo: respuesta estilo Barracuda).

Decisión: Detén envíos masivos e investiga compromiso/contenido inmediatamente; luego solicita deslistado según el proceso de esa lista. Estar listado es síntoma, no la enfermedad.

Task 16: Detect outbound spikes (compromised account or script gone feral)

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 20
Postfix log summaries for: Fri Jan  3 2026

Grand Totals
------------
messages processed:                    18432
messages delivered:                    12010
messages deferred:                      5200
messages bounced:                       1222
rejected connections:                    410

Significado: Volumen alto + muchas deferencias/rebotes + rechazos: perfil clásico de brote.

Decisión: Trátalo como incidente de seguridad + entregabilidad. Bloquea credenciales, limita tasa y separa transaccional de bulk.

Task 17: Check Postfix SASL auth usage (hunting compromised credentials)

cr0x@server:~$ sudo grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head
  8420 sasl_username=support@corp.example
  3011 sasl_username=noreply@corp.example
   188 sasl_username=dev@corp.example

Significado: Una cuenta domina el envío saliente.

Decisión: Si el remitente principal es inesperado, rota la contraseña/token, revisa IPs de origen y añade MFA/restricciones en SMTP submission.

Task 18: Confirm submission vs relay separation (port 587 with auth)

cr0x@server:~$ sudo ss -lntp | grep -E ":25|:587"
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1010,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1010,fd=15))

Significado: Ambos puertos SMTP (25) y submission (587) están escuchando.

Decisión: Asegura que el puerto 25 no permita relay no autenticado, y que el 587 aplique auth/TLS. Las malas configuraciones aquí derivan en «550 rejected» luego de que te listan.

Nota operativa: cada comando anterior está diseñado para responder una decisión. Si una comprobación no cambia tu siguiente paso, es trivia.
La trivia es cómo desperdicias tiempo mientras el correo arde.

Tres micro-historias corporativas desde el campo

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

Una empresa mediana migró su correo saliente de una VM antigua a una nueva instancia cloud reluciente. Mismo hostname, misma configuración de Postfix,
mismas claves DKIM. Hicieron el cambio en una ventana tranquila y se enviaron un correo de «celebración» a sí mismos. Llegó.
Cerraron el cambio.

El lunes por la mañana, correos de facturación a un cliente grande empezaron a rebotar con 550 5.7.1 rejected. Internamente, todo «lucía bien».
Los logs mostraban entregas exitosas a cuentas personales de Gmail. El equipo asumió que la pasarela del cliente estaba rota,
porque claro que lo estaba. Abrieron un ticket con TI del cliente y esperaron.

El cliente respondió: «Su correo falla SPF.» Eso sonaba imposible—el registro SPF no había cambiado. La suposición equivocada fue sutil:
asumieron que la IP de salida era la IP de la instancia. En realidad, el tráfico saliente estaba siendo NATeado por una IP de egreso distinta en la red cloud.
SPF autorizaba la IP antigua, no la del NAT.

La corrección tomó diez minutos: actualizar SPF con la IP de egreso real y añadir un include para la nueva ruta de relay. Desbloquear llevó más:
el cliente ya había añadido un bloqueo temporal porque los reintentos repetidos parecían abuso.

El postmortem fue corto y algo vergonzoso. La lección fue clara: mide siempre tu IP real de envío.
«Movimos el servidor» no es un cambio de correo. «Cambiamos la identidad IP que el mundo ve» sí lo es.

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

Otra empresa decidió «optimizar la entregabilidad» centralizando todo el correo saliente en un MTA de alta capacidad.
La lógica era elegante: un lugar para gestionar DKIM, un lugar para afinar TLS, una IP para calentar. Incluso compraron una IP «premium» a su proveedor.
Alguien hizo una diapositiva. Tenía flechas.

Funcionó—hasta que marketing lanzó una campaña con un nuevo dominio de tracking y una plantilla HTML muy comprimida.
El MTA centralizado de repente transportó recibos transaccionales y el blast de la campaña. Las tasas de queja subieron.
Algunos destinatarios corporativos empezaron a rechazar con bloqueos de política 550; luego dominios de la familia Microsoft empezaron a limitar; luego comenzaron los listados en RBL.

El problema no fue que marketing enviara correos. Fue que la organización colapsó múltiples perfiles de riesgo en un solo cubo de reputación.
A los receptores no les importa que un mensaje sea un reinicio de contraseña y otro sea «Un truco raro». Ven la misma IP, el mismo comportamiento,
y te puntúan en conjunto.

La recuperación requirió separar los flujos: IPs separadas y a veces dominios distintos para bulk vs transaccional, además de límites estrictos de tasa e higiene de contenido.
También tuvieron que reconstruir confianza con los receptores—lentamente—porque la reputación se recupera a la velocidad del comportamiento consistente, no a la velocidad del pánico.

La optimización es buena. Unificar el radio de explosión no lo es. Haz sistemas más simples, pero no de forma que haga la falla catastrófica.

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

Una firma cercana al sector salud tenía una práctica aburrida: cada cambio de correo saliente incluía un ítem en la checklist para enviar mensajes de prueba
a un conjunto de seed mailboxes alojadas en distintos proveedores y dominios. Conservaban los encabezados. Rastreaban resultados de autenticación. Nadie fue ascendido por ello.

Una noche, su proveedor de DNS tuvo una caída parcial que no dejaba los dominios caídos, solo provocó fallos intermitentes en búsquedas TXT en algunas regiones.
Las consultas SPF empezaron a devolver timeouts. Algunos receptores trataron eso como permerror y rechazaron con 550 5.7.1.
Otros aceptaron pero los bajaron de puntuación. Fue confuso e inconsistente.

Las pruebas seed se encendieron en minutos: DKIM pasaba, pero SPF estaba inestable. El on-call no adivinó. Compararon resolutores, confirmaron el problema de DNS,
y conmutaron a su proveedor DNS secundario que habían configurado meses antes porque alguien insistió en que era «mejor práctica».

El flujo de correo se estabilizó antes de que los clientes notaran. La única parte dramática fue el hilo de chat donde la gente preguntaba cómo lo detectaron tan rápido.
La respuesta fue profundamente poco sexy: tenían una línea base y la miraban.

Broma #2: La mejor herramienta de entregabilidad es un recordatorio de calendario para no hacer cosas creativas los viernes por la tarde.

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

1) “550 5.7.1 rejected” solo para un gran cliente

Síntoma: Gmail funciona, dominios pequeños funcionan, un enterprise rechaza todo.

Causa raíz: El cliente tiene una política de allowlist/denylist, reglas de gateway entrante estrictas o requiere TLS/alineamiento; tu IP/dominio puede estar bloqueado localmente.

Solución: Obtén el texto exacto del rechazo; pide al cliente la razón de la política; proporciona tus IPs de envío, dominio envelope-from y dominio DKIM d=; implementa rDNS y HELO consistente; solicita el allowlist solo después de corregir la autenticación.

2) “550 5.1.1 user unknown” después de una migración

Síntoma: Direcciones previamente válidas ahora rebotan como desconocidas.

Causa raíz: Estás entregando al MX equivocado (DNS cacheado obsoleto, dominio mal escrito o dominio de destinatario mal), o el destinatario cambió de tenant y tu ruta antigua está muerta.

Solución: Verifica registros MX, confirma que el dominio es correcto y valida que el destinatario exista mediante el proceso de directorio del receptor (no adivinando). Evita tormentas de reintentos.

3) “550 reverse DNS required”

Síntoma: Rechazo inmediato al inicio de la conversación SMTP.

Causa raíz: No hay PTR, PTR genérico o mismatch entre PTR y A; HELO tampoco coincide.

Solución: Establece PTR a un hostname estable; asegura que ese hostname resuelva de vuelta a la misma IP; configura Postfix/tu MTA HELO en consecuencia.

4) “550 relay denied” cuando las apps envían correo

Síntoma: Las apps no pueden enviar; los humanos sí.

Causa raíz: La app se conecta al puerto 25 sin auth; la submission debería hacerse por 587 con SMTP AUTH y STARTTLS; o tus restricciones de relay son correctas y la app esperaba un relay abierto (no debería).

Solución: Apunta las apps al puerto de submission 587, habilita auth, restringe por IP donde convenga y confirma que la app usa un envelope-from válido.

5) “550 5.7.26 DMARC reject” en correo reenviado

Síntoma: El reenvío falla; la entrega directa funciona.

Causa raíz: SPF falla en forwarders (porque el reenvío cambia la IP de envío) y DKIM está ausente o roto; la política DMARC es reject y el alineamiento falla.

Solución: Asegura que la firma DKIM sobreviva el tránsito (no reescribas encabezados firmados); considera usar ARC en los forwarders que controles; para forwarders terceros, enfócate en alineamiento DKIM.

6) “550 message content rejected” después de añadir un nuevo tracker de enlaces

Síntoma: Solo fallan las plantillas de marketing; el correo transaccional funciona.

Causa raíz: La reputación del dominio de tracking es mala, o el contenido dispara heurísticas de phishing; a veces los adjuntos son bloqueados.

Solución: Elimina o reemplaza las URLs sospechosas; asegura que el dominio de tracking tiene DNS y reputación correctos; evita acortadores; mantiene HTML simple; separa streams/IPs.

7) “550 rejected” empezó justo después de endurecer SPF

Síntoma: Cambiaste SPF a -all y ahora hay rebotes.

Causa raíz: Olvidaste un remitente legítimo (helpdesk, CRM, nómina, impresoras, servidor antiguo) o excediste límites de búsquedas DNS provocando permerror.

Solución: Haz inventario de remitentes, reduce includes, aplana SPF si hace falta y valida cada flujo. No uses SPF como arma contra tu propio ecosistema.

8) 550s aleatorios con “policy restrictions” en muchos receptores

Síntoma: No todo el correo falla; hay ruido.

Causa raíz: Degradación de reputación con puntuación inconsistente entre receptores; o problemas intermitentes de DNS/TLS que hacen que algunos receptores rechacen.

Solución: Comprueba picos de volumen, cuentas comprometidas, fiabilidad de DNS, errores de handshake TLS y salud de colas; luego estabiliza comportamiento y recalienta reputación.

El fallo meta en la mayoría de estos casos: los equipos tratan los rechazos de correo como «problema del otro lado».
A veces lo es. La mayoría de las veces es tuyo, solo que se expresa a través del servidor de otra persona.

Listas de verificación / plan paso a paso para desbloquearte

Paso 0: Deja de empeorar la situación

• Pausa campañas bulk/marketing inmediatamente si sospechas problemas de reputación.
• Limita la tasa de correo saliente si ves picos o remitentes desconocidos.
• Deshabilita cuentas comprometidas o rota credenciales antes de «trabajar en entregabilidad».
• Preserva evidencia: guarda mensajes de rebote, transcripciones SMTP y encabezados.

Paso 1: Identifica el stream fallido

• ¿Es transaccional (restablecimientos de contraseña, facturas) o bulk (newsletters)?
• ¿Es una dirección remitente, un dominio o todo el envío saliente?
• ¿Es un dominio destinatario o múltiples?

Si no puedes separar streams, hazlo ahora. Esto no es «agradable de tener». Es control de radio de impacto.

Paso 2: Arregla los básicos de identidad (el conjunto «haz esto antes de suplicar por deslistado»)

• Corrige SPF para las IPs de egress y vendors reales.
• Habilita firma DKIM consistentemente para el dominio visible From (o un subdominio alineado).
• Publica DMARC con una política que puedas soportar (comienza con p=none si estás a ciegas; sube cuando estés alineado).
• Configura rDNS/PTR y alinea HELO/EHLO a un hostname resolvible.
• Asegura que TLS funciona; algunos receptores exigen STARTTLS y cifrados modernos.

Paso 3: Confirma que tu comportamiento no parece una botnet

• Mantén tasas de envío estables; evita picos súbitos de 10x.
• Usa envelope-from y dominios From consistentes; no rotar identidades para «evadir bloqueos». Eso huele a abuso.
• Implementa manejo de rebotes y suprime direcciones inválidas.
• Haz que la opción de baja funcione para mail bulk. Sí, eso afecta rechazos.

Paso 4: Acciones dirigidas de desbloqueo

• Si una RBL te lista: identifica por qué (compromiso, relay abierto, patrones de queja), corrige la causa raíz y luego solicita deslistado.
• Si un enterprise te bloquea: proporciona a sus admins tus IPs de envío, dominio DKIM y ejemplos; solicita allowlist temporal solo después de arreglos.
• Si proveedores consumidores te bloquean: enfócate en autenticación, reputación y contenido; calienta lentamente y monitoriza rebotes/quejas.

Paso 5: Prueba la corrección con tests controlados

• Envía un correo mínimo en texto plano (sin enlaces, sin adjuntos) al dominio que falla. Si llega, el contenido es sospechoso.
• Envía una plantilla transaccional típica; luego una de marketing.
• Compara encabezados y resultados de autenticación entre mensajes.

Paso 6: Monta monitorización aburrida para no repetir esto el próximo trimestre

• Alerta sobre tasa de rebotes, deferencias y rechazos por dominio.
• Rastrea tasas de pass/fail de autenticación por stream (SPF/DKIM/DMARC).
• Mantén un inventario de remitentes y vendors legítimos.
• La reputación no necesita pánico diario, pero sí atención semanal.

Una cita para mantenerte honesto:

“La esperanza no es una estrategia.” — máxima general de ingeniería, comúnmente atribuida a líderes de operaciones (idea parafraseada)

La entregabilidad de correo es donde la esperanza se ve limitada por la tasa.

Preguntas frecuentes

1) ¿»550 rejected» siempre es culpa mía?

No. A veces el destinatario tiene una política estricta (bloqueo de remitentes externos, solo allowlist, gateway mal configurado).
Pero asume que es tu culpa hasta que puedas probar lo contrario con comprobaciones de autenticación y comportamiento limpio. Esa mentalidad resuelve incidentes más rápido.

2) ¿Cuál es la diferencia entre 550 5.7.1 y 550 5.1.1?

5.1.1 suele ser «destinatario malo» (usuario desconocido). 5.7.1 es «política/seguridad».
El primero es a menudo un problema de directorio/datos. El segundo es identidad/reputación/contenido/política.

3) Si SPF pasa, ¿puedo ignorar DKIM y DMARC?

No puedes ignorarlos si te importa la entrega consistente. SPF falla con reenvíos y algunos relays.
DKIM da una señal de identidad duradera. DMARC lo ata todo y da a los receptores una política clara y a ti visibilidad mediante reportes.

4) ¿Por qué empezó esto después de movernos a un nuevo proveedor cloud?

Reputación nueva de IP, identidad/NAT de egress nueva, rDNS ausente y diferencias sutiles en TLS son desencadenantes comunes.
Las IPs cloud suelen empezar con reputación neutral como mucho. Calienta lentamente y mantén la autenticación impecable.

5) ¿Puedo simplemente cambiar de IP para evitar un bloqueo?

A veces funciona por poco tiempo. También enseña a los receptores a desconfiar de todo tu dominio.
Arregla la causa raíz primero. Si debes rotar IPs por continuidad del negocio, hazlo de forma transparente y estabiliza el comportamiento de inmediato.

6) ¿Y si estamos listados en una RBL pero no enviamos spam?

Las RBLs listan comportamientos, no tu autoimagen. Puede que tengas una cuenta comprometida, un puerto de submission expuesto, una app vulnerable enviando correo,
o un proveedor usando mal tu dominio. Identifica la fuente de envío y detenla. Luego solicita delisting.

7) Nuestros correos son rechazados solo cuando incluyen adjuntos. ¿Por qué?

Los adjuntos disparan escaneo de malware, políticas de tipo de archivo y límites de tamaño. Algunos gateways rechazan ciertas extensiones o archivos protegidos por contraseña.
Prueba con un correo en texto plano primero; luego añade el adjunto. Si el adjunto es imprescindible, usa formatos aprobados y considera enlaces de descarga segura (con dominios reputados).

8) ¿Importa rDNS en 2026?

Sí. No universalmente, pero lo suficiente como para tropezar con gateways corporativos y stacks de política antiguos.
Un PTR ausente es una razón de bajo esfuerzo para desconfiar de ti, y a los receptores les encantan los motivos de bajo esfuerzo.

9) ¿Por qué entregamos a Gmail pero no a dominios alojados por Microsoft?

Modelos de puntuación distintos, tolerancia diferente a señales borderline y comportamientos de throttling distintos.
Trátalo como una pista: compara resultados de autenticación, TLS y patrones de envío. A menudo el filtrado de la familia Microsoft es menos indulgente con cambios súbitos de volumen.

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

Si es un simple fallo de auth, puede ser minutos u horas tras arreglarlo. Si es daño de reputación por abuso o muchas quejas,
piensa en días a semanas de envío consistente y limpio. No negocias con algoritmos; los superas con persistencia.

Conclusión: próximos pasos que puedes ejecutar hoy

«550 rejected» es el receptor diciéndote que no confía en este mensaje, en este remitente o en este comportamiento. Tu camino más rápido de salida no es
un paseo aleatorio por la configuración. Es un triage disciplinado y arreglos dirigidos.

1. Captura el rechazo exacto (código mejorado + texto) y determina si es identidad, reputación o enrutamiento.
2. Valida los fundamentos: IP real de envío, SPF pasa, DKIM presente/válido, alineamiento DMARC, rDNS, HELO, TLS.
3. Detén la hemorragia: pausa bulk, limita tasa, busca cuentas comprometidas, limpia tus listas.
4. Prueba la corrección con tests controlados que aislen contenido vs política vs destinatario.
5. Prevén repeticiones separando streams y monitorizando patrones de rechazo por dominio y resultados de autenticación.

La entregabilidad de correo no es magia. Es operaciones: identidad, higiene y reputación, todo en cambio continuo.
Trátalo como producción y se comportará como producción. Trátalo como una utilidad y eventualmente te facturará en forma de incidentes.