# VERP y gestión automática de rebotes: guía técnica > Qué es VERP, cómo codificar el destinatario en el Return-Path, cómo parsear DSN según RFC 3464 y cómo distinguir rebotes de autorespuestas sin errores. Source: https://pidgely.com/es/blog/verp-gestion-de-rebotes/ · Published: 2026-10-12 · Pidgely 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: ```text MAIL FROM: RCPT TO: ``` Hoy es más habitual usar un **token opaco** en lugar de la dirección en claro: ```text MAIL FROM: ``` 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 ```dns 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: ```text From: Mail Delivery System 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 : 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: | Señal | DSN (rebote) | Autorespuesta | |---|---|---| | `Content-Type` | `multipart/report; report-type=delivery-status` | `text/plain` o `multipart/alternative` | | Remitente del sobre | Nulo `<>` | Normalmente no nulo | | `Auto-Submitted` | Puede ser `auto-replied` o ausente | `auto-replied` (RFC 3834) | | Parte `message/delivery-status` | Sí | No | | Headers típicos | — | `X-Autoreply`, `Precedence: auto_reply` | 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: ```text RCPT TO: 550 5.1.1 : 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. ## Preguntas frecuentes ### ¿Qué es VERP? Variable Envelope Return Path: una técnica que pone en el Return-Path de cada mensaje una dirección única que identifica al destinatario y al envío. Así, cualquier rebote se asocia sin ambigüedad a su origen. ### ¿Por qué no basta con parsear el rebote? Porque muchos rebotes no siguen el formato DSN, vienen de reenvíos con otra dirección o están en otro idioma. VERP identifica al destinatario aunque el contenido del rebote sea ilegible. ### ¿Cómo distingo un rebote de una respuesta de fuera de oficina? Los DSN tienen Content-Type multipart/report con report-type=delivery-status y se envían con remitente vacío. Las autorespuestas suelen llevar Auto-Submitted: auto-replied según RFC 3834 y no son fallos de entrega. ### ¿VERP afecta a SPF o DMARC? No, si el dominio del Return-Path tiene su registro SPF y está alineado con el From, por ejemplo usando un subdominio como bounces.example.com.