Correo: «Dirección del destinatario rechazada»: por qué usuarios válidos siguen rebotando

Qué significa realmente «Dirección del destinatario rechazada»

Cuando ves «Dirección del destinatario rechazada», no estás viendo un único error estandarizado. Estás viendo la interpretación del remitente de una negativa durante la conversación SMTP—casi siempre en respuesta al RCPT TO: comando.

En términos sencillos: el lado receptor (tu lado, o el de un tercero) rechazó al destinatario durante la fase de sobre (envelope), antes de aceptar el cuerpo del mensaje. Por eso a los remitentes les encanta: rechazar pronto ahorra ancho de banda y almacenamiento. También por eso recibes el ticket molesto: el remitente piensa que dijiste que la dirección está mal.

Códigos de estado SMTP típicos que verás

• 550 5.1.1 — usuario desconocido / buzón no disponible (o aparentando serlo).
• 550 5.1.0 / 5.7.1 — rechazo por política que puede etiquetarse erróneamente como «dirección rechazada».
• 551 / 553 — a menudo «no local» o problemas de sintaxis/política de la dirección.
• 450 / 451 / 4.7.1 — rechazo temporal (greylisting, limitación de velocidad, tiempo de espera del backend). Estos a veces aparecen como «destinatario rechazado» en las interfaces porque las UIs no son tus amigas.

Punto clave: «Dirección del destinatario rechazada» no necesariamente significa que el usuario no existe. Significa que el sistema receptor declinó aceptar correo para ese destinatario en ese momento, por alguna razón. Muchos sistemas por defecto usan rechazos en la etapa de destinatario como un lugar conveniente para aplicar política.

Una cita que debería estar en el escritorio de todo ingeniero de correo: Idea parafraseada: “La esperanza no es una estrategia.” — atribuida a muchas personas de fiabilidad, pero la idea es un principio sólido de operaciones. En términos de correo: deja de esperar que sea «solo algo transitorio». Demuestra dónde ocurre la negación.

Dónde ocurre la negación en SMTP (y por qué importa)

SMTP es conversacional. Eso importa porque cada etapa tiene diferentes ajustes, diferentes registros y diferentes consecuencias.

Etapas relevantes en la conversación

1. Conexión / banner: tu borde se presenta. Puede ocurrir negociación TLS. Aquí es donde las reputaciones de IP pueden cortarte antes incluso de llegar a los destinatarios.
2. EHLO/HELO: capacidades. Los motores de política a veces aplican comprobaciones de HELO o requieren TLS antes de continuar.
3. MAIL FROM: remitente de sobre. Decisiones de SPF/DMARC de alineación pueden influir en la aceptación posterior, a veces incorrectamente retrasadas hasta el tiempo de RCPT.
4. RCPT TO: la dirección del destinatario. Este es el sitio habitual de «dirección del destinatario rechazada». Comprobaciones de existencia de destinatario, búsquedas en directorio, enrutamiento a servidores de buzón downstream y reglas de filtrado del destinatario se activan aquí.
5. DATA: cuerpo del mensaje. Escaneo de contenido, límites de tamaño, comprobaciones de malware. Si rechazas aquí, la semántica del rebote puede verse muy diferente.

Si la negación ocurre en tiempo de RCPT, deberías esperar ninguna copia del mensaje en tu lado (a menos que deliberadamente la journales o registres). Eso significa que depuras usando registros y trazas, no búsquedas en buzones.

Y sí, es posible rechazar en tiempo de RCPT porque tu backend de buzones es lento o no está disponible. Los sistemas hacen eso para evitar aceptar correo que no pueden entregar. El correo es un protocolo de almacenar y reenviar, pero muchas implementaciones reales se comportan como un servicio RPC sincrónico.

Broma #1: SMTP es el único protocolo donde «550» puede significar «usuario inexistente» y también «hoy no es mi día, no preguntes por qué».

Hechos e historia interesantes (corto, útil)

• Hecho 1: SMTP precede a los sistemas modernos de identidad; fue diseñado para redes cooperativas, no para ecosistemas adversariales de spam. Muchos problemas de «dirección rechazada» son retrofits de política sobre un protocolo antiguo.
• Hecho 2: La idea de rechazar en tiempo de RCPT se hizo popular porque aceptar DATA para spam es caro—ancho de banda, CPU para escaneo y E/S de disco.
• Hecho 3: Los «ataques de recolección de directorios» (directory harvest attacks) empujaron a los administradores a desactivar la verificación de destinatarios o a mentir con fallos genéricos, lo que luego confunde a remitentes legítimos.
• Hecho 4: El greylisting (rechazos temporales 4xx) fue una técnica antispam temprana que explotaba que los MTAs cumplidores reintentan. Aún causa quejas de “usuario válido rebotó” cuando los remitentes no reintentan correctamente.
• Hecho 5: Los buzones catch-all fueron una vez una red de seguridad común. Muchas organizaciones los eliminaron para reducir la entrada de spam, aumentando la frecuencia de rebotes 5xx duros.
• Hecho 6: Los DNSBL (listas de bloqueo) son operativamente efectivos pero pueden crear falsos positivos que se manifiestan como rechazos de destinatario según dónde se apliquen las comprobaciones.
• Hecho 7: Algunos MTAs implementan «callouts de destinatario» (verificar destinatarios consultando sistemas downstream). Los callouts mal configurados pueden convertir una lentitud transitoria del backend en «usuario desconocido».
• Hecho 8: Existen direcciones de correo internacionalizadas (SMTPUTF8), pero muchos sistemas aún las manejan mal. Usuarios con partes locales no ASCII pueden ser «válidos» internamente y rechazados externamente.
• Hecho 9: Los grandes proveedores usan cada vez más límites de velocidad y detección de anomalías que pueden rechazar en RCPT como señal de abuso, no como afirmación de existencia del destinatario.

Taxonomía de modos de fallo “usuario válido aún rebota”

1) El destinatario existe, pero no en ese sistema

El enrutamiento de correo es brutalmente literal. Si el MX apunta al lugar equivocado, o un gateway cree que es autoritativo para un dominio cuando no lo es, el destinatario puede ser «desconocido» porque el servidor equivocado está siendo preguntado.

Causas comunes:

• Registros MX cambiados pero no propagados, o en caché incorrectamente.
• Cerebro dividido (split-brain): diferentes resolutores ven respuestas MX distintas.
• Múltiples caminos de entrada (filtro en la nube + on-prem) con reglas de validación de destinatarios inconsistentes.
• Una lista de «dominios relay» / «dominios locales» obsoleta en el MTA de borde.

2) La validación del destinatario depende de una consulta a directorio que falla

En tiempo de RCPT, tu borde puede consultar LDAP/AD, SQL, una API o un mapa plano. Si esa consulta caduca o da error, algunas configuraciones fallan cerradas (reject) y otras fallan abiertas (accept and queue).

Fail-closed es más seguro contra carga de spam. También es como creas un incidente de alta prioridad por una caída del directorio que de otro modo sería «solo inicio de sesión lento».

3) Existe un buzón válido, pero el alias no

A los usuarios les encantan los alias. Especialmente ventas. Si quitas un alias, el usuario sigue «existiendo» pero el correo al alias es legítimamente inválido. El remitente dirá que es válido porque funcionó una vez. No mienten. Funcionó una vez.

Esto también ocurre con plus-addressing, subaddressing y variaciones con puntos. Algunos sistemas los aceptan; otros normalizan; otros rechazan.

4) El almacén de buzones backend está caído o saturado; el borde rechaza temprano

Si tu borde valida destinatarios hablando con el servidor de buzón (LMTP, proxy, callout), entonces la latencia de almacenamiento puede aparecer como rechazo SMTP de destinatario. Aquí es donde ser ingeniero de almacenamiento se vuelve divertido en el sentido de «¿por qué estoy aquí a las 3 a. m.?».

Si los metadatos del buzón viven en almacenamiento en red y ese almacenamiento está enfermo—picos de latencia, pool casi lleno, corrupción de metadatos o un fallo de NFS—tus comprobaciones de destinatario pueden fallar y negarás usuarios perfectamente válidos.

5) Reglas anti-spam/anti-abuso demasiado agresivas

Los motores de política a veces rechazan en tiempo de RCPT porque es barato. Pero cuando conectas lógica de contenido o de reputación en RCPT, los textos de error pueden ser engañosos. «Dirección del destinatario rechazada» se convierte en el envoltorio genérico para «tu IP parece sospechosa» o «estás enviando demasiado rápido».

6) El lado del remitente está roto (y aún así te culpan)

Algunos remitentes no reintentan en 4xx. Algunos reescriben el sobre. Algunos envían comandos malformados. Algunos hacen batching de destinatarios que dispara tus límites por conexión. Y algunos sistemas muestran a los usuarios un «dirección rechazada» genérico independientemente de lo que ocurrió.

Broma #2: Si alguna vez te sientes inútil, recuerda que hay clientes de correo que ocultan el código de estado SMTP «para mantenerlo simple».

Manual de diagnóstico rápido

Cuando estás contra el reloj, no necesitas una clase. Necesitas encontrar el cuello de botella rápido y moverte.

Primero: clasifica el rebote con el código SMTP real

• Si es 5xx, es un rechazo duro. Asume problema de configuración/política hasta demostrar lo contrario.
• Si es 4xx, es un rechazo temporal. Asume limitación de velocidad, greylisting o caída/latencia del backend.
• Si la interfaz de rebotes no muestra códigos, exige los encabezados brutos del rebote o la transcripción SMTP. Sin transcripción, no hay certeza.

Segundo: confirma el enrutamiento del correo (DNS y propiedad del borde)

• Comprueba MX desde múltiples resolutores.
• Confirma que el host que rechaza es realmente tuyo (o de tu proveedor) y no un gateway obsoleto.
• Verifica que el dominio esté configurado de forma consistente en todos los saltos entrantes.

Tercero: reproduce con una sesión SMTP contra el mismo borde

• Usa openssl s_client para STARTTLS y envía un RCPT TO manual.
• Compara el comportamiento para un usuario conocido bueno vs el usuario que «rebota».
• Busca diferencias: mapeo de alias, sensibilidad a mayúsculas, subaddressing, variantes de dominio.

Cuarto: lee los registros receptores en el punto de rechazo

• Encuentra la razón exacta del rechazo en los logs del MTA (no la paráfrasis del rebote).
• Identifica si el rechazo vino de: mapas de destinatarios, LDAP, servicio de políticas, filtro antispam o un callout descendente.

Quinto: decide si fallar abierto temporalmente

Si directorios/backends están inestables y tienes capacidad de cola, considera aceptar y encolar correo temporalmente en lugar de rechazar en RCPT. Compra tiempo y protege el tráfico del negocio. También incrementa la entrada de spam. Es un tradeoff de adultos—hazlo conscientemente.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas prácticas que puedes ejecutar durante un incidente. Cada una incluye un comando realista, una salida de ejemplo, lo que significa y la decisión a tomar. Úsalas como herramientas, no rituales.

Tarea 1: Inspeccionar el rebote para obtener el estado SMTP real

cr0x@server:~$ grep -E "Status:|Diagnostic-Code:|Final-Recipient:" -n bounce.eml
12:Final-Recipient: rfc822; user@example.com
13:Action: failed
14:Status: 5.1.1
15:Diagnostic-Code: smtp; 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table

Significado: Este es un rechazo duro en la etapa de destinatario, y el texto indica un problema de mapeo de destinatarios local («virtual mailbox table»).

Decisión: Omite teorías de spam/reputación. Ve directo a la configuración de búsqueda de destinatarios y a los mapas.

Tarea 2: Confirmar registros MX para el dominio

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

Significado: El correo entrante debería fluir a estos gateways.

Decisión: Si el host que rechaza no es uno de estos, puede que estés depurando un gateway desmantelado u oculto, o el remitente usa DNS en caché/incorrecto.

Tarea 3: Comprobar resolución MX desde un resolutor distinto (caza de split-brain)

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

Significado: Un resolutor público está de acuerdo. Buena señal.

Decisión: Si los resolutores internos discrepan, arregla la caché/reenviadores DNS internos antes de tocar configuraciones de correo.

Tarea 4: Verificar identidad del servidor que rechaza y nombre TLS

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mailgw.example.net:25 -servername mx1.mailgw.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mx1.mailgw.example.net
issuer=CN = Example Internal Issuing CA

Significado: Estás hablando con el gateway esperado, y el certificado coincide.

Decisión: Procede con pruebas SMTP en vivo contra el mismo endpoint.

Tarea 5: Reproducir manualmente el rechazo RCPT sobre SMTP

cr0x@server:~$ printf "EHLO test.example.net\r\nMAIL FROM:<probe@test.example.net>\r\nRCPT TO:<user@example.com>\r\nQUIT\r\n" | nc -w 5 mx1.mailgw.example.net 25
220 mx1.mailgw.example.net ESMTP Postfix
250-mx1.mailgw.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
250 2.1.0 Ok
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table
221 2.0.0 Bye

Significado: El gateway mismo está rechazando el destinatario antes de DATA. Esto no es un escaneo de contenido downstream.

Decisión: Revisa mapas virtuales de Postfix, mapas de alias, mapas LDAP o delegación de políticas.

Tarea 6: Comprobar si la dirección está presente en los mapas de Postfix

cr0x@server:~$ postmap -q "user@example.com" /etc/postfix/virtual_mailbox_maps
mailboxes/example.com/user/

Significado: El mapa contiene una entrada y resuelve a una ruta de buzón.

Decisión: Si la prueba SMTP aún rechaza, el gateway puede no estar usando este mapa (configuración errónea), o estás consultando el archivo/tipo equivocado.

Tarea 7: Confirmar qué mapas usa realmente Postfix

cr0x@server:~$ postconf -n | egrep "virtual_mailbox_maps|virtual_alias_maps|relay_domains|mydestination|smtpd_recipient_restrictions"
mydestination = localhost
relay_domains = example.com
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unknown_recipient_domain, reject_unlisted_recipient
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_mailbox_maps = ldap:/etc/postfix/ldap/virtual_mailbox_maps.cf

Significado: La validación de destinatarios está aplicada (reject_unlisted_recipient) y el mapa de buzones es basado en LDAP, no hash.

Decisión: Deja de editar /etc/postfix/virtual_mailbox_maps. Arregla la búsqueda LDAP, credenciales, base DN, filtro o conectividad.

Tarea 8: Probar la búsqueda LDAP directamente (la comprobación “¿el directorio miente?”)

cr0x@server:~$ ldapsearch -x -H ldap://ldap1.example.net -b "ou=People,dc=example,dc=net" "(mail=user@example.com)" dn mail
dn: uid=user,ou=People,dc=example,dc=net
mail: user@example.com

Significado: LDAP contiene la dirección.

Decisión: Si Postfix aún rechaza, el problema está en la configuración del mapa LDAP (filtro equivocado, nombre de atributo, permisos del bind DN) o en fallos intermitentes de LDAP.

Tarea 9: Revisar logs de Postfix por la razón específica del rechazo

cr0x@server:~$ sudo grep -R "reject: RCPT from" /var/log/mail.log | tail -n 5
Jan 04 09:42:11 mx1 postfix/smtpd[28411]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Significado: El rechazo está ocurriendo en smtpd con “NOQUEUE” (nunca aceptado). Esta es una decisión de política en la puerta delantera.

Decisión: Concéntrate en la lista/consulta de destinatarios y restricciones; no pierdas tiempo buscando el mensaje en la cola.

Tarea 10: Validar el archivo de mapa LDAP que usa Postfix

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/ldap/virtual_mailbox_maps.cf
server_host = ldap1.example.net
search_base = ou=People,dc=example,dc=net
query_filter = (mail=%s)
result_attribute = mail
bind = yes
bind_dn = cn=postfix,dc=example,dc=net

Significado: Este mapa devuelve el atributo mail. Eso está bien para comprobaciones de existencia, pero no siempre para rutas de entrega de buzón.

Decisión: Si Postfix espera un destino/ruta de buzón y devuelves el propio correo, puedes obtener «unknown in virtual mailbox table». Alinea result_attribute con cómo entregas (por ejemplo, un atributo de ruta maildir), o usa mapas separados para existencia vs destino.

Tarea 11: Comprobar timeouts de backend que se hacen pasar por “usuario desconocido”

cr0x@server:~$ sudo journalctl -u postfix -S "10 min ago" | egrep -i "timeout|ldap|defer|reject" | tail -n 20
Jan 04 09:40:02 mx1 postfix/ldap[28122]: warning: ldap_search: Timeout
Jan 04 09:40:02 mx1 postfix/smtpd[28115]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 450 4.1.1 <user@example.com>: Recipient address rejected: temporary lookup failure; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Significado: La búsqueda LDAP hizo timeout; el rechazo es temporal (4xx). Algunos remitentes aún mostrarán esto como un «rebote».

Decisión: Trátalo como un incumplimiento del SLO de una dependencia: arregla la latencia/conectividad LDAP. Considera fail-open o caching para comprobaciones de existencia de destinatarios.

Tarea 12: Verificar si estás haciendo greylisting o limitación de velocidad en RCPT

cr0x@server:~$ sudo grep -R "greylist\|rate\|policyd\|postscreen" /var/log/mail.log | tail -n 10
Jan 04 09:41:09 mx1 postfix/smtpd[28307]: warning: unknown[203.0.113.77]: SASL LOGIN authentication failed: authentication failure
Jan 04 09:41:12 mx1 postfix/smtpd[28411]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 451 4.7.1 Service unavailable - try again later; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Significado: El rechazo es 451 4.7.1: temporal, probablemente una puerta de política (greylisting, abuso o problemas de autenticación).

Decisión: Si el remitente es legítimo y sensible al tiempo, pon en lista blanca temporalmente sus IPs de envío mientras ajustas la política y confirmas su comportamiento de reintento.

Tarea 13: Comprobar si el dominio se trata como local/relay correctamente

cr0x@server:~$ postconf -n | egrep "mydestination|virtual_mailbox_domains|relay_domains"
mydestination = localhost
relay_domains = example.com, example.org
virtual_mailbox_domains = example.com

Significado: El dominio aparece tanto como relay como dominio de buzón virtual. Eso es sospechoso; puede cambiar qué búsquedas se usan.

Decisión: Aclara la arquitectura: o alojas buzones (virtual mailbox domains) o retransmites a downstream (relay_domains). La configuración mixta a menudo resulta en rechazos de «usuario válido» en un camino.

Tarea 14: Confirmar que el buzón existe en el almacenamiento

cr0x@server:~$ sudo ls -ld /var/vmail/example.com/user
drwx------ 12 vmail vmail 4096 Jan  4 09:10 /var/vmail/example.com/user

Significado: El maildir existe en disco. Bien.

Decisión: Si las comprobaciones de destinatario aún fallan, el problema no es «carpeta de buzón faltante» sino probablemente mapeo/consulta o permisos/contexto SELinux.

Tarea 15: Comprobar salud de almacenamiento y condiciones de “casi lleno” que hacen que los sistemas de correo rechacen destinatarios

cr0x@server:~$ df -h /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       2.0T  1.9T   80G  96% /var/vmail

Significado: 96% de uso en el volumen de correo. Muchos MTAs y agentes de entrega empiezan a fallar de formas extrañas bajo alta utilización, y algunas capas de política rechazan temprano para evitar explosiones de cola.

Decisión: Inicia alivio de capacidad inmediatamente: expande, limpia o mueve buzones. No ajustes errores SMTP mientras el almacenamiento está gritando.

Tarea 16: Verificar presión en la cola (si aceptas correo y luego difieres la entrega)

cr0x@server:~$ mailq | tail -n 5
-- 2435 Kbytes in 512 Requests.

Significado: Cola moderada. Si este número se dispara, puedes estar aceptando correo pero fallando downstream, lo que puede empujar a los administradores a «rechazar temporalmente» destinatarios y crear rebotes accidentalmente.

Decisión: Si el crecimiento de la cola es descontrolado, arregla la entrega downstream primero; considera aumentar recursos de cola temporalmente o limitar el ingreso en lugar de rebotar usuarios válidos.

Tres micro-historias corporativas desde las trincheras

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

Migraron el filtrado entrante a un gateway de seguridad de correo en la nube. Ventana de cambio limpia, plan de reversión, pruebas pasaron. El equipo supuso que la validación de destinatarios sería idéntica al antiguo borde on-prem porque “solo reenvía correo”.

El lunes por la mañana, un subconjunto de usuarios empezó a rebotar para remitentes externos con «550 5.1.1 user unknown». Internamente todo parecía bien: los usuarios podían enviarse correos entre sí y podían recibir de algunos socios. Se sentía aleatorio, lo que es señal de que te espera un día largo.

La suposición equivocada fue sutil: el borde antiguo aceptaba correo para todos los destinatarios y dejaba que la capa de buzones decidiera qué era válido. El gateway nuevo hacía validación de destinatarios en RCPT sincronizando un feed del directorio. La actualización del feed se retrasó. Alias recién creados y listas de distribución no estaban presentes aún, por lo que el gateway los rechazó como desconocidos.

La solución inmediata fue operativa, no filosófica: aumentar la frecuencia de sincronización del directorio y deshabilitar temporalmente el rechazo estricto de destinatarios para ciertos patrones de direcciones mientras la sincronización se estabilizaba. La solución a largo plazo fue de gobernanza: cualquier cambio de identidad que afecte direcciones de correo debe tratarse como configuración de producción, con garantías de propagación y observabilidad.

Todos aprendieron la misma lección que siempre aprenden, solo que otra vez: “reenviar correo” es un mito. Cada salto es un punto de aplicación de políticas. Si no sabes qué salto es el autoritativo para la existencia del destinatario, no tienes un sistema de correo—tienes un generador de rebotes.

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

Una gran organización estaba siendo golpeada por spam e intentos de recolección de directorio. Alguien propuso una optimización: rechazar destinatarios desconocidos inmediatamente en el borde, antes del escaneo de contenido. Eso ahorraría CPU y disco. Era correcto en principio y desastroso en detalle.

Implementaron verificación de destinatarios haciendo callouts en vivo desde el borde a los servidores de buzón. Los servidores de buzón estaban respaldados por un clúster de almacenamiento ocupado que ocasionalmente tenía picos de latencia durante operaciones de snapshot. La mayoría de usuarios nunca notó nada porque la entrega de correo podía retrasarse y luego ponerse al día. Pero con callouts en RCPT, un pico de 300 ms se convirtió en un timeout SMTP y luego en rechazos.

De repente, durante las ventanas de snapshot, el borde empezó a rechazar destinatarios válidos como «desconocidos». Los remitentes externos vieron fallos duros. Internamente, el monitoreo mostraba “servidores de buzón bien” porque los servidores estaban arriba, solo lentos. Los gráficos de almacenamiento mostraban el pico, pero nadie lo relacionó con el comportamiento SMTP hasta que un SRE se sentó y reprodujo la transcripción SMTP.

La solución no fue deshabilitar la protección antispam. La solución fue dejar de usar comprobaciones sincrónicas de dependencias backend para la existencia de destinatarios. Pasaron a un directorio de destinatarios cacheado en el borde con estaleza acotada, y configuraron timeouts para fallar abiertos en errores de búsqueda mientras limitaban por tasa a remitentes sospechosos. También coordinaron el tiempo de snapshots con las horas pico de correo. Trabajo aburrido de alineación. Gran beneficio.

La optimización es genial, pero solo cuando entiendes el nuevo modo de fallo que estás comprando. Aquí, intercambiaron “carga de spam” por “acoplamiento con dependencias de producción”. En correo, el acoplamiento es donde la fiabilidad viene a morir.

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

Un equipo financiero se quejó de que facturas a un empleado rebotaban con «dirección del destinatario rechazada». El empleado era definitivamente real. Todos se prepararon para otro día de arqueología de correo.

El equipo de correo tenía una práctica aburrida: cada rechazo SMTP entrante se registraba con un motivo estructurado del motor de políticas, y esos logs eran buscables por destinatario e IP de envío. Nada lujoso. Solo registro disciplinado y retención.

Consultaron los logs y encontraron que la misma IP remitente había disparado una regla de limitación de tasa tras un pico de mensajes a múltiples destinatarios. El motor de políticas rechazó en RCPT con un 451 4.7.1, pero el sistema del remitente lo tradujo en un rebote duro para el usuario. La frase «dirección del destinatario rechazada» era una mentira de UI.

Porque tenían el tiempo exacto, el nombre de la regla y el código SMTP, pudieron hacer una corrección quirúrgica: poner en lista blanca la IP remitente temporalmente y pedir al socio que ajuste su comportamiento de reintento. Sin sacudidas de configuración. Sin cambios DNS especulativos. El incidente cerró rápido, y el equipo pareció mágicamente competente—aunque en realidad eran competentes de forma poco glamorosa.

La observabilidad no es glamorosa, pero es la diferencia entre un incidente y una novela de misterio. En producción quieres incidentes, no novelas.

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

1) Síntoma: «550 5.1.1 user unknown» para un usuario que existe

Causa raíz: El borde hace validación estricta de destinatarios contra un directorio/mapa obsoleto o que falla.

Solución: Verifica qué mapa es autoritativo (postconf -n), prueba la búsqueda directamente, arregla sincronización/timeouts LDAP. Considera caching y fail-open para fallos de búsqueda.

2) Síntoma: Rebotes solo de algunos remitentes externos

Causa raíz: Enrutamiento dividido (objetivos MX distintos), remitente con MX en caché antiguo, o socio usando un camino gateway específico que aplica políticas de destinatario diferentes.

Solución: Compara hostnames/IPs que rechazan entre rebotes. Alinea la política de destinatarios en todos los gateways entrantes. Asegura que gateways viejos respondan claramente «dominio no manejado» en lugar de «usuario desconocido».

3) Síntoma: Solo los alias rebotan; la dirección primaria funciona

Causa raíz: Mapa de alias faltante, alias eliminado o alias no incluido en el feed de directorio usado por el borde.

Solución: Vuelve a añadir el alias o corrige la sincronización de alias. Si lo eliminaste intencionalmente, comunica y establece un periodo controlado de redirección o respuesta automática en lugar de un rebote duro.

4) Síntoma: Receptores aleatorios rebotan en horas pico

Causa raíz: La verificación de destinatarios depende de la latencia del backend (LDAP, callouts a servidores de buzón, almacenamiento). Los timeouts causan rechazos.

Solución: Incrementa la resiliencia: caché local, timeouts más largos/apropiados, fail-open para errores transitorios y separa los umbrales antispam de las comprobaciones de existencia de destinatarios.

5) Síntoma: «Dirección del destinatario rechazada» pero el código SMTP es 5.7.1

Causa raíz: Rechazo por política (reputación, autenticación, TLS requerido, remitente bloqueado) presentado con texto engañoso por la UI del remitente o un gateway.

Solución: Usa logs/transcripción. Si es por política, ajusta la política. No pierdas tiempo validando el buzón.

6) Síntoma: Nuevas incorporaciones rebotan durante algunas horas tras su creación

Causa raíz: Retraso de propagación identidad-a-correo (sincronización de directorio, políticas de libreta de direcciones, sincronización de gateway en la nube). El borde rechaza hasta que los datos llegan.

Solución: Acorta el intervalo de sincronización, publica SLOs de propagación esperados y considera aceptar y encolar correo para destinatarios desconocidos durante esa ventana si el impacto de negocio es alto.

7) Síntoma: Solo direcciones internacionalizadas rebotan externamente

Causa raíz: Incompatibilidad en manejo de SMTPUTF8/IDN; gateway o remitente no soporta partes locales UTF-8 o expectativas de punycode en el dominio.

Solución: Asegura soporte SMTPUTF8 de extremo a extremo o evita partes locales no ASCII para direcciones de cara al exterior. Para dominios, confirma configuración IDN consistente.

8) Síntoma: El usuario existe, pero el correo rebota tras mover/migrar buzón

Causa raíz: Atributo de enrutamiento de correo (targetAddress, tabla de enrutamiento de correo o mapa de transporte interno) no actualizado en todas partes; algunos gateways aún apuntan al almacén antiguo.

Solución: Audita atributos de enrutamiento, asegura que la antigua tienda devuelva diferidos temporales (4xx) en lugar de 5xx duros durante la migración, y mantén reenvíos/relays hasta que el corte sea totalmente consistente.

Listas de comprobación / plan paso a paso

Paso a paso: manejar un ticket de “usuario válido rebotó” como un adulto

1. Obtén el rebote crudo. Pide los encabezados completos y la línea diagnóstica SMTP. Las capturas de pantalla son decoración.
2. Extrae: código SMTP, host que rechaza, marca de tiempo, destinatario, remitente de sobre, IP remitente si está presente.
3. Confirma enrutamiento: registros MX, y si el host que rechaza está en la ruta de entrada que esperas.
4. Reproduce: sesión SMTP manual al host que rechaza; prueba tanto el destinatario informado como un destinatario de control.
5. Lee los logs: encuentra la entrada NOQUEUE: reject y el módulo (smtpd, policy, ldap, postscreen).
6. Identifica la puerta: mapas de destinatarios, directorio, motor de políticas, limitación de tasa, callout o enrutamiento downstream.
7. Arregla la puerta: entrada en mapa, sincronización de alias, ajuste de timeouts, lista blanca, salud del backend o corrección DNS/enrutamiento.
8. Decide mitigación temporal: fail-open para búsquedas, aceptar y encolar temporalmente, o lista blanca de socios.
9. Verifica con la misma prueba de reproducción. No esperes a que un socio “intente más tarde” sin pruebas.
10. Anota la clase de incidente. Si no puedes categorizarlo la próxima vez, no lo arreglaste realmente.

Lista de comprobación: decisiones de diseño que reducen estos incidentes

• Elige dónde se aplica la existencia de destinatario: borde vs capa de buzón. Sé explícito.
• Si la aplicas en el borde, cachea con una ventana de estaleza definida y monitorea la salud de sincronización.
• Separa “usuario desconocido” de “rechazo por política” en los logs y en las respuestas SMTP (códigos de estado mejorados claros ayudan).
• Prefiere 4xx en fallos de dependencias (timeout LDAP, timeout de callout a buzón). 5xx debe significar “esto nunca funcionará”.
• Mantén consistencia en rutas entrantes (varios MX, gateways en la nube, bordes regionales). Misma lógica de destinatarios en todas partes.
• Instrumenta y conserva logs de rechazo el tiempo suficiente para emparejar las líneas temporales reportadas por negocio.
• El monitoreo de capacidad de almacenamiento es monitoreo de correo si tus metadatos de buzón y la entrega dependen de él.

Lista de comprobación: qué no hacer (porque se siente productivo)

• No «vacíes DNS» como primer movimiento. Verifica las respuestas DNS y el comportamiento de caché primero.
• No deshabilites la validación de destinatarios globalmente como respuesta de pánico sin considerar el impacto de oleadas de spam.
• No edites archivos de mapas que Postfix no está usando (revisa postconf -n antes de tocar nada).
• No trates 4xx como un problema menor; algunos remitentes no reintentan y tú seguirás siendo responsable del outage.
• No aceptes correo a ciegas si no puedes encolar de forma segura (disco casi lleno, cola ya explotando).

Preguntas frecuentes

1) Si el usuario puede iniciar sesión, ¿por qué el correo diría «usuario desconocido»?

Porque la identidad de inicio de sesión y la identidad de enrutamiento de correo son sistemas distintos. El borde puede validar contra una vista diferente del directorio, una sincronización obsoleta o un atributo distinto (principal vs alias).

2) ¿Siempre es culpa nuestra «Dirección del destinatario rechazada»?

No. Puede ser un remitente que no reintenta en 4xx, un remitente usando MX en caché viejo, o una UI que parafrasea todo rechazo como un problema de dirección. Tu trabajo es demostrar dónde ocurrió el rechazo y por qué.

3) ¿Deberíamos rechazar destinatarios desconocidos en el borde?

Usualmente sí para controlar spam, pero solo si puedes hacerlo de forma fiable: búsquedas rápidas de directorio, caching y comportamiento sensato ante fallos de dependencias. Si no, cambias spam por rebotes autoinfligidos.

4) ¿Cuál es la diferencia entre rechazar en RCPT vs después de DATA?

El rechazo en tiempo de RCPT ocurre antes de aceptar el cuerpo del mensaje; es más barato y evita encolar. Rechazar en DATA te da más contexto (escaneo de contenido), pero ya aceptaste más trabajo y puede que necesites generar DSNs según el comportamiento.

5) ¿Por qué algunos rebotes muestran 550 pero el problema real es limitación de tasa?

Algunos gateways usan códigos 5xx genéricos para múltiples rechazos de política, y algún software remitente colapsa múltiples errores en «dirección rechazada». Siempre usa el código de estado mejorado y el texto diagnóstico exacto de los logs.

6) ¿Realmente los problemas de almacenamiento pueden causar “destinatario rechazado”?

Sí. Si la verificación del destinatario depende de metadatos de buzón en disco o de un callout a un servidor de buzón que está lento por latencia de almacenamiento, el borde puede hacer timeout y rechazar al destinatario.

7) ¿Cuál es la mitigación temporal más segura durante una caída de directorio?

Si tienes capacidad de cola: fallar abierto en errores de búsqueda de directorio (aceptar correo, diferir entrega) mientras se limita por IP y se mantienen controles básicos anti-abuso. Si no tienes capacidad de cola, es posible que debas 4xx tempfail.

8) ¿Por qué solo ocurre con cuentas nuevas?

Retraso de propagación: el buzón existe en un sistema, pero la lista de destinatarios del borde (o sincronización del gateway en la nube) no se ha actualizado. Arregla la tubería de sincronización y publica expectativas para que «funciona en dos horas» no sea tu plan operativo.

9) Nuestro socio insiste en que recibió un rebote duro, pero nosotros vemos 451 tempfails. ¿Quién tiene razón?

Ambos. Tú devolviste un fallo temporal; su sistema decidió tratarlo como permanente (o su UI lo hizo). Si es un socio de alto valor, pídeles confirmar el comportamiento de reintento y considera una whitelist enfocada.

10) ¿Cómo prevenimos mensajes de error engañosos?

No puedes controlar las UIs de los remitentes, pero sí puedes controlar tus respuestas SMTP. Usa códigos de estado mejorados precisos e incluye una razón corta que mapee a una clave de runbook interno («policy:rate-limit», «lookup:ldap-timeout»).

Conclusión: próximos pasos que sí puedes hacer

«Dirección del destinatario rechazada» no es un diagnóstico. Es un síntoma de una decisión tomada en tiempo de destinatario SMTP—a menudo por una capa de políticas que intenta ser eficiente. Tu trabajo es encontrar la puerta exacta y decidir si debe ser estricta, cacheada o temporalmente permisiva.

Haz lo siguiente:

1. Estandariza cómo capturas rebotes: requiere código SMTP, host que rechaza y marca de tiempo.
2. Haz explícita la validación de destinatarios: qué salto es autoritativo y qué ocurre cuando las búsquedas fallan.
3. Instrumenta razones de rechazo con logs estructurados y consérvalos el tiempo suficiente para emparejar las líneas temporales del negocio.
4. Audita dependencias: latencia LDAP, callouts a buzones backend y capacidad de almacenamiento. Si pueden rechazar destinatarios, son parte de tu SLO de entrada.
5. Practica el manual de diagnóstico rápido una vez cuando no estés en llamas. Tu yo futuro estará menos gruñón.