Infraestructura de email
Desuscripción en un clic, la cabecera que de verdad cuenta.
El requisito de remitente masivo más infra-implementado no es el enlace de baja del pie — es la cabecera List-Unsubscribe-Post que Gmail y Yahoo buscan específicamente. El un clic de RFC 8058 necesita dos cabeceras (List-Unsubscribe con un URI HTTPS, y List-Unsubscribe-Post con el valor exacto List-Unsubscribe=One-Click), ambas firmadas con DKIM, más un endpoint HTTPS que complete la baja en POST y devuelva 200 — sin login, sin redirección, sin página de confirmación. Hazlo bien y reduces las quejas de spam; hazlo mal y los escáneres de enlaces pueden dar de baja a tu gente por ti.
En breve
- El enlace del pie no basta. El correo promocional masivo necesita el un clic basado en cabecera, no solo un enlace en el cuerpo.
- Dos cabeceras, ambas firmadas con DKIM. List-Unsubscribe (URI HTTPS) más List-Unsubscribe-Post con el valor exacto List-Unsubscribe=One-Click.
- Solo POST, nunca GET. Da de baja en POST y devuelve 200; una baja por GET deja que los escáneres den de baja a la gente por accidente.
- Sin redirección, sin página de preferencias. El endpoint debe completar la baja él mismo, dentro de 48 horas.
- Solo promocional. El correo transaccional — restablecimientos, recibos, confirmaciones — está exento.
¿Por qué ya no basta con el enlace de baja del pie?
Durante años el enlace de baja al final del correo era toda la historia. Desde que Gmail y Yahoo empezaron a aplicar las reglas de remitente masivo en 2024, es solo la mitad. Los proveedores esperan ahora un mecanismo de un clic basado en cabecera que su propia interfaz pueda disparar — un botón nativo de Cancelar suscripción junto a tu nombre de remitente que completa la baja sin enviar al destinatario a una página externa. El enlace del pie sigue siendo obligatorio, por la ley antispam y por los proveedores, pero por sí solo ya no cumple el requisito para el correo promocional.
El razonamiento es de comportamiento, y es el sentido entero del estándar. Cuando salir de una lista es de verdad un clic, los destinatarios lo usan; cuando está enterrado o es incómodo, su alternativa es pulsar Marcar como spam. Los proveedores de buzón saben que los usuarios no distinguen entre darse de baja y marcar como basura, así que premian a los remitentes que hacen la salida sin fricción. Una salida limpia de un clic que no cuenta como queja de spam es, en la práctica, una palanca directa sobre la tasa de quejas que decide tu entregabilidad.
Por eso esta única cabecera pesa tanto en relación con su tamaño. Los datos de referencia nombran una y otra vez la cabecera List-Unsubscribe-Post como el requisito de remitente masivo más infra-implementado: los equipos añaden un enlace visible en el pie, ven una opción de baja en su propio correo y dan por hecho que cumplen — mientras omiten la única cabecera que Gmail comprueba de verdad. La brecha es pequeña de arreglar y cara de ignorar, porque desde finales de 2025 omitirla puede pasarte de la entrega diferida al rechazo directo.
¿Qué son exactamente las dos cabeceras?
El un clic es un par de cabeceras que trabajan juntas, definidas por RFC 8058 (la señal de un clic vía POST, sobre las cabeceras List-* de RFC 2369). La primera anuncia el mecanismo de baja; la segunda señala que es de verdad un clic y que debe procesarse con un POST HTTP. Omite cualquiera de las dos y no tienes un clic — tienes un enlace corriente.
# Dos cabeceras en cada mensaje promocional — ambas firmadas con DKIM
List-Unsubscribe: <https://example.com/u/9f2c4a8e>,
<mailto:unsub@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
# el valor de -Post debe ser EXACTAMENTE este; es la señal de un clic
Tres detalles deciden si esto funciona. La cabecera List-Unsubscribe debe contener al menos un URI
HTTPS, dentro de corchetes angulares — los corchetes ausentes son el motivo más común de que una
cabecera esté presente y no haga nada. El valor de List-Unsubscribe-Post debe ser exactamente
List-Unsubscribe=One-Click. Y ambas cabeceras deben estar cubiertas por una firma DKIM
válida y alineada, porque un receptor que no puede verificarlas puede ignorarlas por completo — que es
como fallan en silencio las cabeceras inyectadas por middleware tras la firma.
Incluir un URI mailto: junto al HTTPS es buena práctica, pero un mailto por sí solo no
cumple el requisito, porque no puede garantizar el procesamiento instantáneo y automatizado. El URI
HTTPS es el que lleva el mecanismo POST; el mailto está ahí para Apple Mail y los clientes antiguos que
lo prefieren.
El propio URI HTTPS merece un momento de reflexión, porque es donde se encuentran la seguridad y la fiabilidad. RFC 8058 recomienda que la URL de baja lleve un identificador opaco y difícil de falsificar en vez de una dirección de correo en claro en la cadena de consulta. La razón es doble: una dirección en claro es trivial de manipular para cualquiera, y filtra la dirección del destinatario a cualquier cosa que registre URL por el camino. Un token opaco — una cadena aleatoria e impredecible que tu sistema mapea de vuelta al destinatario y la lista correctos — permite que el POST se complete de inmediato manteniendo la dirección privada y la petición difícil de abusar. También significa que la URL lleva todo lo que el endpoint necesita para actuar por sí solo, que es justo lo que exige el un clic: la baja debe tener éxito desde el POST solo, sin que el endpoint recurra a una sesión, una cookie o un estado de sesión iniciada que el servidor de un proveedor de buzón nunca tendrá.
Implementación
Implementarlo de principio a fin
Seis pasos, de separar tus flujos a verificar sobre un mensaje entregado. Un ingeniero competente lo despliega en una tarde — el valor está en clavar los detalles exactos.
- 1
Identifica tus flujos promocionales
El un clic aplica al correo de marketing y de suscripción, no al transaccional. El primer paso no es añadir cabeceras a todo — es separar los flujos promocionales (boletines, campañas) de los restablecimientos de contraseña, recibos y confirmaciones, que están exentos.
- 2
Genera un token opaco por destinatario
Construye una URL de baja que identifique al destinatario y la lista lo bastante bien como para actuar de inmediato, usando un token opaco difícil de falsificar en vez de una dirección de correo en claro. El POST debe llevar todo lo necesario para completar la baja por sí solo.
- 3
Añade ambas cabeceras, firmadas con DKIM
Añade List-Unsubscribe con un URI HTTPS (y un mailto para Apple Mail), más List-Unsubscribe-Post con el valor exacto List-Unsubscribe=One-Click. Ambas cabeceras deben estar dentro de la firma DKIM, o los receptores pueden ignorarlas.
- 4
Construye un endpoint POST que complete la baja
El endpoint HTTPS debe dar de baja al destinatario y devolver 200 OK en POST, sin login, sin cadena de redirecciones y sin página de confirmación. Y algo crucial: nunca des de baja en GET — los escáneres precargan los enlaces y darán de baja a la gente en silencio.
- 5
Suprime en tiempo real, dentro de 48 horas
Procesa la baja de inmediato y deja de enviar dentro de la ventana de 48 horas que exigen los proveedores. Un trabajo por lotes diferido significa que la gente sigue recibiendo correo tras darse de baja, que es justo cuando se disparan las quejas de spam.
- 6
Verifica sobre el mensaje entregado
Envía un mensaje real por la ruta real de campaña y lee las cabeceras entregadas en bruto — no un envío de prueba — porque algunos sistemas añaden las cabeceras en una ruta pero no en otra. Luego haz POST al endpoint con curl para confirmar que de verdad elimina al destinatario.
El detalle que atrapa a los equipos más cuidadosos es el problema de las múltiples rutas: el correo de campaña, el de ciclo de vida y los mailers heredados suelen viajar por rutas distintas, y una ruta pone las cabeceras bien mientras otra, en silencio, no. Verificar sobre el mensaje real entregado, no una prueba, es lo que lo saca a la luz.
¿Cómo verifico que funciona de verdad?
No lo juzgues por si aparece el botón en la bandeja. El botón de Cancelar suscripción a menudo no se muestra en un envío de prueba aunque la implementación sea perfecta, en parte porque los proveedores sopesan la reputación del remitente antes de mostrarlo. La única comprobación fiable es leer las cabeceras en bruto de un mensaje entregado y luego ejercitar el endpoint directamente.
# Verifica que el endpoint da de baja solo con POST — sin login, sin redirección, 200 OK
curl -i -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "List-Unsubscribe=One-Click" \
https://example.com/u/9f2c4a8e
# esperado: 200 OK, y el destinatario realmente eliminado de la listaLa prueba debe confirmar dos cosas: que el endpoint devuelve 200 y que el destinatario se elimina de verdad de la lista prevista, sin login, cadena de redirecciones ni página de confirmación de por medio. Si aparece cualquiera de esas, tienes un enlace que funciona pero no un clic de RFC 8058, y los proveedores lo tratarán como incumplimiento.
Escollos
Los errores que rompen el un clic en silencio
La mayoría pasan un vistazo casual en tu propia bandeja y solo salen a la luz como quejas crecientes o rechazos repentinos.
| Error | Por qué rompe |
|---|---|
| Dar de baja en GET | Los escáneres de seguridad y los precargadores de enlaces piden las URL y dan de baja a la gente en silencio; un caso documentado dio de baja a miles de destinatarios de Microsoft. Procesa las bajas solo en POST. |
| Falta la cabecera List-Unsubscribe-Post | Está el enlace del pie o un List-Unsubscribe simple, pero sin la cabecera -Post no hay señal de un clic, que es justo lo que Gmail y Yahoo exigen. |
| Cabecera solo con mailto | Un URI mailto por sí solo no garantiza el procesamiento instantáneo y automatizado; se necesita un URI HTTPS para el mecanismo POST. |
| URL no HTTPS | Los endpoints HTTP planos no cumplen RFC 8058; Gmail los ignora. |
| Redirigir a un centro de preferencias | El endpoint debe completar la baja y devolver 200; redirigir a una página de confirmación o de preferencias rompe el un clic y se lee como incumplimiento. |
| Faltan los corchetes angulares | La causa nº1 de «la cabecera está pero no pasa nada» — la URL debe ir dentro de <...>. |
| Cabeceras añadidas tras la firma | El middleware o una ruta posterior que inyecta cabeceras tras la firma DKIM las deja sin firmar, así que los receptores pueden ignorarlas. Las múltiples rutas de correo suelen diferir en silencio. |
El que hay que tomarse más en serio es la baja disparada en GET. Parece inofensivo en pruebas, porque un humano que pulsa un enlace hace lo correcto — pero en producción, los escáneres y previsualizadores automáticos piden las URL de las cabeceras constantemente, y cada una de esas peticiones da de baja a alguien en silencio. Procesar las bajas solo en POST no es un detalle estético; es el problema concreto que RFC 8058 se escribió para resolver.
El flujo
Qué pasa cuando alguien pulsa Cancelar suscripción
El camino de un clic, y dónde se caen de él las implementaciones comunes.
Dos clientes quedan fuera de este camino limpio y necesitan manejo. Apple Mail usa el URI mailto e ignora el POST, así que también debes aceptar correos de baja entrantes; el webmail de Outlook puede bloquear a un remitente para un usuario internamente sin llamar nunca a tu endpoint, así que sigues recibiendo quejas que no puedes ver — por eso un enlace visible en el cuerpo sigue siendo tu red de seguridad.
La ventana de 48 horas y la supresión en tiempo real
Las cabeceras son solo la mitad de la obligación; honrar la petición es la otra mitad. Cuando un destinatario pulsa Cancelar suscripción, los proveedores exigen que la baja se procese dentro de 48 horas, y la propia guía de Google empuja a los remitentes a actuar más rápido cuando pueden. Esa ventana suena generosa hasta que miras cómo suprime de verdad la mayoría de los sistemas de envío: en un trabajo por lotes diferido que corre de noche, o una vez al día, o cuando se construye la siguiente campaña. Cualquier cosa más lenta que el casi tiempo real significa que la gente sigue recibiendo correo tras pedir explícitamente que pares.
Ese retraso es precisamente de donde vienen las quejas. Un destinatario que se da de baja y luego recibe otro mensaje a la mañana siguiente no supone que tu trabajo por lotes va con retraso — supone que lo ignoraste, y echa mano de Marcar como spam, que es justo el resultado que todo el mecanismo existe para evitar. La solución es tratar el POST de baja como un evento que actualiza la supresión de inmediato, antes de que el siguiente envío pueda volver a tomar la dirección, en vez de como una fila a reconciliar después.
La idempotencia también importa aquí, y es fácil de pasar por alto. Los proveedores y los escáneres pueden enviar el mismo POST más de una vez, así que tu endpoint debe tratar una baja repetida como una operación nula que aún devuelve 200, no como un error y desde luego no como algo que pudiera activar una resuscripción. Un endpoint que da de baja limpiamente en el primer POST pero falla en el segundo es un error sutil que se manifiesta como tickets de soporte confusos y la ocasional persona que asegura que la resuscribieron contra su voluntad.
Cómo se enlaza el un clic con tu tasa de quejas y la ley
El un clic no es una casilla aislada que marcar; se asienta directamente sobre el umbral de tasa de quejas que gobierna tu entregabilidad. Gmail y Yahoo quieren a los remitentes masivos por debajo de una tasa de quejas de spam del 0,1% y tratan cualquier cosa por encima del 0,3% como disparador de filtrado. A escala, eso es un margen finísimo, y una baja sin fricción es una de las pocas palancas que lo mueve a tu favor: cada destinatario que se va limpiamente por la cabecera es un destinatario que no presentó una queja. Una implementación correcta de un clic es, en ese sentido, gestión de la tasa de quejas con otro nombre.
También vive dentro de un marco legal que merece respeto por sí mismo. Un enlace de baja visible en el cuerpo es obligatorio por la ley antispam con independencia de lo que pidan Gmail y Yahoo, y las sanciones por equivocarse con la baja no son triviales — bajo la CAN-SPAM en Estados Unidos, las infracciones se evalúan por correo individual, no por campaña, lo que convierte un flujo de baja descuidado en una responsabilidad real a volumen. El un clic basado en cabecera y el enlace del pie exigido por ley son dos obligaciones distintas que dan la casualidad de apuntar en la misma dirección.
Lo alentador es que aquí el cumplimiento y la buena práctica convergen del todo. No hay versión de esto donde la elección óptima para la entregabilidad y la elección respetuosa con el destinatario diverjan: la misma salida sin fricción que te mantiene bajo el umbral de quejas es también la que respeta a la persona que ya no quiere tu correo. Esa alineación es bastante rara en entregabilidad como para nombrarla — la mayoría de las palancas implican un compromiso, y esta no.
Dónde nos situamos
Alojamos infraestructura de envío, y en las plataformas que operamos las cabeceras conformes son parte de la configuración en vez de una ocurrencia tardía — un stack autohospedado de KumoMTA o PowerMTA puede emitir un par List-Unsubscribe correcto, firmado con DKIM, en cada mensaje promocional, y un endpoint POST limpio es una pieza pequeña de pegamento. El punto honesto, sin embargo, es que las cabeceras son la parte fácil. El trabajo más difícil y valioso es mantener los flujos separados, la supresión en tiempo real y la lista lo bastante limpia como para que poca gente quiera irse en primer lugar.
Así que nuestro consejo es tratar el un clic como lo mínimo y luego ir más allá: despliega las dos cabeceras y el endpoint POST esta semana, verifícalos sobre un mensaje entregado, y dedica la energía ahorrada a la higiene de lista y la interacción, que es donde la entregabilidad se gana o se pierde de verdad. Si envías con nosotros, nos aseguraremos de que las cabeceras sean correctas y estén firmadas; si autohospedas o usas un ESP, el mismo estándar se aplica sea quien sea quien opere los servidores.
Preguntas
Respondidas con claridad
Las preguntas que se hacen los equipos antes de desplegar la desuscripción en un clic.
¿No basta con el enlace de baja del pie de mi correo?
No, no para el correo promocional masivo. El enlace del pie sigue siendo obligatorio por la ley antispam y por los proveedores, pero por sí solo no cumple el requisito de un clic. Gmail y Yahoo buscan específicamente la cabecera List-Unsubscribe-Post, que permite a su interfaz mostrar un botón nativo de Cancelar suscripción junto a tu nombre y completar la baja con un solo POST. El enlace del pie y el un clic basado en cabecera son complementarios: conserva ambos.
¿Qué debe contener exactamente List-Unsubscribe-Post?
Exactamente el valor List-Unsubscribe=One-Click — nada más. Esa cadena no es decorativa; es la señal definida por RFC 8058 que indica al receptor que puede hacer un POST HTTPS para una baja directa. Acompáñala de una cabecera List-Unsubscribe que contenga al menos un URI HTTPS dentro de corchetes angulares. Aquí es donde muchas configuraciones por lo demás correctas fallan en silencio: tienen List-Unsubscribe pero omiten la cabecera -Post, así que no hay señal de un clic en absoluto.
¿La desuscripción en un clic aplica al correo transaccional?
No. Los restablecimientos de contraseña, recibos, notificaciones de envío y confirmaciones de reserva están exentos — el requisito apunta al correo promocional y de suscripción. Los proveedores distinguen ambos en gran medida por el contenido y el comportamiento del destinatario más que por tu intención, así que lo práctico es separar tus flujos promocionales y aplicar las cabeceras ahí, dejando en paz el correo genuinamente transaccional.
¿Por qué los escáneres de enlaces dieron de baja a la gente automáticamente?
Porque el endpoint daba de baja en una petición GET. Las herramientas de seguridad, el antivirus y las previsualizaciones de bandeja piden de forma rutinaria las URL de las cabeceras, y si tu baja se dispara en GET, esas peticiones automáticas dan de baja a la gente en silencio — un caso documentado dio de baja así a miles de destinatarios de Microsoft. RFC 8058 existe precisamente para evitar esto: la baja debe ocurrir solo en POST, nunca en GET. Un GET debe, como mucho, mostrar una página informativa.
¿En qué se diferencian Apple Mail y Outlook aquí?
Apple Mail muestra un banner de Cancelar suscripción que usa el URI mailto e ignora el POST HTTPS por completo, por lo que conviene incluir tanto un mailto como un URI HTTPS y estar listo para procesar correos de baja entrantes. Outlook es más delicado: su webmail puede bloquear al remitente para ese usuario internamente sin llamar nunca a tu endpoint, así que nunca recibes la señal y sigues enviando — lo que luego genera quejas. La defensa es conservar un enlace de baja visible en el cuerpo como respaldo junto a las cabeceras.
¿Cómo verifico que mi implementación funciona de verdad?
No te fíes de si aparece el botón en la bandeja — a menudo no se muestra en los envíos de prueba aunque todo esté correcto, en parte porque los proveedores sopesan la reputación del remitente antes de mostrarlo. En su lugar, envía un mensaje real por tu ruta real de campaña y lee las cabeceras entregadas en bruto para confirmar que ambas están presentes y firmadas con DKIM. Luego haz POST al endpoint con curl, enviando List-Unsubscribe=One-Click, y confirma que el destinatario se elimina de verdad sin login, redirección ni página de confirmación.
¿Quieres el un clic bien hecho desde el principio?
Cuéntanos cómo envías, y nos aseguraremos de que tu correo promocional lleve cabeceras de un clic correctas y firmadas con DKIM — y un endpoint POST que dé de baja a la gente limpiamente.