El encabezado List-Unsubscribe es vital para la entregabilidad

El botón de baja es un mecanismo de entregabilidad

Cuando un destinatario quiere salir de una lista y el proceso de baja es demasiado complejo — enterrado en el footer, requiere login, pide reseteo de contraseña, lo lleva a un 404 — el suscriptor pulsa el botón de spam en su lugar. Desde la perspectiva del destinatario, "Reportar spam" logra el mismo resultado que "Darse de baja" con un solo tap. Desde la perspectiva del sender, la diferencia es catastrófica.

Una queja de spam se registra como señal de reputación negativa fuerte. Gmail, Yahoo y Microsoft rastrean las tasas de queja como input principal de las decisiones de placement en bandeja de entrada. Crúce 0.3% de tasa de queja en Gmail y su placement cae en cuestión de horas. Manténgalo por encima sostenido y va a pasar semanas reconstruyendo lo que tomó meses ganar. Una baja se registra como nada — el destinatario simplemente sale de la lista.

El header List-Unsubscribe es el mecanismo técnico que permite a los proveedores de buzón ofrecer al destinatario una salida de un solo clic, eliminando la fricción que lo empuja al botón de spam. Es, por amplio margen, el cambio técnico de mayor efecto sobre las tasas de queja — y el cambio que se puede desplegar sin tocar el contenido del email, la audiencia o la frecuencia.

Cómo funciona el header a nivel de protocolo

List-Unsubscribe es un header SMTP definido en el RFC 2369 (publicado en 1998). Lleva una o más URIs que el agente de correo del receptor puede llamar para dar de baja al destinatario. El header soporta dos esquemas URI:

• mailto: — una dirección de correo que, cuando recibe cualquier mensaje, procesa la baja. El cliente de correo envía un mensaje vacío a la dirección; el MTA del sender lo entrega a un script que actualiza la lista de supresión.
• https:// — una URL HTTPS que, al ser llamada, procesa la baja. Con RFC 8058 (añadido en 2017), la llamada es un POST con body List-Unsubscribe=One-Click — ninguna interacción adicional requerida.

El formato espera URIs envueltas en corchetes angulares, separadas por comas cuando ambas están presentes:

Qué hace cada proveedor de buzón importante con el header

La conclusión: incluya siempre los dos — un mailto: y una https:// URL. El mailto: cubre la cola larga de proveedores que no han implementado RFC 8058. El https:// + List-Unsubscribe-Post cubre el requisito de enforcement de Gmail y Yahoo. La combinación es lo que despliegan los senders en producción.

Checklist de implementación

• Genere un token único por destinatario. No use el correo del destinatario como token directamente — eso expone direcciones en headers y crea un problema de privacidad. Use un hash o un identificador respaldado por base de datos.
• Inyecte ambas URIs en el header al construir el mensaje. Formato: List-Unsubscribe: <mailto:...>, <https://...>
• Añada el header List-Unsubscribe-Post. Exactamente: List-Unsubscribe-Post: List-Unsubscribe=One-Click
• El endpoint HTTPS acepta POST. Devuelve 200 OK tras procesar. Sin redirect, sin login, sin página de confirmación. El body contiene List-Unsubscribe=One-Click.
• La dirección mailto: enrutada a un procesador. El MTA entrante recibe correo en la dirección de baja, parsea la parte local para extraer el token, busca al destinatario, lo marca como dado de baja y suprime envíos futuros.
• La supresión hace efecto en cuestión de minutos. Si el job de supresión se ejecuta en batch nocturno, va a seguir enviando hasta 24 horas a gente que ya se dio de baja, y la tasa de quejas se va a disparar. La supresión real-time o casi-real-time es el estándar.
• Parte local de mailto: ≤ 64 octetos. Restricción del RFC 5321. Tokens largos pueden ser rechazados por MTAs estrictos.
• URL HTTPS idealmente < 1,024 caracteres. Sin límite formal pero algunos MTAs intermedios pueden truncar.
• Enlace de baja visible en el cuerpo del email todavía requerido. El header sirve a los proveedores; el enlace en el cuerpo sirve a los destinatarios que usan webmail sin integración de surface. Tanto la CAN-SPAM como el GDPR esperan un mecanismo de baja claro en el contenido.

Implementación específica en PowerMTA

PowerMTA por sí mismo no genera headers List-Unsubscribe. El header tiene que estar presente en el mensaje en el momento de la submission SMTP. Eso significa que la aplicación de email (MailWizz, Acelle, código custom, plataforma de marketing automation) debe inyectarlo.

Para el procesamiento entrante de bajas mailto:, la pipe queue de PowerMTA es el hook correcto. Configure un transport de dominio que pipee el correo destinado a la dirección de baja a un script:

CSE construyó y opera un programa webhook llamado unsubmail que maneja esto punta a punta. Recibe mensajes desde la pipe queue de PowerMTA, parsea la parte local de la dirección mailto: para extraer el token del destinatario, llama al webhook del cliente con un payload limpio de baja, y le confirma el mensaje a PowerMTA. Para nuestros clientes de PMTA gestionado, esto es parte de la configuración estándar. Los clientes auto-gestionados pueden implementar lógica equivalente en cualquier lenguaje de scripting; el surface del protocolo es pequeño.

Para la implementación del endpoint HTTPS, el patrón es aún más simple: un endpoint POST público en su aplicación que acepte el body, valide el token y escriba la baja en su almacén de datos. El endpoint debería devolver 200 dentro de un par de segundos; los proveedores de buzón reintentarán ante timeout, pero lo registran como experiencia degradada.

Cómo se ven el "antes y después" en la práctica

Los senders que añaden un header List-Unsubscribe correctamente formado a un programa previamente no conforme suelen ver bajadas de la tasa de queja del 40–70% en dos semanas. El número exacto depende de la calidad de la lista y del contenido; la mejora direccional es consistente porque está quitando fricción a la gente que iba a salirse de todos modos.

Un patrón concreto de uno de nuestros clientes: una lista B2C de marketing de unos 4 millones de direcciones tenía 0.42% de tasa de quejas en Gmail (por encima del umbral 0.3%, con la consiguiente degradación de placement). Añadieron RFC 8058 con un clic a finales de 2024. En tres semanas la tasa de quejas era 0.14%. El placement de Gmail recuperó baseline en cinco semanas. Sin cambios en contenido, frecuencia o audiencia — solo el header.

El caso opuesto es más dramático. Un sender con List-Unsubscribe configurado pero con el endpoint HTTPS roto (devolviendo 500) fue penalizado más fuerte de lo que habría sido sin el header: Gmail y Yahoo reintentan, y los fallos repetidos se acumulan como señal de calidad contra el sender. El header tiene que funcionar de verdad.

Errores comunes de implementación

• Endpoint HTTPS devuelve redirect 302 a una página de confirmación. Rompe el one-click. RFC 8058 espera que el POST complete la baja en un solo round-trip.
• El endpoint requiere autenticación. El proveedor que hace POST no está autenticado como el destinatario. El token en la URL es la autenticación.
• Pedir confirmación. Las páginas de "¿Está seguro de que quiere darse de baja?" están explícitamente prohibidas por RFC 8058. La acción debe procesarse sin más input del usuario.
• Tokens distintos para mailto: y https://. El mismo destinatario debe ser direccionable por las dos vías. Elija un token canónico por destinatario.
• Header List-Unsubscribe-Post ausente. Sin él, Gmail no va a tratar su URL https:// como endpoint RFC 8058. El header debe ser exactamente List-Unsubscribe-Post: List-Unsubscribe=One-Click — sensible a mayúsculas en el valor.
• Lista de supresión actualizada en batch diario en lugar de real-time. El usuario se da de baja el lunes por la mañana, recibe otra campaña el martes, pulsa spam. Procese las bajas en cuestión de minutos.
• Endpoint HTTPS bloqueado por WAF. Algunos web application firewalls bloquean peticiones sin headers de navegador estándar. El POST de baja no va a parecer una petición de browser. Whiteliste el endpoint.

Más allá del header: higiene de tasa de queja

List-Unsubscribe reduce la fricción al usuario que activamente busca una salida. No aborda las causas upstream que lo hicieron querer salirse. Si las tasas de queja siguen elevadas tras implementar el header correctamente, el problema está en el programa, no en el protocolo:

• Envío a direcciones que no hicieron opt-in explícito.
• Frecuencia que excede lo que el destinatario aceptó.
• Asuntos (subject lines) que tergiversan el contenido.
• Suscriptores inactivos largo tiempo (sin aperturas en 12+ meses) re-engagados a volumen completo.
• Contenido que no concuerda con la marca a la que el destinatario se suscribió.

Para una vista completa de cómo conecta el mecanismo de baja con el trabajo de reputación general del sender, vea nuestros planes de PowerMTA gestionado y la guía de auditoría de entregabilidad, más las notas operativas sobre manejo de bounces y quejas.