Bloqueos de política de correo “550 5.7.1” — la vía realista de solución

Qué significa realmente 550 5.7.1 (y por qué es deliberadamente vago)

Los códigos de estado SMTP son engañosamente simples. 550 es un fallo permanente: el servidor remoto está diciendo
“no vuelvas a intentar, arregla algo”. El estado mejorado 5.7.1 suele corresponder a
“entrega no autorizada, mensaje rechazado”, pero eso es un cubo, no un diagnóstico.

El detalle clave: “política” es una decisión remota. Puede dispararse por tu postura de autenticación
(SPF/DKIM/DMARC), tu reputación de IP o dominio, tu rDNS y la identidad HELO/EHLO, tu postura TLS,
tu contenido, tus patrones de envío o las reglas internas del destinatario. A veces es una mezcla.

En términos de producción, 550 5.7.1 no es un mensaje de error. Es una disputa contractual.
El sistema receptor afirma: “Tu sistema no cumple nuestro umbral en este momento.”
Tu trabajo es determinar qué umbral.

Un cambio de mentalidad práctico: deja de pensar “el correo está caído”. Piensa “la entregabilidad está fallando”.
Esto no es pedantería. Disponibilidad es que tu servidor esté arriba. Entregabilidad es que otros confíen en él.
Herramientas diferentes. Arreglos diferentes. Plazos diferentes.

Guion de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando una cola se está acumulando y los ejecutivos circulan nerviosos, necesitas un orden de operaciones que corte el ruido.
Aquí está la vía más rápida que he encontrado y que evita las dos trampas clásicas: cambios DNS aleatorios y cambios de relay en pánico.

Primero: clasifica el rechazo

• ¿Dónde se rechaza? ¿Durante el diálogo SMTP (RCPT TO / DATA) o después de la aceptación (rebote posterior)?
• ¿Es a todos los destinatarios o a un solo dominio? “Solo a Microsoft” es diferente de “a todos”.
• ¿Son todos los remitentes o solo un dominio From? El DMARC desalineado suele parecer “algunas marcas fallan”.

Segundo: revisa identidad y alineación (ganancias baratas)

• SPF: IP(s) salientes autorizadas y cadenas include no rotas.
• DKIM: firma válida, selector correcto, claves no caducadas, firmando los headers correctos.
• DMARC: alineación entre el From visible y las identidades SPF/DKIM.

Tercero: comprueba señales de reputación (la parte lenta)

• Reputación de IP saliente y listas de bloqueo (RBL) que los receptores realmente usan.
• Reputación de dominio (especialmente si tu dominio se usó recientemente para spam, cuentas comprometidas o comportamiento imitador).
• Señales de comportamiento: picos súbitos de volumen, IP nueva, alta tasa de rebotes, baja interacción.

Cuarto: verifica presentación SMTP (rDNS/HELO/TLS)

• Existe reverse DNS y coincide con tu hostname anunciado (o al menos parece intencional).
• HELO/EHLO es un FQDN real con forward DNS coincidente.
• TLS es sensato; certificados no expirados; no estás publicitando cifrados extraños.

Quinto: contenido y enrutamiento

• Disparadores de contenido: acortadores de URL, MIME malformado, falta de List-Unsubscribe para mail masivo, tipos de adjuntos sospechosos.
• Enrutamiento: ¿estás reenviando inesperadamente a través de un smart host o NAT de nube que cambió la IP saliente?

Si sigues este orden, normalmente identificarás el cuello de botella dominante en 30–60 minutos y dejarás de sangrar.
La cola larga—recuperar la reputación—puede tomar días, pero al menos sabrás que estás pagando la deuda correcta.

Hechos interesantes y contexto histórico (para que lo raro tenga sentido)

1. SMTP precede al spam por décadas. El modelo original asumía pares mayormente cooperativos; la autenticación no era un requisito primario.
2. Los códigos de estado mejorados (como 5.7.1) se estandarizaron después para dar más matices que “550”, pero los proveedores todavía los sobrecargan.
3. SPF empezó como una idea de “quién puede enviar para este dominio” porque falsificar remitentes de sobre fue barato y común; nunca fue una solución completa contra el phishing.
4. DKIM surgió del firmado criptográfico a nivel de dominio para sobrevivir al reenvío mejor que SPF; sigue siendo frágil cuando intermediarios reescriben contenido.
5. El poder real de DMARC es la alineación y la política. Permite al propietario de un dominio decir “si esto no autentica como yo, rechaza o cuarentena”.
6. Reverse DNS se convirtió en un contrato social. No es un requisito estricto del protocolo, pero muchos receptores tratan la falta de rDNS como “probablemente botnet”.
7. Las listas de bloqueo existían antes que los modernos sistemas de reputación. Los operadores tempranos compartían listas porque era más rápido que discutir con cada spammer individualmente.
8. Los grandes proveedores ejecutan motores de reputación propietarios. Puedes pasar SPF/DKIM/DMARC y aún así ser bloqueado si tu tráfico parece abusivo.
9. “Política” también significa decisiones de cumplimiento locales. Algunas organizaciones rechazan correo desde rangos residenciales, ciertas geografías o posturas TLS débiles sin importar la autenticación.

Recopila evidencia primero: qué capturar antes de “arreglar” algo

Cuando el correo falla, la gente empieza a “probar cosas”. Así es como terminas con tres selectores DKIM mal configurados,
un registro SPF que excede los límites de búsqueda DNS y un problema de reputación que no puedes explicar porque cambiaste cinco variables a la vez.

Captura un pequeño paquete de evidencia. No es burocracia; es cómo evitas repetir interrupciones.

• Un mensaje de rebote completo incluyendo encabezados y transcripción SMTP (no una captura de pantalla).
• Registros Postfix/Exim alrededor de la falla con ID de cola y respuesta remota.
• La IP y el hostname remitente tal como se observan externamente (no lo que crees que es).
• Registros DNS actuales para SPF, selectores DKIM, DMARC, MX, A/AAAA, PTR.
• Cambios recientes de envío: nueva campaña de marketing, IP nueva, relay nuevo, despliegue de la app, cambio de NAT o remediación de cuenta comprometida.

Broma #1: Si tu “arreglo” es editar registros DNS de memoria a las 2 a.m., felicidades—has reinventado la ruleta con menos bebidas.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decides

Estas son tareas ejecutables que puedes hacer desde un host de correo Linux o una caja de diagnóstico con acceso de red.
Cada tarea incluye: comando, salida de ejemplo, qué significa la salida y qué decides a continuación.

Tarea 1: Encuentra el texto exacto de rechazo remoto y la etapa (Postfix)

cr0x@server:~$ sudo grep -E "status=bounced|status=deferred|5\.7\.1|policy" /var/log/mail.log | tail -n 8
Jan 04 10:11:22 mx1 postfix/smtp[18422]: 9C2E91A2C4: to=<user@recipient.example>, relay=mx.recipient.example[203.0.113.9]:25, delay=2.1, delays=0.1/0.02/0.6/1.4, dsn=5.7.1, status=bounced (host mx.recipient.example[203.0.113.9] said: 550 5.7.1 Message rejected due to policy (in reply to end of DATA command))
Jan 04 10:11:23 mx1 postfix/qmgr[913]: 9C2E91A2C4: removed

Significado: El rechazo al final de DATA significa que el remoto aceptó el sobre pero no le gustó el contenido o los resultados de autenticación tras el escaneo.
Si se rechazó en RCPT TO, sería más probable reputación de IP, RBL o política del destinatario.

Decisión: Si se rechaza al final de DATA, prioriza la alineación de autenticación y las comprobaciones de contenido; aún verifica la reputación, pero empieza por lo que el remoto escaneó.

Tarea 2: Inspecciona un mensaje en cola de forma segura (Postfix)

cr0x@server:~$ sudo postcat -q 9C2E91A2C4 | sed -n '1,120p'
*** ENVELOPE RECORDS ***
message_size: 48231            1980             1               0               0
message_arrival_time: Sat Jan  4 10:11:20 2026
create_time: Sat Jan  4 10:11:20 2026
named_attribute: log_ident=mx1
sender: noreply@brand.example
*** MESSAGE CONTENTS ***
Received: from app1.internal (app1.internal [10.0.2.15])
        by mx1.brand.example (Postfix) with ESMTPSA id 9C2E91A2C4
        for <user@recipient.example>; Sat, 04 Jan 2026 10:11:20 +0000 (UTC)
From: "Brand Support" <noreply@brand.example>
To: <user@recipient.example>
Subject: Password reset
Date: Sat, 04 Jan 2026 10:11:20 +0000
Message-ID: <20260104101120.12345@app1.internal>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Significado: Esto confirma el dominio From visible, la ruta de envío (ESMTPSA desde una app interna)
y si los encabezados parecen “normales”. Un Message-ID en un dominio interno puede ser una pequeña señal de desconfianza para algunos filtros.

Decisión: Si Message-ID u otros encabezados se ven extraños, corrige la política de encabezados de la app/MTA (dominio de Message-ID, Date, MIME). Luego vuelve a probar antes de cambiar DNS.

Tarea 3: Verifica desde qué IP realmente envías (las sorpresas de NAT saliente existen)

cr0x@server:~$ ip route get 8.8.8.8 | sed -n '1p'
8.8.8.8 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000

Significado: La IP de origen es 192.0.2.10 para tráfico saliente típico. Si esperabas otra IP, tienes un problema de enrutamiento/NAT.

Decisión: Si la IP de envío cambió recientemente, trata la reputación como sospechosa y revisa rDNS y listas de bloqueo para la nueva IP.

Tarea 4: Comprueba DNS forward para tu hostname de correo (A/AAAA)

cr0x@server:~$ dig +short A mx1.brand.example
192.0.2.10

Significado: El hostname resuelve. Muchos receptores penalizan nombres HELO que no resuelven.

Decisión: Si está vacío, arregla DNS. Si resuelve a la IP equivocada, corrígelo antes que cualquier otra cosa.

Tarea 5: Comprueba reverse DNS (PTR) para la IP de envío

cr0x@server:~$ dig +short -x 192.0.2.10
mx1.brand.example.

Significado: PTR existe y parece intencional.

Decisión: Si el PTR falta o es genérico (valor por defecto del proveedor de nube), solicita cambio de rDNS a tu proveedor. Muchos bloqueos de política dependen en silencio de esto.

Tarea 6: Comprueba la identidad HELO/EHLO que presenta tu Postfix

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|smtp_helo_name'
mydomain = brand.example
myhostname = mx1.brand.example
smtp_helo_name = $myhostname

Significado: Presentas un FQDN estable. Bien.

Decisión: Si smtp_helo_name está configurado a algo no calificado (como “mail”) o interno, arréglalo y reinicia Postfix.

Tarea 7: Valida el registro SPF y detecta explosión de búsquedas DNS

cr0x@server:~$ dig +short TXT brand.example | sed -n '1,3p'
"v=spf1 ip4:192.0.2.10 include:spf.mailvendor.example -all"

Significado: SPF está presente. Pero esto no te dice si los includes exceden el límite de 10 búsquedas DNS.

Decisión: Si tienes múltiples includes, debes evaluar el recuento de búsquedas. Si lo excedes, SPF puede dar “permerror”, lo que puede disparar bloqueos de política.

Tarea 8: Evalúa SPF desde fuera usando una herramienta local (simulación de resultados de autenticación)

cr0x@server:~$ python3 - <<'PY'
import sys, dns.resolver
domain="brand.example"
answers=dns.resolver.resolve(domain,'TXT')
for r in answers:
    for s in r.strings:
        t=s.decode()
        if t.startswith("v=spf1"):
            print(t)
PY
v=spf1 ip4:192.0.2.10 include:spf.mailvendor.example -all

Significado: Confirma la cadena SPF que publicas. Esto todavía no es una evaluación SPF completa, pero detecta rápidamente “múltiples registros SPF” y problemas obvios de formato.

Decisión: Si ves más de un registro v=spf1, corrige inmediatamente. Los receptores pueden tratarlo como permerror de SPF.

Tarea 9: Comprueba el registro DMARC y la postura de política

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

Significado: Tienes alineación estricta (adkim=s, aspf=s) y una política de rechazo.
Excelente para antifishing. También implacable si tus sistemas no están perfectamente alineados.

Decisión: Si estás recibiendo bloqueos de política en proveedores importantes justo después de activar DMARC estricto, confirma que todos los emisores legítimos firman DKIM con d= alineado o que SPF alinea con el dominio From.

Tarea 10: Verifica que exista la clave pública DKIM para el selector que crees usar

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

Significado: El selector existe. Un selector faltante es una causa muy común de outage cuando rotaste claves y olvidaste el DNS.

Decisión: Si falta, publícalo, espera la propagación y vuelve a probar. Si está presente, verifica que tu MTA realmente use ese selector.

Tarea 11: Confirma la configuración de firmado DKIM (ejemplo OpenDKIM + Postfix)

cr0x@server:~$ sudo egrep -n 'Domain|Selector|KeyFile|Socket' /etc/opendkim.conf | head
14:Domain                 brand.example
15:Selector               s2024
16:KeyFile                /etc/opendkim/keys/brand.example/s2024.private
23:Socket                 inet:8891@localhost

Significado: Muestra qué dominio DKIM y selector estás configurado para usar.

Decisión: Si Domain/Selector no coinciden con DNS, corrige la configuración. Si la ruta de KeyFile es incorrecta o los permisos están rotos, el firmado DKIM falla silenciosamente y los receptores te consideran sospechoso.

Tarea 12: Comprueba Authentication-Results en un mensaje entregado (verdad de campo)

cr0x@server:~$ grep -i "Authentication-Results" -n /var/mail/test-inbox | tail -n 3
120:Authentication-Results: mx.google.example; spf=pass (google.example: domain of noreply@brand.example designates 192.0.2.10 as permitted sender) smtp.mailfrom=noreply@brand.example; dkim=pass header.i=@brand.example header.s=s2024; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=brand.example

Significado: Este es el veredicto del receptor. Si dice SPF pass, DKIM pass, DMARC pass, puedes dejar de adivinar y pasar a reputación/contenido/límites de tasa.

Decisión: Si SPF/DKIM/DMARC fallan aquí, arregla la alineación antes que nada. Pasar localmente es irrelevante; la evaluación del receptor es lo que importa.

Tarea 13: Comprueba si tu IP está listada en DNSBLs comunes (señal rápida, no evangelio)

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

Significado: Salida vacía sugiere “no listado” en estos. Si obtienes una IP de vuelta, estás listado.

Decisión: Si estás listado en un DNSBL usado por tu destinatario, o arreglas la causa (compromiso/relay abierto) y solicitas delistado, o cambias IPs salientes (y luego las calientas con cuidado).

Tarea 14: Valida postura TLS desde fuera (STARTTLS, cadena de certificados)

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

Significado: El certificado es válido y no está caducado.

Decisión: Si está caducado o no coincide, arregla los certificados. Algunas organizaciones aplican bloqueos de política por no-TLS o TLS roto, especialmente en correo B2B.

Tarea 15: Asegúrate de no ser un relay abierto (sí, todavía)

cr0x@server:~$ swaks --server mx1.brand.example --to victim@external.example --from attacker@external.example --data "Subject: test

hello"
=== Trying mx1.brand.example:25...
=== Connected to mx1.brand.example.
<-  220 mx1.brand.example ESMTP Postfix
 -> EHLO server
<-  250-mx1.brand.example
 -> MAIL FROM:<attacker@external.example>
<-  554 5.7.1 Relay access denied

Significado: Relay denegado para remitente externo no autenticado. Bien.

Decisión: Si acepta relay, detén todo. Estás a punto de hacerte famoso de la peor manera y los bloqueos 550 serán lo menor de tus problemas.

Tarea 16: Comprueba crecimiento de la cola saliente y comportamiento de reintentos

cr0x@server:~$ mailq | tail -n 5
-- 2 Kbytes in 1 Request.

Significado: Cola baja es buena. Durante un incidente podrías ver cientos/miles en cola con repetidas diferencias.

Decisión: Si la cola crece, limita la tasa o pausa el flujo ofensivo (campaña de marketing, cuenta comprometida) para evitar empeorar la reputación mientras arreglas la identidad.

De dónde vienen los bloqueos de política: los modos reales de fallo

1) La autenticación pasa… pero no está alineada

Esta es la variante más enfurecedora porque tus registros muestran con orgullo “SPF=pass” y “DKIM=pass” en algún lugar,
sin embargo DMARC falla y el receptor te trata como suplantador. La alineación es la diferencia entre
“un dominio autenticado” y “el dominio From visible autenticado”.

Causas típicas:

• Tu app envía From: brand.example pero el remitente de sobre es bounce@mailer.vendor.example y solo eso pasa SPF.
• DKIM firma con d=vendor.example y no con d=brand.example.
• DMARC configurado con alineación estricta mientras subdominios legítimos envían correo que no coincide exactamente.

2) Espiral de muerte de reputación (volumen y rebotes)

La reputación se alimenta de retroalimentación. Si de repente envías a una lista con muchas direcciones inválidas, generas rebotes duros.
Si tu contenido parece phishing, los destinatarios lo ignoran o lo reportan. Si sigues enviando mientras te bloquean, amplificas la señal:
“este remitente no aprende.”

La recuperación es posible, pero lenta y aburrida. Eso es bueno: significa que los atacantes tampoco pueden “resetear” instantáneamente.

3) Desajuste de identidad de infraestructura (rDNS, HELO, IP dinámica)

Muchos receptores tratan el correo de IPs sin PTR, o con un PTR que grita “instancia genérica de nube”, como sospechoso.
No siempre es un bloqueo duro, pero cuando se combina con otras señales débiles, se convierte en el voto decisivo.

Si estás enviando desde un rango de ISP residencial, espera rechazos 5.7.1 consistentes de sistemas de correo corporativos serios.

4) Bloqueos por política basados en contenido (sí, tu correo inofensivo puede parecer malvado)

Los filtros son implacables con patrones que correlacionan con abuso:
límites MIME malformados, correo solo HTML con texto diminuto y enlaces gigantes, URLs acortadas, texto de enlace que no coincide,
adjuntos con macros, y “dominio nuevo + lenguaje urgente + enlace de acceso”.

Tu error de “política” puede ser que el sistema remoto rechace aceptar tu mensaje porque supera un umbral.
No obtienes la puntuación. Obtienes la pared.

5) Reenvíos y listas que rompen SPF (y a veces DKIM)

SPF falla cuando el correo es reenviado porque la IP del servidor reenviante no está autorizada en tu SPF.
DKIM puede sobrevivir al reenvío, pero se rompe si el reenviador reescribe el cuerpo o ciertos encabezados.
Entonces DMARC falla porque ambos mecanismos son frágiles ante modificaciones.

Si tu audiencia incluye universidades, listas de distribución, sistemas de tickets y pasarelas de seguridad,
esto puede ser una fracción significativa de los rechazos “aleatorios” 5.7.1.

6) Limitación específica del proveedor y puertas de política

Los grandes proveedores y pasarelas corporativas implementan sus propias puertas: límites por IP, topes por dominio, controles de ráfaga y sospecha sobre “nuevo remitente”.
A veces responden con deferencias 4xx. A veces responden con bloqueos 5xx de política que son efectivamente “vete hasta que mejore la reputación”.

Aquí es donde los operadores pierden días discutiendo con el protocolo. No es un problema del protocolo. Es un sistema anti-abuso haciendo su trabajo.

Una cita que mantiene honestos a los equipos

Idea parafraseada de Richard Cook (seguridad y confiabilidad): “el éxito viene de ajustes continuos; el fallo ocurre cuando esos ajustes no pueden mantenerse al día.”

Tres microhistorias corporativas desde la trinchera

Microhistoria #1: El incidente causado por una suposición equivocada (el NAT que robó el correo)

Una empresa SaaS mediana ejecutaba Postfix en un par de VMs. Tenían SPF, DKIM, DMARC—todo verde en sus propias pruebas.
Sin embargo, una porción de correo transaccional a un proveedor de mailbox grande empezó a fallar con bloqueos 550 5.7.1.
El equipo supuso “DKIM se rompió”, porque ese es el culpable habitual tras un despliegue.

Rotaron claves DKIM. Ajustaron la alineación DMARC. Añadieron otro include a SPF.
La interrupción continuó. La cola se enfureció. Soporte se volvió más ruidoso.

La cuestión real fue más mundana: su equipo de red había movido las VMs de correo detrás de un NAT de salida diferente durante un mantenimiento de firewall.
El correo saliente ahora salía desde una IP que no estaba en SPF y sin rDNS configurado.
Sus pruebas internas golpeaban un proveedor de pruebas más permisivo; el proveedor grande no.

Una vez identificada la verdadera IP de egress (revisando enrutamiento y comparando con los logs del destinatario),
la solución fue sencilla: actualizar SPF para la nueva IP, configurar PTR correctamente y estabilizar HELO.
La lección quedó: en correo, “¿desde qué IP enviamos?” no es una pregunta filosófica. Es la línea principal de la autopsia.

Microhistoria #2: La optimización que salió mal (ajuste de cola vs reputación)

Un equipo empresarial decidió que su rendimiento saliente era “demasiado lento”. Marketing quería lanzamientos más grandes, más rápido.
Alguien ajustó la concurrencia y las tasas de conexión de Postfix al alza. Los gráficos se vieron genial. La latencia bajó.
Su MTA se comportó como si hubiera tomado tres espressos y encontrado nueva razón de ser.

Luego empezaron a aparecer bloqueos 550 5.7.1 intermitentes, mayormente en los proveedores más grandes y algunos gateways corporativos estrictos.
El equipo supuso “caída del proveedor” porque los reintentos a veces funcionaban, y porque culpar a otro da consuelo.

Los proveedores no estaban caídos. Estaban aplicando control de abuso.
El nuevo patrón de concurrencia parecía un remitente comprometido: ráfagas, alta paralelización, intentos rápidos de entrega a muchos destinatarios.
Unos pocos errores en las cargas de listas generaron rebotes duros, amplificando la señal negativa.

Revirtieron la concurrencia, implementaron limitación por dominio y añadieron un “modo de calentamiento” para envíos grandes.
La entregabilidad se estabilizó. La optimización no solo salió mal; enseñó al equipo que el KPI principal para correo no es el rendimiento.
El KPI es “mensajes aceptados y no marcados como basura”.

Microhistoria #3: La práctica aburrida pero correcta que salvó el día (informes DMARC como humo temprano)

Una compañía financiera tenía la costumbre que parecía exceso: revisaban informes agregados DMARC semanalmente.
No con un comité caro—solo una rotación en on-call y una nota interna breve.
La mayoría de semanas era aburrido: tasas de pase, unas fuentes desconocidas, nada dramático.

Una semana notaron una nueva fuente enviando correo que decía ser su dominio, fallando alineación y viniendo de un proveedor de hosting aleatorio.
No era su infraestructura. No era un vendor autorizado. Era suplantación o un tercero comprometido.
Ningún cliente se había quejado aún. Ninguna blacklist los había golpeado todavía. Pero el humo era visible.

Endurecieron SPF, verificaron selectores DKIM de todos los vendors y contactaron al proveedor de hosting con evidencia.
También aseguraron preventivamente que sus flujos legítimos estuvieran perfectamente alineados y firmados, para no quedar atrapados en el radio de explosión.

Cuando las campañas de phishing se intensificaron y los proveedores de mailbox se volvieron más estrictos con esa marca, su tráfico legítimo siguió fluyendo.
La práctica no era glamorosa, pero cambió la curva del incidente de “caída súbita” a “mitigación silenciosa”.

Broma #2: La entregabilidad de correo es la única disciplina donde hacerlo todo bien sigue sintiéndose como ser juzgado por un gato.

Errores comunes: síntoma → causa raíz → arreglo específico

1) Síntoma: 550 5.7.1 aparece solo para un proveedor grande

Causa raíz: Puntuación de reputación específica del proveedor, limitación o heurísticas de contenido; a veces rDNS/TLS faltante que proveedores más pequeños ignoran.

Arreglo: Verifica Authentication-Results de ese proveedor, confirma IP de egress, arregla rDNS/HELO/TLS y luego reduce la tasa de envío y limpia rebotes. Espera tiempo de recuperación.

2) Síntoma: SPF “pass” pero DMARC falla

Causa raíz: SPF pasa para un dominio diferente (remitente de sobre) que el dominio From visible; falla la alineación DMARC.

Arreglo: Asegura que el dominio remitente del sobre se alinee con From (o configura DKIM con d=brand.example y alinea DMARC). Evita la alineación estricta hasta estar seguro de que todas las fuentes cumplen.

3) Síntoma: Todo funciona hasta rotar claves DKIM

Causa raíz: Nuevo selector no publicado en DNS, latencia de propagación DNS o permisos de archivo de clave incorrectos provocando fallo silencioso de firmado.

Arreglo: Publica el selector primero, espera TTL, valida con dig, luego cambia el firmado. Monitoriza logs por errores de firmado DKIM.

4) Síntoma: Pico súbito de rebotes y luego bloqueos de política

Causa raíz: Falta de higiene de listas, cuenta comprometida enviando a direcciones recogidas o una importación mala que causó destinatarios inválidos.

Arreglo: Detén el flujo, cuarentena el remitente/app, limpia listas, implementa límites de salida y procesamiento de rebotes. Luego reanuda lentamente.

5) Síntoma: Los bloqueos empezaron tras mudarse a nueva región de nube

Causa raíz: Nuevo rango de IP con reputación fría/deficiente; rDNS faltante; desajuste entre HELO y PTR; algunos proveedores desconfían ciertos rangos.

Arreglo: Configura PTR y forward DNS correctamente, calienta la IP gradualmente y considera usar un servicio de relay reputado durante el calentamiento para correo crítico.

6) Síntoma: Solo fallan destinatarios reenviados (universidades, listas, sistemas de tickets)

Causa raíz: El reenvío rompe SPF; DKIM se rompe si el cuerpo se modifica; DMARC falla y los receptores aplican la política.

Arreglo: Prefiere la alineación DKIM; asegúrate de que DKIM sobreviva modificaciones comunes (canonicalización simple puede ser frágil). Considera soporte ARC si operas un servicio de reenvío; para emisores, mantén DKIM robusto.

7) Síntoma: “Relay access denied” usuarios internos dicen que es 5.7.1 política

Causa raíz: Mala configuración de submission (clientes no autentican, puerto equivocado, restricciones de relay incorrectas), no un bloqueo remoto.

Arreglo: Arregla el servicio de submission en 587 con auth, verifica smtpd_recipient_restrictions y asegura que los clientes usen STARTTLS + auth.

8) Síntoma: Rechazo sucede al final de DATA para correo muy HTML

Causa raíz: Puntuación de contenido: reputación de URL, MIME malformado, dominios de tracking, patrones From/nombre de display que encajan mal, falta de parte text/plain.

Arreglo: Valida MIME, incluye multipart/alternative con text/plain, elimina patrones de URL riesgosos, arregla HTML roto, evita acortadores y alinea dominios de tracking con tu marca.

Listas de verificación / plan paso a paso

Paso a paso: Estabiliza el incidente (primeras 2 horas)

1. Deja de empeorarlo. Pausa flujos masivos y remitentes sospechosos. Mantén los restablecimientos de contraseña y recibos si puedes aislarlos.
2. Elige un dominio destinatario que falle y una muestra de mensaje. No depures diez a la vez.
3. Captura la transcripción de rebote y el ID de cola, además de la respuesta remota y la etapa (RCPT vs DATA).
4. Confirma la IP de egress y verifica consistencia PTR + HELO + registro A.
5. Valida SPF/DKIM/DMARC desde la perspectiva del receptor usando Authentication-Results de una entrega de prueba o buzón sembrado.
6. Comprueba señales obvias de reputación: presencia en DNSBL y si la IP es nueva/fría.
7. Haz un cambio a la vez, documéntalo y vuelve a probar. Los cambios DNS cuentan como “cambios lentos”.

Paso a paso: Arregla identidad y alineación (mismo día)

1. SPF: registro único, IPs autorizadas correctas, evita includes excesivos, usa -all solo cuando estés seguro.
2. DKIM: firma todos los flujos salientes con d= alineado para el dominio From visible. Rota claves con solapamiento.
3. DMARC: empieza con p=none durante el despliegue si tienes emisores desconocidos; pasa a quarantine y reject cuando las tasas de pase sean estables.
4. Remitente de sobre: asegúrate de que el dominio de rebote esté bajo tu control y se alinee cuando SPF es tu vía primaria.
5. Encabezados: corrige dominio de Message-ID, Date, estructura MIME y asegúrate de no producir contenido malformado.

Paso a paso: Recupera la reputación (días a semanas)

1. Reduce volumen y suaviza las ráfagas. Los proveedores desconfían remitentes con picos.
2. Limpia listas y suprime rebotes. Las tasas altas de rebote duro son daño autoinfligido.
3. Segmenta flujos de correo. El correo transaccional no debe compartir reputación con marketing experimental.
4. Calienta IPs nuevas lentamente. Empieza con destinatarios comprometidos y aumenta volumen gradualmente.
5. Monitorea quejas y señales de interacción donde estén disponibles (feedback loops, reportes de usuarios).
6. No “arregles” la reputación saltando IPs semanalmente. Eso parece evasión. Algunos sistemas recuerdan.

Checklist operacional: Qué mantener permanentemente

• Diagrama documentado del flujo de correo: apps → submission → MTA → relay (si hay) → IPs de egress a internet.
• Fragmentos de zona DNS en control de versión o infraestructura como código para SPF/DKIM/DMARC.
• Runbook de rotación de claves: publica selector, valida DNS, cambia firmado, mantiene selector viejo durante la ventana de solapamiento.
• Limitación de salida por dominio/proveedor y valores de concurrencia sensatos.
• IPs/dominios separados para transaccional vs marketing cuando el negocio depende de que los recibos lleguen.
• Alertas en picos de rebotes, crecimiento de cola y fallos súbitos de autenticación.

Preguntas frecuentes

1) ¿“550 5.7.1” es siempre un problema de SPF/DKIM/DMARC?

No. A menudo está correlacionado con fallos de autenticación, pero puede ser reputación, rDNS/HELO desajustado, política TLS o filtrado de contenido.
La etapa SMTP importa: el rechazo en RCPT suele apuntar a IP/reputación; el rechazo al final de DATA suele apuntar a evaluación de contenido/autenticación tras el escaneo.

2) Pasamos SPF, DKIM y DMARC, pero aún recibimos 550 5.7.1. ¿Y ahora qué?

Asume reputación o contenido. Confirma que envías desde la IP que crees, comprueba consistencia PTR/HELO,
revisa tasas de rebote/quejas y busca disparadores de contenido (URLs, adjuntos, MIME malformado, tracking agresivo).
También verifica que no estés generando ráfagas que disparen puertas de política.

3) ¿Puedo arreglarlo cambiando mi IP?

A veces, pero trátalo como último recurso para correo crítico—especialmente si la IP actual está listada por un compromiso real que ya arreglaste.
Una IP nueva es “fría” y también puede estar bloqueada. Si rotas IPs repetidamente, pareces abusador y tu futuro se vuelve interesante en el sentido equivocado.

4) ¿Cuál es la diferencia entre SPF fail y SPF permerror?

Fail significa que la IP no está autorizada por la política SPF del dominio. Permerror significa que el registro está roto (a menudo por demasiadas búsquedas DNS o múltiples registros SPF).
Permerror es especialmente doloroso porque es autoinfligido y puede disparar fallo DMARC incluso para correo legítimo.

5) ¿Por qué el reenvío rompe las cosas?

SPF se evalúa contra la IP conectante. Cuando un reenviador envía tu correo, la IP conectante pasa a ser la del reenviador, no la tuya—por eso SPF suele fallar.
DKIM puede sobrevivir al reenvío, pero se rompe si el reenviador modifica el cuerpo o encabezados firmados. DMARC falla si ni SPF alineado ni DKIM alineado pasan.

6) ¿Deberíamos poner DMARC en p=reject para detener la suplantación?

Eventualmente, sí. Pero hazlo como un SRE, no como un jugador. Inventaría todos los emisores legítimos primero, consigue DKIM consistente,
empieza con p=none para observar, luego pasa a quarantine y finalmente a reject.
De lo contrario bloquearás tu propio correo de negocio y lo llamarás “seguridad”.

7) ¿Cómo mantenemos el correo transaccional fluyendo cuando marketing nos bloquea?

Separa flujos: diferentes IPs, diferentes subdominios y, idealmente, infraestructura separada.
El correo transaccional necesita reputación estable y comportamiento conservador. Marketing necesita experimentar, lo cual está bien—solo no dejes que queme las salidas de emergencia.

8) ¿Puede el contenido solo causar un “bloqueo de política” aun con autenticación perfecta?

Sí. La autenticación responde “quién eres”, no “eres bienvenido”. Si tu mensaje parece entrega de malware, phishing de credenciales o tráfico de afiliados spammy,
algunos receptores bloquearán al final de DATA. Arregla la corrección MIME, elimina URLs sospechosas y evita tipos de adjunto riesgosos.

9) ¿Cuál es la comprobación de cordura más rápida durante un incidente?

Saca una transcripción de rebote, confirma IP de egress y PTR, y obtén un encabezado Authentication-Results desde un buzón sembrado.
Eso triangula identidad vs reputación vs contenido más rápido que cualquier discusión en Slack.

Conclusión: pasos siguientes que realmente reducen los 550

“Bloqueo de política 550 5.7.1” no es un solo bug. Es un veredicto desde el otro lado de internet, normalmente respaldado por un montón de señales que no ves completamente.
Tu trabajo es hacer tu identidad inequívoca, tu infraestructura consistente y tu comportamiento de envío aburrido.
Aburrido es bueno. Aburrido llega.

Pasos prácticos siguientes:

1. Construye un paquete de evidencia repetible: transcripción de rebote, ID de cola, etapa, IP de egress y registros DNS actuales.
2. Haz la alineación innegociable: DKIM con d= alineado para tu dominio From, SPF que realmente coincida con la IP de envío, DMARC que refleje la realidad.
3. Endurece la identidad SMTP: rDNS, HELO, forward DNS y certificados TLS válidos.
4. Controla el comportamiento: limitación de tasa, segmenta flujos y evita que las ráfagas se conviertan en incidentes de reputación.
5. Institucionaliza la práctica aburrida: monitoriza resultados de autenticación y picos de rebotes antes de que se conviertan en una interrupción.

Si haces esas cinco cosas, 550 5.7.1 no desaparecerá para siempre—el correo sigue siendo correo—pero se convertirá en una molestia ocasional en lugar de un incidente recurrente de producción.