Rebotes de correo: cómo leer uno y qué significa cada código

Qué es un rebote, y los dos momentos en que se produce

La palabra está tomada del papel, y es la imagen equivocada. Nada viaja de vuelta. Un mensaje se va entregando de servidor en servidor, y el último que todavía lo tiene y no consigue deshacerse de él escribe un mensaje nuevo — dirigido a ti, sobre el antiguo — y envía ese en su lugar. Todo lo que puedes averiguar está en ese informe, y el informe vale exactamente lo que valga la máquina que lo escribió.

Se puede producir en dos momentos muy distintos, y distinguirlos es la mayor parte del diagnóstico. Otros dos resultados parecen fallos desde donde tú estás, y no lo son:

Así que «ha rebotado» nombra dos cosas distintas. Una es un error que te mostró tu propio software, y la otra es una carta que te escribió la máquina de un desconocido, y solo la segunda trae un informe que se pueda leer. El resto de esta guía trata sobre ese informe.

Dónde está en realidad el motivo

Un informe de entrega es un mensaje en tres partes, y esa forma está fijada desde el RFC 3464. La primera parte es la disculpa, escrita para un humano por la máquina más cercana a ti. La segunda es el bloque legible por máquina, la única parte que contiene hechos. La tercera es tu mensaje original, o solo sus cabeceras, para que puedas saber cuál de ellos falló.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Lee la parte del medio en este orden:

Final-Recipient:

Qué dirección falló. Un informe puede llevar un bloque por destinatario, así que en un mensaje enviado a varias personas esta es la forma de saber de cuál se trata — y es muy posible que a los demás sí les haya llegado.

Action:

failed es un rebote. delayed es un aviso de que un servidor todavía lo está intentando y no ha renunciado a nada; puede que aún recibas un segundo informe diciendo que funcionó. relayed y delivered no son fallos en absoluto, y es fácil confundirlos con uno.

Status:

El código de estado ampliado — tres números, pensados para que los lea el software y no tú. Es la parte que se puede comparar entre un proveedor y otro, cosa que las frases nunca permiten.

Diagnostic-Code:

La línea que importa. Es la respuesta propia del servidor remoto, citada palabra por palabra, con su código de respuesta y la frase que haya escrito su administrador. Todo lo anterior es un relato de segunda mano; esto es el original.

Remote-MTA:

Qué host lo dijo. Vale la pena mirarlo siempre que el fallo tenga que ver con el enrutamiento: un nombre de host que no reconoces suele significar que el correo del dominio va a parar a algún sitio que no esperabas, o a donde antes iba y ya no.

La frase que va en lo más alto del informe no es una prueba. La escribe tu propio servidor de salida, con las palabras que traiga de fábrica su software, sobre un fallo que solo está retransmitiendo. Dos disculpas idénticas pueden estar encima de dos líneas Diagnostic-Code: completamente distintas, que es por lo que un rebote leído de arriba abajo se malinterpreta tan a menudo.

Los dos números, y el dígito que decide

Un rechazo se escribe así, y son tres cosas distintas unidas por espacios:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

El 550 es el código de respuesta: tres dígitos, definidos por el propio SMTP en el RFC 5321, y la parte que el protocolo necesita para decidir qué hacer a continuación. El 5.1.1 es el código de estado ampliado del RFC 3463, añadido porque tres dígitos no bastaban para expresar lo suficiente. Todo lo que sigue es texto libre, escrito por quien administre ese servidor, y no lo estandariza absolutamente nada.

Los dos números empiezan por el mismo dígito, y ese dígito es el veredicto:

El segundo número es el asunto — qué tipo de cosa salió mal. Es la forma más rápida de ubicar un código que nunca has visto:

Rebote duro (hard bounce)

Un 5. La dirección está mal, ha desaparecido, o se rechaza por política, y volver a enviar el mismo mensaje no cambia nada. Los remitentes masivos retiran una dirección de la lista a la primera, porque seguir insistiendo es lo que hace que un dominio remitente acabe limitado en todas partes a la vez.

Rebote blando (soft bounce)

Un 4. Un buzón lleno, un servidor ocupado, un rechazo temporal por política. Se reintenta sin que nadie tenga que hacer nada, y normalmente llega; solo te enteras si antes se agotan los reintentos.

Ninguno de los dos términos aparece en ninguna especificación. Son la abreviatura que usa el sector del envío para ese primer dígito, que es lo que de verdad importa — y vale la pena conocer esa abreviatura, porque cualquier herramienta de entregabilidad que te den la usará en sus informes.

Los códigos que realmente te vas a encontrar

Hay docenas en el registro que mantiene la IANA, y aproximadamente una docena en la vida normal. Estos cubren prácticamente cualquier rebote que alguien vaya a leer:

Existen códigos fuera de esta lista, y todos significan algo, pero un código que nunca has visto casi siempre es un .7. — la política de alguien, descrita con sus propias palabras en la línea de al lado.

Qué puede y qué no puede rebotar en una dirección temporal

Casi nada — y merece la pena explicarlo con detalle, porque tres de las cosas que la gente describe aquí como un rebote no lo son:

«Usuario desconocido» no puede darse

El servidor acepta cualquier nombre en sus dominios públicos. anything@grabmail.io es una dirección válida antes incluso de que nadie la haya escrito, porque no hay ninguna lista de buzones contra la que comprobarla — así que un 5.1.1 de GrabMail no es algo que exista. Cómo funciona el correo temporal por dentro tiene el mecanismo completo.

La caducidad no es un rebote

Un mensaje se elimina 5 días después de llegar, y para entonces al servidor emisor ya se le dijo 250 hace tiempo, y ha olvidado todo el intercambio. No se avisa a nadie, porque nada falló: se entregó, y más tarde se eliminó. Cuánto dura un buzón es la guía para esa otra mitad.

Un formulario que rechaza la dirección no es un rebote

No se envió ningún correo en absoluto. El sitio comparó el dominio con una lista y rechazó el formulario; nada llegó nunca a un servidor de correo, y no hay nada que leer. Por qué los formularios de registro bloquean el correo desechable es un problema distinto, con un conjunto de respuestas distinto.

El silencio tampoco es un rebote

Si algo que esperabas nunca llegó y nadie te envió un informe, el fallo — si lo hubo — ocurrió en el lado emisor, donde tú no puedes verlo. El correo que no llega repasa las causas en el orden en que merece la pena comprobarlas.

Eso deja exactamente un rechazo genuino, y es el límite de tamaño. Un servidor emisor que anuncia el tamaño por adelantado es rechazado de inmediato, antes de que se almacene un solo byte:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Un remitente que no anuncia el tamaño recibe en su lugar la misma respuesta al final del mensaje, una vez que ya se han contado los bytes. En cualquier caso el código es 5.3.4, no se almacena nada, y una persona real se entera por su propio sistema de correo — que es exactamente la razón de rechazar en la puerta en lugar de aceptar y descartar.

No hay ningún plan ni ninguna cabecera que eleve el límite, ni rebote por ninguna otra cosa aquí: sin cuota de entrada, sin límite de velocidad, sin rechazo porque alguien ya esté usando ese nombre. En un dominio compartido, dos personas que escriben el mismo nombre simplemente comparten el buzón, lo cual es una propiedad de privacidad, no de entrega.

Rebotes en un dominio que acabas de apuntar aquí

Apuntar un dominio a un buzón catch-all es un solo registro DNS, y casi todos los rebotes que produce pertenecen a la hora alrededor del cambio, no a la configuración en sí. Hay cinco casos, y se distinguen bien entre ellos:

1. Antes de que exista el registro. Un dominio sin MX y sin registro de dirección al que recurrir da a los remitentes 5.4.4 o 5.1.2: no hay dónde entregar, y no vale la pena reintentar nada.
2. Mientras el cambio se propaga. Los remitentes que ya habían consultado el registro conservan la respuesta antigua hasta que se agote su TTL. Un rebote en esta ventana nombra el host antiguo en la línea Remote-MTA:, que es precisamente cómo distinguirlo de un registro que has configurado mal.
3. Una vez propagado. Se acepta cualquier nombre en el dominio, así que «usuario desconocido» también deja de ser posible ahí. Un solo registro, prioridad 10, apuntando a smtp.grabmail.io, y nada más que publicar para que llegue el correo.
4. Si el dominio publicaba antes un MX nulo. Los dominios aparcados suelen llevar el registro que significa «este dominio nunca recibe correo». Los remitentes que lo tenían en caché responden 5.1.10 hasta que caduque, publiques después lo que publiques.
5. Si el dominio también envía correo. Un 5.7.26 en correo saliente no tiene que ver con nada de esto — es tu propio SPF o DMARC, que no cubre lo que sea que envió el mensaje. La guía de solo recepción es el caso estricto; un dominio que también envía necesita en su lugar el despliegue gradual habitual.

Leer el registro responde a casi todo eso antes de que nadie tenga que leer un rebote:

$ dig +short MX yourdomain.com

La respuesta debería ser una sola línea: la prioridad, luego el host, y después un punto final. Cualquier otra cosa — dos líneas, un host desconocido, nada en absoluto — es el rebote que estás a punto de recibir, con tres minutos de antelación. Apuntar aquí tu propio dominio es toda la configuración, y los tres registros que evitan la suplantación es lo que hay que publicar en cuanto empiece a llegar correo.

Un rebote de un mensaje que nunca enviaste

Llega con el aspecto exacto de un informe de fallo corriente, citando un mensaje que nunca has visto, dirigido a un destinatario del que nunca has oído hablar. No se ha vulnerado nada. Alguien envió correo con tu dirección escrita en el sobre como remitente, un servidor receptor lo aceptó antes de descubrir que no podía entregarlo, y luego hizo lo correcto con un mensaje fallido: escribió un informe y se lo envió al remitente que le habían dado. Que eres tú.

El nombre que recibe es backscatter, y merece la pena decir claramente lo que demuestra: nada sobre tu buzón. Falsificar un remitente de sobre no exige acceso a nada — es una sola línea escrita en una conversación. Quien lo hizo solo necesitaba tu dirección y nada más, y es muy posible que la adivinara.

Tres cosas lo distinguen de un rebote real en unos diez segundos:

• El mensaje devuelto no es tuyo. La tercera parte del informe lleva el original, o al menos sus cabeceras. Si nunca lo has escrito, no lo enviaste tú, y todo lo demás en el informe es el problema de otra persona.
• La cadena de Received: empieza en algún sitio que nunca has usado. Léela de abajo hacia arriba: la línea más baja es la máquina que realmente inyectó el mensaje, y no va a ser tu proveedor. Leer una cabecera de correo cubre la dirección de lectura y por qué el final de abajo es el extremo honesto.
• Las fechas no cuadran. El backscatter normalmente informa de un mensaje enviado horas o días antes de que el informe te llegue a ti, salido de una cola que lleva desde entonces reintentando la campaña de otra persona.

No hay nada que arreglar ni nada que responder. Si la dirección pertenece a un dominio tuyo, publicar SPF y DMARC lo reduce de la única forma que funciona: un servidor receptor que comprueba la política del remitente antes de aceptar rechaza la falsificación dentro de la conversación, y nunca genera un informe para nadie. Tres registros en un dominio de solo recepción es la versión más estricta de eso, y con diferencia la más fácil de publicar.

Un nombre corto en un dominio público compartido recibe más de esto que una dirección privada, por la misma razón por la que recibe más spam: es adivinable, y un falsificador que elige remitentes de sobre no te está apuntando a ti en particular. Es ruido sobre otra persona, y a diferencia del spam, aquí no hay ningún botón que entrene nada — qué hacen en realidad los controles contra el spam es la guía de los botones que sí funcionan.

El orden en que hay que leerlo

1. Decide qué tipo tienes delante. Un error en tu propia aplicación de correo justo al pulsar enviar es un rechazo. Un mensaje de MAILER-DAEMON que llega después es un informe, y solo el informe trae algo que leer.
2. Comprueba que se trata de un mensaje que realmente enviaste. La copia devuelta está en la tercera parte. Si no es tuya, es backscatter, y ya has terminado.
3. Abre el código fuente sin procesar. La disculpa de arriba es la frase de serie de tu propio servidor, no el motivo, y el bloque legible por máquina no se muestra por defecto en ningún sitio.
4. Busca Status: y lee el primer dígito. Un 4 todavía se está reintentando y puede que aún funcione por su cuenta; un 5 es definitivo, y no va a pasar nada más.
5. Lee Diagnostic-Code:. Es la frase propia del otro extremo, y el único sitio donde de verdad se nombra la regla que te rechazó.
6. Ubica el segundo dígito. .1. es la dirección, .2. el buzón, .4. la ruta, .7. la política de alguien. Normalmente con eso basta para saber de quién es el problema.
7. Actúa según de quién sea el problema. Un fallo de direccionamiento se arregla teniendo la dirección correcta; uno de enrutamiento, arreglando el DNS; uno de política, cumpliendo la política, o pidiendo a la persona del otro lado que revise sus propios registros — donde el mismo rechazo está escrito con mucho más detalle del que te enviaron a ti.

Dos cosas nunca son la solución. Reenviar el mensaje sin cambios después de un 5 repite el mismo rechazo y, si se hace demasiadas veces, daña la reputación del dominio emisor en todas partes a la vez. Y responder al informe no llega a nadie: vino de un remitente de sobre vacío, que es precisamente la razón por la que pudo llegarte a ti en primer lugar.

Preguntas