¿Por qué tu bandeja de entrada se llena de informes de no entrega para campañas que nunca has lanzado? El panel de tu herramienta de emailing muestra cero envíos. Sin embargo, los NDR se acumulan desde el día anterior. Este fenómeno tiene un nombre preciso: el backscatter. Un spammer ha usado tu dominio como dirección de retorno en sus envíos fraudulentos; los servidores que rechazan estos mensajes después te devuelven la factura en forma de rebotes. Nada que ver con un hackeo de tu cuenta ni con una fuga de tu lista de contactos.
El mecanismo del backscatter: From visible y Return-Path, dos direcciones distintas
El cliente de correo muestra un remitente. El comando SMTP MAIL FROM lleva otro, invisible en la interfaz. Esta segunda dirección, el Return-Path, es el destino de los rebotes. Un spammer usurpa este campo técnico, no necesariamente el From visible que ve el destinatario final en su correo. Inscribe tu dominio en el sobre SMTP en el momento del comando MAIL FROM, sin que el cuerpo del mensaje muestre nunca tu nombre. Esa diferencia es la que decide qué ajuste corta el flujo más adelante. El mecanismo completo de la usurpación, desde el From falsificado hasta la suplantación de identidad completa, lo explicamos en nuestro artículo sobre cómo funciona el email spoofing. Aquí, el objetivo es más concreto: el sobre técnico, el que el protocolo usa para enrutar los informes de error, distinto del mensaje que realmente lee el destinatario final.
Por qué el servidor del destinatario te devuelve el rebote a ti
Porque envía el informe de error a la dirección inscrita en el sobre. Esa dirección lleva tu dominio. Ningún elemento del protocolo le permite saber que ha sido falsificada. En detalle, existen dos comportamientos en un servidor que recibe un correo fraudulento. El primero rechaza la conexión en directo, durante la transacción SMTP, con un código de error inmediato; nunca se genera ningún rebote, el problema se detiene en seco del lado del servidor emisor del spam. El segundo acepta el mensaje. Lo descubre demasiado tarde: el buzón está lleno o el destinatario no existe. Es este segundo caso el que produce el backscatter: el servidor genera un NDR (Non-Delivery Report), con el formato definido por la RFC 3464 (IETF, 2003), y luego lo envía de buena fe al Return-Path usurpado.
Un investigador que recibió 49.000 mensajes de backscatter en cuatro meses pasó sus rebotes por el filtro de cuatro listas negras: de 4177 rebotes cuya IP emisora era identificable, el 19% de esas IP aún no figuraban en ellas, SpamCop señalando el 73% y CBL el 69% (Christopher Fuhrman, École de technologie supérieure de Montréal, 2008).
Esta vieja constatación sigue vigente. Los servidores mal configurados que aceptan y luego rechazan, en lugar de rechazar en la entrada, forman un parque residual que sigue funcionando, a menudo mensajerías de empresa administradas por equipos que ya no siguen las recomendaciones SMTP habituales. La tipología completa de los distintos motivos de correos no entregados la tratamos aparte. El backscatter es un caso particular dentro de ella, generado por un tercero y sin relación con tu propio envío.
Leer las cabeceras del bounce para confirmar que el envío no viene de ti
Llega un rebote sospechoso. Tres verificaciones suelen bastar para decidir, en este orden:
- La cadena Received, en la parte superior del mensaje sin procesar, lista cada servidor atravesado del primero al último. Si ninguno de ellos corresponde a tu infraestructura de envío habitual (IP, MTA, plataforma de emailing identificada), el origen es externo.
- El Message-ID del mensaje original, generalmente incluido en el cuerpo del bounce como cita parcial. Un Message-ID que tus propios logs de envío nunca generaron confirma que el mensaje jamás salió de tu lado.
- El Enhanced Status Code del informe, en formato 5.x.x, precisa la causa exacta del rechazo del lado del servidor destinatario: buzón inexistente o cuota superada.
Un bounce de backscatter se reconoce por la ausencia total de correspondencia entre su Message-ID y los registros de envío del remitente legítimo, sea cual sea la plataforma de envío utilizada, Twilio SendGrid, Mailjet o un SMTP propio. Sin esa correspondencia, no hace falta ninguna investigación adicional.
Lo que esto no significa: ni hackeo, ni fuga de lista
La primera reacción, al descubrir decenas de NDR desconocidos, suele inclinarse hacia la hipótesis de la cuenta comprometida. Es comprensible. Pero un backscatter no supone ningún acceso al dominio ni al buzón de correo, ninguna fuga de base de contactos, ninguna vulneración de la herramienta de emailing. El spammer solo necesita una información pública, tu nombre de dominio, para inscribirla en el sobre de un envío que nunca implica tus servidores. También podría pensarse que un ESP basta para cubrir este riesgo, ya que gestiona la autenticación de los envíos salientes. Sin embargo, SPF y DMARC se declaran a nivel del DNS del dominio, no a nivel de la herramienta de envío: cambiar de ESP no cierra nada mientras esos registros sigan ausentes o sean permisivos.
Después surge sistemáticamente otra preocupación: ¿este flujo hará que me bloqueen? Backscatterer.org, la lista negra dedicada a este fenómeno, registra los servidores que emiten backscatter, nunca los dominios usurpados que lo reciben. Se entra en ella al reenviar rebotes hacia terceros inocentes. Recibir miles de ellos no cambia nada.
Lo que realmente se puede hacer: publicar un SPF en hard fail
Un registro SPF publicado en -all es el único ajuste que actúa sobre la fuente del backscatter. Este hard fail pide al servidor receptor que rechace, durante la transacción SMTP, cualquier mensaje que inscriba tu dominio en MAIL FROM sin provenir de tus servidores autorizados. El mensaje muere en la puerta, no se genera ningún NDR, nada vuelve hacia ti. Detallamos la sintaxis completa en nuestro artículo sobre qué pasa cuando el SPF está ausente. La trampa del exceso de consultas la explicamos en esta guía sobre el límite de las 10 búsquedas DNS. Lo que ninguna configuración logrará, en cambio: impedir que un spammer escriba tu dominio en un sobre o forzar a un servidor de terceros mal configurado a respetar SPF.
DMARC interviene en otro plano. El matiz decide lo que puedes esperar de él aquí. Una política en p=quarantine o p=reject se evalúa sobre el dominio del campo From de cabecera, el que ve el destinatario, tras verificar que una firma DKIM o un control SPF autentican bien ese dominio. Es la regla de alineación. Cuando el spammer se limita a usurpar el sobre y firma su mensaje con un From ajeno a tu dominio, el servidor receptor nunca consulta tu política DMARC. Protege tu marca contra la usurpación visible, pero no corta por sí sola los rebotes extraviados: ese papel corresponde a SPF, y DMARC toma el relevo en cuanto el spammer usurpa también el From mostrado.
Del lado de la recepción, BATV (Bounce Address Tag Validation) ataca el problema de raíz. Tu servidor firma la dirección de retorno de cada envío saliente con un token fechado, y luego rechaza cualquier NDR dirigido a una dirección no firmada. Un backscatter no puede llevar ese token, ya que responde a un sobre que tú nunca emitiste. Vigilar los informes agregados DMARC (rua) da además una imagen del volumen y del origen de la usurpación, sin llegar nunca a detenerla en la fuente, con la misma salvedad que antes: esos informes solo reportan los mensajes que llevan tu dominio en el From de cabecera. Una usurpación limitada al sobre no aparecerá ahí. Explicamos la lectura de estos archivos XML a fondo en nuestra guía para leer un informe DMARC agregado.
Este endurecimiento tiene un límite. Un SPF hard fail no hace callar a los servidores que ignoran la política, que no han actualizado su resolutor o que aplican una evaluación parcial de los registros DNS. Ese residuo sigue produciendo rebotes extraviados, incluso después de un despliegue correcto del lado del dominio. El -all tiene además un coste colateral que conviene conocer: un mensaje legítimo reenviado por un alias o un buzón de reenvío falla el control SPF en el destinatario final, ya que la IP que presenta el mensaje ya no es la tuya. Los servidores de redirección bien gestionados reescriben el sobre mediante SRS para evitarlo; los demás romperán tus reenvíos.
Comprobar que tu propio servidor no genera backscatter
El razonamiento se invierte. Esta mitad del asunto casi siempre se pasa por alto. Un servidor que acepta todo y luego devuelve un NDR fabrica exactamente el ruido descrito más arriba, en casa de otro. Los ajustes que producen este comportamiento son conocidos:
- una dirección catch-all que absorbe cualquier destinatario antes de descubrir que el buzón no existe;
- un autorespondedor de ausencia que responde mecánicamente a un sobre usurpado;
- una pasarela antispam que filtra tras la aceptación, en lugar de rechazar durante la transacción SMTP.
La solución se resume en una regla: validar la existencia del destinatario en el momento del RCPT TO y rechazar ahí, con un código 5.x.x, en lugar de aceptar y luego disculparse. Es lo que separa a un servidor que protege a los demás de un servidor que acaba en Backscatterer.org.
No confundir backscatter con una lista realmente sucia
Un pico repentino de rebotes en las estadísticas de envío se parece, a primera vista, a un deterioro de la sender reputation. La mayoría de las veces no es así, si los rebotes corresponden a campañas nunca lanzadas. La confusión sale cara cuando lleva a purgar una lista de contactos basándose en una señal que no proviene de ella: los errores de entrega reportados por Google Postmaster Tools, al igual que los contadores de hard bounce de tu plataforma de envío, permanecen sordos ante los backscatter que nunca pasaron por tus propias campañas, ya que ningún envío real los desencadenó. Antes de concluir que hay una list hygiene deficiente basándote en un flujo de NDR, comprueba mediante las cabeceras descritas más arriba si esos rebotes corresponden a un envío real o a un sobre usurpado: limpiar la lista de contactos no solucionará nada si el problema viene de otro lado.
La adopción de DMARC avanza, impulsada por las reglas impuestas a los grandes remitentes por Google y Yahoo desde febrero de 2024, que exigen como mínimo una política publicada en p=none. La revisión del estándar publicada en 2026 bajo el nombre de DMARCbis (RFC 9989) no eleva ese umbral: reformula el protocolo y sustituye la lista de sufijos públicos por una remontada de árbol DNS, sin imponer una política estricta a nadie. El parque residual de mensajerías mal configuradas, por su parte, sigue un calendario mucho más lento, el de las actualizaciones DNS que nadie ha planificado.
