← RFC Reference

RFC 5617: ADSP — Prácticas de Firma del Dominio del Autor

Por qué existe

DKIM (RFC 6376) permite que un dominio firme sus mensajes salientes, pero no indica a los receptores qué hacer cuando un mensaje carece de una firma válida. Sin una capa de política, un receptor no tiene forma de saber si un mensaje sin firmar de bank.example.com es legítimo (quizás su ruta saliente no siempre firma) o fraudulento (un phisher suplantando al banco).

ADSP fue el primer intento de llenar este vacío. Permitió que los propietarios de dominios publicaran un registro DNS declarando su práctica de firma:

• "unknown" — el dominio puede o no firmar todos los mensajes (el valor predeterminado si no existe registro ADSP).
• "all" — el dominio firma todos los mensajes con una Firma de Autor (el d= de DKIM coincide con el dominio From:).
• "discardable" — el dominio firma todos los mensajes, y los mensajes sin firmar deben descartarse.

Publicado en agosto de 2009, ADSP tuvo una adopción limitada y fue trasladado al estado "Historic" en noviembre de 2013 por RFC 5863. Su sucesor, DMARC, abordó las deficiencias de ADSP y se convirtió en el mecanismo de política de autenticación de correo electrónico estándar.

Cómo funciona

La búsqueda DNS

Los registros ADSP se publican como registros DNS TXT en _adsp._domainkey.<domain>. Cuando un receptor obtiene un mensaje con un encabezado From: de alice@example.com, busca:

Valores de política

Firma de Autor vs. Firma de Terceros

Un concepto clave en ADSP es la Firma de Autor — una firma DKIM donde la etiqueta d= en el encabezado DKIM-Signature coincide exactamente con el dominio en el encabezado From:. Esto es más estricto que DKIM general, que permite que cualquier dominio firme:

Esto significaba que si utilizabas un ESP (Proveedor de Servicios de Correo Electrónico) que firmaba correo como d=esp.com en lugar de d=tudominio.com, ADSP trataría esos mensajes como sin firmar — aunque tuvieran una firma DKIM perfectamente válida.

El flujo de verificación

1. Recibir el mensaje y extraer el dominio del encabezado From:.
2. Buscar encabezados DKIM-Signature donde d= coincida con el dominio From (Firmas de Autor).
3. Si existe una Firma de Autor válida y se valida, aceptar el mensaje normalmente.
4. Si no existe una Firma de Autor válida, consultar DNS por _adsp._domainkey.<domain>.
5. Aplicar la política: unknown significa no tomar medidas, all significa tratar con sospecha, discardable significa rechazar o descartar silenciosamente.

Detalles técnicos clave

Por qué ADSP falló

El diseño de ADSP tenía limitaciones fundamentales que previnieron una adopción significativa:

• Las listas de correo rompen las Firmas de Autor. Cuando una lista de correo modifica el mensaje (añade un pie de página, cambia el Subject), la firma DKIM se rompe. Bajo dkim=discardable, el receptor descartaría el mensaje. Los dominios que usan listas de correo nunca podrían desplegar de forma segura una política estricta.
• Sin cobertura de subdominio. ADSP solo se aplicaba al dominio exacto consultado. No había forma de establecer una política para *.example.com sin publicar registros para cada subdominio individualmente.
• Sin mecanismo de informe. ADSP no tenía forma de que los receptores enviaran comentarios a los propietarios de dominios sobre resultados de autenticación. Sin datos, los propietarios de dominios no podían evaluar el impacto de una política más estricta antes de desplegarla.
• Sin lanzamiento gradual. Las únicas opciones eran "unknown" (sin protección), "all" (ambiguo), o "discardable" (nuclear). No había equivalente a la etiqueta porcentaje (pct=) de DMARC para aplicación gradual.
• SPF no fue considerado. ADSP solo evaluaba DKIM. Un mensaje que pasaba SPF pero carecía de DKIM se trataba igual que una falsificación completamente no autenticada.

ADSP vs. DMARC: Diferencias clave

El registro DNS en detalle

Errores comunes

• Desplegar ADSP en 2024+. ADSP es historic. Ningún receptor importante verifica registros ADSP. Si aún tienes uno publicado, no hace nada. Despliega DMARC en su lugar.
• Confundir ADSP con DMARC. Ambos son mecanismos de política para DKIM, pero DMARC es el estándar actual. Si encuentras documentación que referencia registros _adsp._domainkey, está desactualizada.
• Dejar registros ADSP anticuados en DNS. Los registros ADSP antiguos consumen tiempo de consulta DNS y añaden confusión durante la depuración. Si encuentras registros TXT _adsp._domainkey en tu zona, límplalos.
• Pensar que "discardable" era la política más estricta posible. Incluso en su apogeo, "discardable" de ADSP fue respetado por muy pocos receptores. La adopción era demasiado baja para proporcionar protección significativa contra suplantación.
• No aprender la lección. ADSP falló porque era todo o nada sin visibilidad. DMARC tuvo éxito porque añadió informe (rua=) y lanzamiento gradual (pct=). Siempre comienza con monitoreo antes de aplicación.

Impacto en la entregabilidad

• Sin impacto actual. Los receptores modernos no verifican registros ADSP. Publicar uno no tiene efecto en la entrega, resultados de autenticación, o filtrado de spam.
• Lección histórica para despliegue de DMARC. El fracaso de ADSP informó directamente el diseño de DMARC. Las características de informe y lanzamiento gradual que hacen DMARC desplegable existen porque ADSP demostró que una política binaria sin retroalimentación es impráctica.
• Registros anticuados como señal. Un registro ADSP antiguo en DNS es una señal leve de que la infraestructura de correo electrónico de un dominio no se mantiene activamente. Aunque ningún receptor penaliza esto, puede causar confusión durante la depuración de autenticación.
• Migrar a DMARC. Si tu dominio tiene un registro ADSP pero sin registro DMARC, despliega DMARC inmediatamente. Comienza con p=none y una dirección de informe rua= para ganar visibilidad, luego estrecha la política basándote en datos.

Related RFCs