La cabecera List-Unsubscribe existe desde los años 2000, pero se convirtió en un requisito técnico ineludible cuando Gmail y Yahoo empezaron a exigirla, en 2024, a todo remitente de gran volumen. Sin ella, un dominio de envío comercial puede acabar directamente en la carpeta de spam sin importar lo sólida que sea su autenticación SPF, DKIM y DMARC.
Por qué esta cabecera se volvió obligatoria
Un remitente se convierte en «bulk sender» para Gmail en cuanto envía alrededor de 5000 mensajes o más a cuentas personales de Gmail en un periodo de 24 horas. Ese estatus, una vez alcanzado, no desaparece aunque el volumen baje después. Yahoo aplica un umbral comparable. Ambos proveedores exigen entonces, para los mensajes promocionales y de marketing, un mecanismo de baja que funcione realmente en un clic, sin página de confirmación, sin formulario y sin necesidad de iniciar sesión.
Este mecanismo es independiente de la autenticación descrita en la guía sobre SPF, DKIM y DMARC: una dirección perfectamente autenticada pero sin una baja conforme sigue expuesta a una tasa de quejas elevada, una de las causas documentadas de llegar a spam.
Cómo funciona la RFC 8058
La RFC 8058 define dos cabeceras complementarias. List-Unsubscribe transporta la URI de baja, idealmente en HTTPS. List-Unsubscribe-Post indica al cliente de correo que puede activar la acción con una simple petición POST, sin abrir ninguna página:
List-Unsubscribe: <https://ejemplo.com/baja?token=abc123>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickCuando el cliente de correo detecta ambas cabeceras juntas, muestra un botón nativo «Cancelar suscripción» junto al remitente y, al pulsarlo, envía una petición POST directamente al servidor, sin cargar nunca una página en un navegador. Esa automatización es lo que distingue la baja en un clic real de un simple enlace de baja colocado en el pie del correo.
Implementar la cabecera en el servidor
La mayoría de las bibliotecas de envío transaccional ofrecen un método para añadir cabeceras personalizadas. Aquí un ejemplo con Symfony Mailer, habitual entre equipos que gestionan su propia infraestructura de envío en lugar de delegarlo todo a un proveedor externo:
use Symfony\Component\Mime\Email;
$email = (new Email())
->from('[email protected]')
->to($destinatario)
->subject('El boletín del mes')
->html($cuerpoHtml);
$headers = $email->getHeaders();
$headers->addTextHeader(
'List-Unsubscribe',
', '
);
$headers->addTextHeader('List-Unsubscribe-Post', 'List-Unsubscribe=One-Click');
$mailer->send($email); El detalle técnico que más falla: la URL referenciada por List-Unsubscribe debe tratar la petición POST como una baja inmediata y definitiva, sin redirigir a una página de confirmación. Una ruta que muestra «¿Seguro que quieres darte de baja?» rompe el cumplimiento del one-click, aunque la cabecera esté presente y sea sintácticamente correcta.
Lo que ofrecen las plataformas de envío
| Plataforma | Soporte nativo de la RFC 8058 | Configuración del lado del cliente |
|---|---|---|
| SendGrid | Sí, mediante grupos de baja | Se activa en los ajustes de supresión, cabeceras añadidas automáticamente |
| Mailgun | Sí | Activación por dominio desde el panel o la API |
| Postmark | Sí, en el flujo Broadcast | Enlace y cabecera POST generados automáticamente |
| Brevo | Sí | Enlace de baja nativo, cabecera añadida por defecto en las campañas |
| Envío propio (Symfony Mailer, PHPMailer) | No por defecto | Hay que programarlo manualmente, como se muestra arriba |
Los umbrales que conviene conocer por proveedor
| Exigencia | Gmail | Yahoo |
|---|---|---|
| Umbral de volumen que activa las reglas | ~5000 mensajes/24h a cuentas personales | Umbral comparable |
| Autenticación | SPF y DKIM obligatorios, DMARC mínimo p=none con alineación | Exigencias equivalentes |
| Baja en un clic | RFC 8058 obligatoria | Cabecera List-Unsubscribe obligatoria, RFC 8058 muy recomendada |
| Plazo de procesamiento | 48 horas como máximo | 48 horas como máximo |
| Tasa de quejas de spam | Objetivo por debajo del 0,1 %, umbral crítico en 0,3 % | Umbral similar bajo vigilancia |
Desde 2024, Gmail y Yahoo exigen una baja en un clic a todo remitente que supere los 5000 mensajes diarios hacia sus dominios, con un plazo de procesamiento limitado a 48 horas.
Errores frecuentes que invalidan el cumplimiento one-click
La especificación cabe en pocas líneas, pero su implementación concentra un número desproporcionado de errores recurrentes, a menudo invisibles hasta que algún proveedor los penaliza explícitamente.
El primero afecta a la propia ruta: algunos frameworks aplican por defecto protección CSRF a todos los endpoints POST, incluido el de baja. El cliente de correo no dispone de cookie de sesión ni de token CSRF que presentar, así que la petición falla silenciosamente y el usuario sigue suscrito sin que nadie del lado del remitente lo note. La ruta de baja debe excluirse explícitamente de ese control, apoyándose en cambio en el propio token de la URL para autenticar la solicitud.
El segundo error consiste en responder con un código de estado inesperado. Algunos clientes de correo consideran que cualquier código distinto de 200 o 202 indica un fallo, y reintentan la operación o la abandonan directamente. Una ruta que redirige con un 302 a una página de agradecimiento, por inofensiva que parezca a un visitante humano, se sale del comportamiento que espera la RFC.
El tercero, más sutil, tiene que ver con el retraso de propagación interna: la cabecera puede apuntar a una ruta perfectamente funcional, pero si la baja solo se refleja en la base de envío tras un procesamiento diferido de varias horas, un envío programado mientras tanto vuelve a llegar a una dirección que se creía dada de baja. Las 48 horas que conceden Gmail y Yahoo para atender la solicitud cubren el procesamiento, no una cola paralela que lo ignora.
Por último, la dirección de la cabecera From debe mantenerse coherente con el dominio de autenticación y con el dominio de la ruta de baja. Un envío realizado desde una plataforma externa con un dominio de seguimiento distinto del usado para la alineación DMARC puede, en algunos casos, debilitar la lectura de la cabecera por parte del cliente de correo, sobre todo cuando conviven varios subdominios sin una configuración coherente.
Verificar la implementación antes de enviar a gran escala
Un envío de prueba basta para confirmar la presencia sintáctica de las cabeceras: la mayoría de los webmails muestran la opción de baja nativa en cuanto la detectan bien formada. Las herramientas gratuitas de análisis de entregabilidad, como mail-tester, incluyen también una comprobación específica sobre la presencia y validez de List-Unsubscribe. Queda además necesario probar la propia ruta de baja: una petición POST enviada manualmente a la URL declarada debe dar de baja la dirección sin redirección ni página intermedia, tal como lo haría un cliente de correo.
Esta comprobación técnica complementa las revisiones de renderizado ya tratadas en la guía sobre el comportamiento del HTML en los clientes de correo, donde la incoherencia entre remitentes de prueba explica buena parte de las sorpresas en producción.
Lo esencial
La cabecera List-Unsubscribe ya no es una opción de cortesía, sino una condición de entrada a la bandeja de entrada en cuanto el volumen de envío supera unos pocos miles de mensajes diarios. Su implementación técnica es sencilla, dos líneas de cabecera y una ruta de servidor, pero el error más frecuente sigue siendo hacerla pasar por un formulario de confirmación que invalida la promesa del one-click.
Este tipo de detalle técnico, dos cabeceras y una ruta sin redirección, hace perder un tiempo desproporcionado a equipos convencidos de tener un problema de contenido o de reputación de IP, cuando en realidad su baja lleva meses redirigiendo silenciosamente a una página de confirmación. Antes de sospechar de la reputación del dominio, siempre conviene revisar primero esas dos líneas de cabecera — Simon Janvier.
Para saber más
Fuente: Google, «Email sender guidelines FAQ», documentación oficial de Gmail para remitentes.
