VERP y gestión automática de rebotes: guía técnica

VERP (Variable Envelope Return Path) consiste en usar una dirección de Return-Path única por mensaje y destinatario, como b-7f3a9c@bounces.example.com, para que cualquier rebote que vuelva identifique exactamente a quién y qué envío corresponde. Combinado con el parseo de DSN según RFC 3464, permite automatizar la gestión de rebotes de forma fiable: suprimir direcciones inválidas, contar fallos temporales y descartar autorespuestas que no son rebotes.

El problema: los rebotes son caóticos

Cuando un servidor no puede entregar un mensaje que ya aceptó, envía una notificación al Return-Path (la dirección del MAIL FROM del sobre). En teoría esa notificación es un DSN estructurado. En la práctica encontrarás:

• DSN correctos con multipart/report.
• Mensajes en texto libre, en cualquier idioma, sin estructura.
• Rebotes de servidores intermedios que mencionan una dirección distinta a la que tú enviaste, porque el usuario tenía un reenvío configurado (ana@example.es → ana.lopez@example.net).
• Rebotes que no incluyen el mensaje original.

Si tu Return-Path es fijo (bounces@example.com), tienes que adivinar a quién se refiere cada rebote leyendo el contenido. Con VERP no necesitas adivinar.

Cómo funciona VERP

La forma clásica, propuesta por D. J. Bernstein, codifica la dirección del destinatario en el local-part:

MAIL FROM:<bounces+ana=example.es@bounces.example.com>
RCPT TO:<ana@example.es>

Hoy es más habitual usar un token opaco en lugar de la dirección en claro:

MAIL FROM:<b-01HZX4K7Q2.f3a9@bounces.example.com>

El token apunta a un registro interno: ID del mensaje, destinatario, cuenta, stream. Ventajas del token frente a la dirección en claro:

• No expone datos personales en el sobre.
• Admite verificación: añade un HMAC corto para rechazar rebotes falsificados.
• Evita problemas de caracteres en direcciones con símbolos poco habituales.
• Cabe holgadamente en el límite de 64 caracteres del local-part (RFC 5321).

El servidor MX de bounces.example.com acepta cualquier local-part con el prefijo esperado, extrae el token, lo valida y asocia el rebote al envío original.

DNS necesario

bounces.example.com.  IN MX   10 mx-bounces.example.com.
bounces.example.com.  IN TXT  "v=spf1 ip4:203.0.113.0/28 -all"

Como el dominio del Return-Path es un subdominio de example.com, SPF queda alineado con DMARC en modo relajado.

Anatomía de un DSN (RFC 3464)

Un DSN bien formado es un mensaje multipart/report (RFC 6522) con tres partes:

From: Mail Delivery System <MAILER-DAEMON@mx.example.es>
To: b-01HZX4K7Q2.f3a9@bounces.example.com
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
    boundary="XYZ"

--XYZ
Content-Type: text/plain; charset=utf-8

No se pudo entregar su mensaje a ana@example.es.

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

Reporting-MTA: dns; mx.example.es
Arrival-Date: Mon, 12 Oct 2026 10:15:02 +0200

Final-Recipient: rfc822; ana@example.es
Original-Recipient: rfc822; ana@example.es
Action: failed
Status: 5.1.1
Remote-MTA: dns; buzones.example.es
Diagnostic-Code: smtp; 550 5.1.1 <ana@example.es>: User unknown

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

Message-ID: <01HZX4K7Q2@example.com>
...
--XYZ--

Campos clave por destinatario:

• Action: failed (definitivo), delayed (sigue en cola), delivered, relayed o expanded. Solo failed cuenta como rebote.
• Status: enhanced status code (RFC 3463), como 5.1.1 o 4.2.2.
• Diagnostic-Code: la respuesta SMTP original, si existe.
• Final-Recipient: puede no coincidir con tu destinatario si hubo reenvío. Por eso VERP es más fiable que este campo.

Los DSN se envían con remitente nulo (MAIL FROM:<>), para que un DSN que falle no genere otro DSN en bucle.

Rebotes vs autorespuestas

Tu buzón de rebotes recibirá también mensajes que no son fallos de entrega:

• Respuestas de fuera de oficina y vacaciones.
• Sistemas de desafío-respuesta ("confirme que es humano").
• Acuses de recibo de sistemas de tickets.
• Respuestas humanas de usuarios que contestan a lo que creen que es la dirección del remitente.

RFC 3834 recomienda que las respuestas automáticas se envíen al Return-Path, así que llegan a tu infraestructura de rebotes. Cómo distinguirlas:

Un orden de clasificación robusto:

1. ¿Tiene una parte message/delivery-status? → Parsear como DSN.
2. ¿Es un ARF (report-type=feedback-report)? → Es una queja, no un rebote.
3. ¿Tiene Auto-Submitted: auto-replied o headers de autorespuesta? → Autorespuesta: registrar, no suprimir.
4. ¿Remitente nulo y texto con patrones de fallo conocidos? → Rebote no estándar: clasificar con heurísticas y con más cautela.
5. Resto → Respuesta humana o desconocido: no suprimir.

Rebotes síncronos: la otra mitad

VERP resuelve los rebotes asíncronos. Pero muchos rechazos ocurren durante la sesión SMTP, y tu MTA los recibe en el momento:

RCPT TO:<ana@example.es>
550 5.1.1 <ana@example.es>: Recipient address rejected: User unknown

Tu sistema debe tratar ambos caminos con la misma lógica de clasificación, para que un 5.1.1 síncrono y un Status: 5.1.1 en un DSN produzcan la misma supresión.

Backscatter y rebotes falsificados

Si tu MX de rebotes acepta cualquier mensaje, alguien puede enviarte DSN falsos para suprimir direcciones legítimas. Defensas:

• Token con HMAC en el local-part, verificado antes de procesar.
• Caducidad del token: un rebote de un mensaje enviado hace meses es sospechoso.
• Rechazar en SMTP los local-parts inválidos, en vez de aceptarlos y descartarlos.

Errores comunes

• Return-Path fijo y parseo del contenido para adivinar el destinatario.
• Suprimir con Action: delayed, que solo es un aviso.
• Tratar las autorespuestas como rebotes, suprimiendo a usuarios que estaban de vacaciones.
• Return-Path en un dominio sin SPF o no alineado, que rompe DMARC por la vía SPF.
• No procesar los rebotes síncronos con la misma lógica que los DSN.
• Aceptar tokens sin verificar.

Checklist

• [ ] Subdominio de return-path con MX y SPF propios.
• [ ] Token VERP opaco con HMAC por mensaje y destinatario.
• [ ] Parser de multipart/report con message/delivery-status.
• [ ] Separación de DSN, ARF, autorespuestas y respuestas humanas.
• [ ] Misma clasificación para rebotes síncronos y asíncronos.
• [ ] Supresión basada en Action: failed y enhanced status code.

En Pidgely

Pidgely usa VERP con tokens firmados en un subdominio de return-path alineado, parsea DSN según RFC 3464, separa las autorespuestas y unifica la clasificación de rebotes síncronos y asíncronos antes de actualizar la lista de supresión.