List-Unsubscribe y RFC 8058: cómo implementar baja con un clic en cold email

List-Unsubscribe es un encabezado definido para que el cliente de correo conozca una ruta de baja sin tener que interpretar el diseño del mensaje. RFC 2369 permite incluir URLs entre ángulos, normalmente mailto y HTTP o HTTPS. RFC 8058 añade una señal específica para que el receptor complete una baja mediante un POST con consentimiento del usuario.

La distinción importa. Un enlace visible en el cuerpo ayuda a la persona; el header permite que Gmail, Yahoo u otro cliente muestre su propia interfaz. Un List-Unsubscribe con mailto no es lo mismo que one-click por RFC 8058. Y una URL que abre una página para pedir cinco datos tampoco completa una baja automática.

El objetivo no es adornar el source del email. Es ofrecer una salida fiable antes de que la alternativa sea marcar spam. Una implementación útil conecta el gesto del receptor con la misma lista de supresión que consultan todos los remitentes, campañas y secuenciadores.

Google exige a remitentes que envían más de 5,000 mensajes diarios a cuentas Gmail que sus mensajes de marketing y suscripción soporten baja con un clic y tengan además un enlace visible en el cuerpo. Yahoo publica un requisito comparable para bulk senders de marketing y suscripción, recomienda el método POST de RFC 8058 y pide atender las bajas dentro de dos días.

Esas páginas no dicen que cualquier cold email B2B, sin importar volumen y clasificación, quede automáticamente dentro de la misma categoría. Tampoco sustituyen legislación, contrato con el proveedor ni reglas de cada jurisdicción. Clasifica cada flujo con asesoría adecuada y no uses una interpretación estrecha como excusa para construir una salida defectuosa.

La recomendación operativa de picos.Ai es más simple: cualquier campaña debe tener un opt-out visible, funcional y rápido; si el flujo y la plataforma están dentro del alcance de one-click, implementa RFC 8058 completo. Una baja voluntaria es información que el sistema debe respetar, no una negociación sobre qué documento tarda más en obligarte.

La pareja mínima es exacta. Primer header: List-Unsubscribe: <https://mail.example.com/u/token-opaco>. Segundo header: List-Unsubscribe-Post: List-Unsubscribe=One-Click. La URL HTTPS debe identificar al destinatario y la lista sin necesitar parámetros adicionales en el cuerpo del POST.

RFC 8058 permite que List-Unsubscribe incluya también otra URI, como mailto, pero exige al menos una HTTPS para one-click. El receptor realiza un POST a esa URL y envía como cuerpo List-Unsubscribe=One-Click. El endpoint no debe depender de una sesión previa, porque la solicitud no trae contexto del navegador del usuario.

No inventes variantes del valor, no pongas la URL sin ángulos y no asumas que el header del proveedor equivale a la versión entregada. Gateways, plataformas y firmas pueden modificar el mensaje. La prueba válida empieza en el source recibido por una cuenta controlada.

La URL necesita un token opaco y difícil de falsificar que permita resolver destinatario, lista o tenant. No incluyas el email en texto claro si puedes evitarlo. Firma o cifra el token, limita su propósito y valida integridad en el servidor. El endpoint debe procesar el POST sin pedir login, password, cookies ni confirmación adicional.

RFC 8058 indica que el servidor no debe devolver un redirect HTTPS, porque los POST redirigidos han tenido comportamiento inconsistente. Responde directamente. La operación también debe ser idempotente: si Gmail, Yahoo o una prueba repite la misma solicitud, el contacto queda suprimido una vez y las respuestas posteriores no reactivan nada ni producen errores peligrosos.

Registra el evento con timestamp, token o identificador derivado, lista, campaña cuando exista, fuente one_click y resultado. Evita logs con la URL completa si el token funciona como credencial. La observabilidad debe ayudar a auditar una baja sin convertir el archivo de logs en un catálogo de enlaces reutilizables.

RFC 8058 exige una firma DKIM válida que cubra List-Unsubscribe y List-Unsubscribe-Post. En el header DKIM-Signature, ambos nombres deben aparecer dentro del parámetro h=. La razón es evitar que otra parte inserte o cambie la instrucción y provoque bajas contra un endpoint que el remitente no autorizó.

Un resultado dkim=pass no demuestra por sí solo que esos headers estén firmados. Descarga el original, localiza DKIM-Signature y revisa h=. Si hay varias firmas, identifica cuál valida y cuál cubre los campos. Después confirma en Authentication-Results el dominio firmante y la alineación que espera tu política DMARC.

Haz esta revisión por proveedor y ruta. Google Workspace, Microsoft 365, Instantly, Smartlead u otro sender pueden construir o firmar mensajes en etapas diferentes. Si la plataforma agrega List-Unsubscribe después de la firma que debía cubrirlo, el correo puede autenticar y aun no cumplir la condición específica de RFC 8058.

El endpoint no termina cuando devuelve 200. Debe escribir una supresión durable antes de que otro worker seleccione al contacto. La entidad mínima incluye email normalizado o contact_id, alcance, motivo, source, created_at y evidencia del evento. Define si la baja afecta una lista, una marca o toda la organización según expectativa, política y contexto legal.

Después propaga el estado a Clay, Instantly, Smartlead, CRM y cualquier cola propia. La mejor arquitectura mantiene una fuente central y obliga a cada envío a consultar o recibir esa supresión. Copiar opt-outs cada noche deja una ventana donde dos campañas pueden seguir contactando a la misma persona.

Diseña para carreras. Un POST puede llegar mientras un mensaje ya está en cola. El worker debe volver a verificar supresión inmediatamente antes de enviar, no solamente cuando el lead entró a la secuencia. Una interfaz que dice baja completada mientras otro job conserva permiso es una promesa visual sin control operativo.

No asumas que activar una opción llamada unsubscribe resuelve las cuatro capas. Pregunta si agrega List-Unsubscribe, si agrega List-Unsubscribe-Post, qué URL usa, quién hospeda el endpoint y si la firma DKIM cubre ambos headers. Después revisa cómo se exporta el evento y con qué latencia llega a la supresión global.

Confirma también el alcance. Una plataforma puede detener una campaña, un workspace o un buzón, pero otra herramienta todavía podría enviar al mismo contacto. Prueba duplicados entre campañas y aliases. Verifica qué ocurre si el email usa mayúsculas, plus addressing, un contacto duplicado o un cambio de owner.

Si el proveedor no permite controlar o inspeccionar el endpoint, conserva evidencia de pruebas reales y conecta su evento de baja al sistema central mediante webhook o sincronización segura. Si ni siquiera expone un evento confiable, no compensas el hueco añadiendo otro link al footer; necesitas cambiar la arquitectura o el proveedor.

Crea contactos de prueba autorizados en Gmail, Yahoo y otros receptores relevantes. Envía desde cada combinación de dominio, buzón y plataforma. Descarga el original y comprueba ambos headers, URL HTTPS, DKIM h=, dkim=pass y dominio esperado. Guarda una muestra redactada como evidencia de la versión probada.

Activa la baja desde la interfaz del cliente cuando aparezca. Confirma que el endpoint recibió POST, que el registro central cambió, que todas las herramientas dejaron de considerar elegible al contacto y que un job nuevo queda bloqueado. Repite la misma solicitud para validar idempotencia y comprueba que no exige cookies, autenticación ni redirect.

Prueba fallas de manera controlada: token inválido, token ya usado, webhook repetido, CRM caído y sender con cola existente. Define si el endpoint responde después de la escritura central y cómo reintenta integraciones secundarias. La regla segura es aceptar la baja una vez y reconciliar sistemas; nunca volver a habilitar al contacto porque una plataforma estuvo temporalmente fuera de servicio.

El primer error es enviar solo List-Unsubscribe con mailto y llamarlo RFC 8058. El segundo es omitir List-Unsubscribe-Post. El tercero es usar una URL HTTPS que redirige a login o preferencia. El cuarto es firmar el mensaje con DKIM sin incluir ambos headers dentro de h=.

También aparecen fallas menos visibles: token con email expuesto, endpoint que cambia solo una campaña, supresión que sincroniza horas después, POST no idempotente, URL de staging, certificado roto o link visible que termina en una página distinta al header. Cada una rompe una parte distinta de la promesa.

Por último, no uses one-click como argumento de deliverability garantizada. Facilitar la salida puede reducir fricción y evita obligar al destinatario a buscar alternativas, pero no corrige mala selección, volumen, reputación, autenticación o copy engañoso. Es infraestructura de respeto y control, no un pase VIP a la bandeja principal.

List-Unsubscribe y RFC 8058 resuelven el protocolo entre receptor y endpoint. La operación real continúa en la base de supresión, los secuenciadores, el CRM y cada worker que puede enviar. Diseñar únicamente el header es como instalar un botón de emergencia que no está conectado a la máquina.

picos.Ai audita el flujo completo: mensaje recibido, headers, cobertura DKIM, token, POST, registro durable, propagación, carreras y prueba de no envío. También separa los requisitos publicados por Gmail y Yahoo de las decisiones internas y de las obligaciones legales que deben revisar especialistas en cada jurisdicción.

Si hoy no puedes demostrar qué ocurre después de que alguien pulsa unsubscribe, usa el enlace Hablemos al final de esta página. Podemos probar una cohorte controlada y dejar evidencia por dominio y plataforma. La meta no es mostrar la palabra unsubscribe; es conseguir que una decisión de salida sobreviva a todo el stack.