Correo identificado por DomainKeys

DomainKeys Identified Mail ( DKIM ) es un método de autenticación de correo electrónico diseñado para detectar direcciones de remitentes falsificadas en el correo electrónico ( suplantación de identidad ), una técnica que se utiliza a menudo en el phishing y el correo no deseado .

DKIM permite al receptor comprobar que un correo electrónico que afirma provenir de un dominio específico fue efectivamente autorizado por el propietario de ese dominio. ^[1] Esto se logra mediante la colocación de una firma digital , vinculada a un nombre de dominio, en cada mensaje de correo electrónico saliente. El sistema del destinatario puede verificar esto consultando la clave pública del remitente publicada en el DNS . Una firma válida también garantiza que algunas partes del correo electrónico (posiblemente incluidos los archivos adjuntos ) no se hayan modificado desde que se colocó la firma. ^[2] Por lo general, las firmas DKIM no son visibles para los usuarios finales y son colocadas o verificadas por la infraestructura en lugar de los autores y destinatarios del mensaje.

DKIM es un estándar de Internet . ^[3] Está definido en RFC 6376, de septiembre de 2011, con actualizaciones en RFC 8301 y RFC 8463.

La necesidad de una identificación validada por correo electrónico surge porque, de otro modo, es fácil crear direcciones y contenidos falsificados, que se utilizan ampliamente en spam , phishing y otros fraudes basados ​​en correo electrónico. ^[4] Por ejemplo, un estafador puede enviar un mensaje que dice ser de [email protected] , con el objetivo de convencer al destinatario de que acepte y lea el correo electrónico, y es difícil para los destinatarios determinar si confían en este mensaje. Los administradores de sistemas también tienen que lidiar con quejas sobre correo electrónico malicioso que parece haberse originado en sus sistemas, pero no fue así. ^[5]

DKIM ofrece la posibilidad de firmar un mensaje y permite al firmante ( organización autora ) comunicar qué correo electrónico considera legítimo. No previene ni revela directamente el comportamiento abusivo.

DKIM también proporciona un proceso para verificar un mensaje firmado. Los módulos de verificación suelen actuar en nombre de la organización receptora , posiblemente en cada salto .

Todo esto es independiente de los aspectos de enrutamiento del Protocolo simple de transferencia de correo (SMTP), ya que opera sobre el mensaje RFC 5322 (el encabezado y el cuerpo del correo transportado), no sobre el "sobre" SMTP definido en el RFC 5321. Por lo tanto, las firmas DKIM sobreviven a la retransmisión básica a través de múltiples agentes de transferencia de mensajes .

La organización firmante puede ser un manejador directo del mensaje, como el autor, el agente de envío de correo , el sitio o cualquier intermediario a lo largo de la ruta de tránsito, o un manejador indirecto, como un servicio independiente que brinda asistencia a un manejador directo.

Los módulos de firma insertan uno o más DKIM-Signature:campos de encabezado, posiblemente en nombre de la organización autora o del proveedor de servicios de origen. La especificación permite a los firmantes elegir qué campos de encabezado firman, pero el From:campo siempre debe estar firmado. ^{[6] [7]} El campo de encabezado resultante consta de una lista de tag=valuepartes como en el ejemplo siguiente:

Firma DKIM:  v=1;  a=rsa-sha256;  d= ejemplo.net ;  s=brisbane;  c=relajado/simple;  q=dns/txt; [email protected] ; t=1117574938; x=1118006938; l=200; h=desde:hasta:asunto:fecha:palabrasclave:palabrasclave; z=Desde: [email protected] |Para: [email protected] | Asunto:demo=20run|Fecha:julio=205,=202005=203:44:08=20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR          

donde las etiquetas utilizadas son:

Los más relevantes son b para la firma digital real del contenido (encabezados y cuerpo) del mensaje de correo, bh para el hash del cuerpo (opcionalmente limitado a los primeros 16 octetos del cuerpo), d para el dominio de firma y s para el selector.

Se puede incluir opcionalmente un identificador de agente o usuario (AUID). El formato es una dirección de correo electrónico con una parte local opcional. El dominio debe ser igual o un subdominio del dominio firmante. La semántica del AUID se deja intencionalmente sin definir y el dominio firmante puede utilizarla para establecer una esfera de responsabilidad más precisa.

Tanto el encabezado como el cuerpo contribuyen a la firma. Primero, se genera un hash del cuerpo del mensaje, siempre desde el principio, posiblemente truncado a una longitud dada l (que puede ser cero). Segundo, se genera un hash de los campos del encabezado seleccionados, en el orden dado por h . Los nombres de campo repetidos se comparan desde la parte inferior del encabezado hacia arriba, que es el orden en el que Received:se insertan los campos en el encabezado. Un campo inexistente coincide con la cadena vacía, de modo que agregar un campo con ese nombre romperá la firma. El DKIM-Signature:campo de la firma que se está creando, con bh igual al hash del cuerpo calculado y b igual a la cadena vacía, se agrega implícitamente al segundo hash, aunque su nombre no debe aparecer en h - si lo hace, se refiere a otra firma preexistente. Para ambos hashes, el texto se canoniza de acuerdo con los algoritmos c relevantes. El resultado, después del cifrado con la clave privada del firmante y la codificación con Base64, es b .

Además de la lista de campos de encabezado que figuran en h , se puede proporcionar en z una lista de campos de encabezado (que incluya tanto el nombre del campo como el valor) presentes en el momento de la firma . Esta lista no necesita coincidir con la lista de encabezados en h .

Los algoritmos, los campos y la longitud del cuerpo deben elegirse de modo que se garantice una identificación inequívoca del mensaje y, al mismo tiempo, se permita que las firmas sobrevivan a los cambios inevitables que se producirán durante el tránsito. No se implica ninguna integridad de los datos de extremo a extremo. ^[2]

Un servidor SMTP receptor que desea verificar utiliza el nombre de dominio y el selector para realizar una búsqueda DNS. ^[8] Por ejemplo, dada la firma de ejemplo anterior: la etiqueta d proporciona el dominio del autor que se verificará, example.net  ; la etiqueta s el selector, brisbane . La cadena _domainkey es una parte fija de la especificación. Esto proporciona el registro de recursos TXT que se buscará como:

brisbane._domainkey.example.net

Tenga en cuenta que el selector y el nombre de dominio pueden ser UTF-8 en el correo electrónico internacionalizado. ^[9] En ese caso, la etiqueta debe codificarse de acuerdo con IDNA antes de la búsqueda. Los datos devueltos de la consulta de este registro también son una lista de pares de etiqueta-valor. Incluye la clave pública del dominio , junto con otros tokens y marcas de uso de clave (por ejemplo, desde una línea de comando: nslookup -q=TXT brisbane._domainkey.example.net) como en este ejemplo:

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

Las etiquetas disponibles son: ^[3]

Un registro CNAME también se puede utilizar para apuntar a un registro TXT diferente, por ejemplo, cuando una organización envía un correo electrónico en nombre de otra.

El receptor puede utilizar la clave pública (valor de la etiqueta p ) para validar la firma en el valor hash del campo de encabezado y compararlo con el valor hash del mensaje de correo electrónico (encabezados y cuerpo) que recibió. Si los dos valores coinciden, esto demuestra criptográficamente que el correo electrónico fue firmado por el dominio indicado y no ha sido alterado durante el tránsito.

El error en la verificación de la firma no obliga a rechazar el mensaje. En cambio, las razones precisas por las que no se pudo probar la autenticidad del mensaje deben ponerse a disposición de los procesos ascendentes y descendentes. Los métodos para hacerlo pueden incluir el envío de un mensaje FBL o la adición de un Authentication-Results:campo de encabezado al mensaje como se describe en RFC 7001.

DomainKeys estaba protegido por la patente estadounidense 6.986.049 , que ya ha expirado. Yahoo! licenció sus reivindicaciones de patentes bajo un esquema de licencia dual: el Acuerdo de Licencia de Patente de DomainKeys v1.2 , ^[10] o la Licencia Pública General GNU v2.0 (y ninguna otra versión) . ^{[11] [12]}

En esencia, tanto DKIM como SPF proporcionan diferentes medidas de autenticidad del correo electrónico. DMARC permite a una organización publicar una política que especifique qué mecanismo (DKIM, SPF o ambos) se utiliza al enviar correo electrónico desde ese dominio; cómo comprobar el From:campo presentado a los usuarios finales; cómo debe tratar el receptor las fallas, y un mecanismo de notificación de las acciones realizadas conforme a esas políticas. ^[13]

La principal ventaja de este sistema para los destinatarios de correo electrónico es que permite al dominio firmante identificar de manera confiable un flujo de correo electrónico legítimo, lo que permite que las listas negras y blancas basadas en dominios sean más efectivas. ^[14] Esto también es probable que haga que ciertos tipos de ataques de phishing sean más fáciles de detectar.

Existen algunos incentivos para que los remitentes de correo firmen el correo electrónico saliente:

• Permite una gran reducción en el trabajo de escritorio de abuso para dominios habilitados para DKIM si los receptores de correo electrónico utilizan el sistema DKIM para identificar mensajes de correo electrónico falsificados que dicen ser de ese dominio.
• El propietario del dominio puede entonces concentrar las energías de su equipo anti-abuso en sus propios usuarios que en realidad están haciendo un uso inapropiado de ese dominio.

DKIM es un método para etiquetar un mensaje y no filtra ni identifica el correo basura. Sin embargo, el uso generalizado de DKIM puede evitar que los spammers falsifiquen la dirección de origen de sus mensajes, una técnica que emplean comúnmente en la actualidad. Si se obliga a los spammers a mostrar un dominio de origen correcto, otras técnicas de filtrado pueden funcionar de manera más eficaz. En particular, el dominio de origen puede incorporarse a un sistema de reputación para identificar mejor el correo basura. Por el contrario, DKIM puede facilitar la identificación de correo que se sabe que no es correo basura y que no necesita filtrarse. Si un sistema receptor tiene una lista blanca de dominios de envío conocidos como buenos, ya sea mantenida localmente o por certificadores externos, puede omitir el filtrado del correo firmado de esos dominios y quizás filtrar el correo restante de manera más agresiva. ^[14]

DKIM puede ser útil como una tecnología anti- phishing . Los remitentes de correo en dominios que han sido víctimas de phishing pueden firmar su correo para demostrar que es genuino. Los destinatarios pueden tomar la ausencia de una firma válida en el correo de esos dominios como una indicación de que el correo probablemente sea falso. La mejor manera de determinar el conjunto de dominios que merecen este grado de escrutinio sigue siendo una pregunta abierta. DKIM solía tener una característica opcional llamada ADSP que permite a los autores que firman todo su correo autoidentificarse, pero fue degradada a estado histórico en noviembre de 2013. ^[15] En cambio, DMARC se puede utilizar para el mismo propósito ^[16] y permite a los dominios autopublicar qué técnicas (incluyendo SPF y DKIM) emplean, lo que hace que sea más fácil para el receptor tomar una decisión informada sobre si un determinado correo es spam o no. ^[17] Por ejemplo, al utilizar DMARC, eBay y PayPal publican políticas que establecen que todo su correo está autenticado y solicitan que cualquier sistema receptor, como Gmail , rechace todo aquel que no lo esté. ^[18]

Dado que se implementa utilizando registros DNS y un campo de encabezado RFC 5322 adicional, DKIM es compatible con la infraestructura de correo electrónico existente. En particular, es transparente para los sistemas de correo electrónico existentes que carecen de compatibilidad con DKIM. ^[19]

Este enfoque de diseño también es compatible con otros servicios relacionados, como los estándares de protección de contenido S/MIME y OpenPGP . DKIM es compatible con el estándar DNSSEC y con SPF .

DKIM requiere que se generen sumas de comprobación criptográficas para cada mensaje enviado a través de un servidor de correo, lo que genera una sobrecarga computacional que de otro modo no sería necesaria para la entrega de correo electrónico. Esta sobrecarga computacional adicional es una característica distintiva de los sellos postales digitales, lo que hace que el envío de spam masivo sea más costoso (computacionalmente). ^[20] Esta faceta de DKIM puede parecer similar a hashcash , excepto que la verificación del lado del receptor es una cantidad insignificante de trabajo, mientras que un algoritmo hashcash típico requeriría mucho más trabajo. ^{[ cita requerida ]}

La función de no repudio de DKIM impide que los remitentes (como los spammers) nieguen de forma creíble haber enviado un correo electrónico. Ha resultado útil para medios de comunicación como WikiLeaks , que ha podido aprovechar las firmas del cuerpo de DKIM para demostrar que los correos electrónicos filtrados eran auténticos y no habían sido manipulados. ^[21]

Muchos consideran que el no repudio es una característica no deseada de DKIM, forzada por comportamientos como los que se acaban de describir. De hecho, el protocolo DKIM prevé la expiración. Hay una etiqueta x opcional en cada firma, que establece un tiempo de expiración formal; sin embargo, los verificadores pueden ignorarla. Además, los propietarios de dominios pueden revocar una clave pública eliminando sus datos criptográficos del registro, impidiendo así la verificación de la firma a menos que alguien haya guardado los datos de la clave pública de antemano. La rotación de claves DKIM se recomienda a menudo simplemente para minimizar el impacto de las claves comprometidas. Sin embargo, para desactivar definitivamente el no repudio, se pueden publicar claves secretas vencidas, lo que permite que cualquiera produzca firmas falsas, anulando así la importancia de las originales. ^{[22] [23] [24]}

El propio RFC identifica una serie de posibles vectores de ataque. ^[25]

Las firmas DKIM no incluyen el sobre del mensaje, que contiene la ruta de retorno y los destinatarios del mensaje. Dado que DKIM no intenta proteger contra direcciones incorrectas, esto no afecta su utilidad.

En 2013, en el momento de la estandarización, se plantearon y refutaron una serie de preocupaciones. ^[26]

Una preocupación para cualquier solución criptográfica sería el abuso de la reproducción de mensajes , que pasa por alto las técnicas que actualmente limitan el nivel de abuso de dominios más grandes. ^{[ aclaración necesaria ]} La reproducción se puede inferir utilizando claves públicas por mensaje, rastreando las consultas DNS para esas claves y filtrando la gran cantidad de consultas debido al envío de correo electrónico a grandes listas de correo o consultas maliciosas por parte de actores maliciosos.

Para una comparación de diferentes métodos que también abordan este problema, consulte autenticación de correo electrónico .

Como se mencionó anteriormente, la autenticación no es lo mismo que la prevención de abusos. Un usuario de correo electrónico malintencionado de un dominio de confianza puede redactar un mensaje malicioso y hacer que se firme con DKIM y se envíe desde ese dominio a cualquier buzón de correo desde donde pueda recuperarlo como un archivo, para así obtener una copia firmada del mensaje. El uso de la etiqueta l en las firmas hace que la manipulación de dichos mensajes sea aún más fácil. La copia firmada puede luego reenviarse a un millón de destinatarios, por ejemplo a través de una botnet , sin control. El proveedor de correo electrónico que firmó el mensaje puede bloquear al usuario infractor, pero no puede detener la difusión de mensajes ya firmados. La validez de las firmas en dichos mensajes puede limitarse incluyendo siempre una etiqueta de tiempo de expiración en las firmas, o revocando una clave pública periódicamente o tras una notificación de un incidente. La efectividad del escenario difícilmente puede limitarse filtrando el correo saliente, ya que eso implica la capacidad de detectar si un mensaje podría ser potencialmente útil para los spammers. ^[27]

Actualmente, DKIM cuenta con dos algoritmos de canonización , simple y relajado , ninguno de los cuales es compatible con MIME . ^[28] Los servidores de correo pueden convertir legítimamente a un conjunto de caracteres diferente y, a menudo, documentan esto con campos de encabezado. Además, los servidores en determinadas circunstancias tienen que reescribir la estructura MIME, alterando así el preámbulo , el epílogo y los límites de entidad, cualquiera de los cuales rompe las firmas DKIM. Solo los mensajes de texto sin formato escritos en us-ascii , siempre que los campos de encabezado MIME no estén firmados, ^[29] disfrutan de la solidez que requiere la integridad de extremo a extremo.X-MIME-Autoconverted:

El Proyecto OpenDKIM organizó una recopilación de datos que involucraba 21 servidores de correo y millones de mensajes. El 92,3% de las firmas observadas se verificaron con éxito, una tasa de éxito que disminuye ligeramente (90,5%) cuando solo se considera el tráfico de listas de correo. ^[30]

Los problemas pueden verse exacerbados cuando el software de filtrado o retransmisión realiza cambios en un mensaje. Si el remitente no toma precauciones específicas, la adición de pie de página que realizan la mayoría de las listas de correo y muchas soluciones antivirus centrales romperá la firma DKIM. Una posible mitigación es firmar solo una cantidad designada de bytes del cuerpo del mensaje. Esto se indica con la etiqueta l en el encabezado de firma DKIM . Todo lo que se agregue más allá de la longitud especificada del cuerpo del mensaje no se tiene en cuenta al calcular la firma DKIM. Esto no funcionará para los mensajes MIME. ^[31]

Otra solución alternativa es incluir en la lista blanca a los reenvíos conocidos, por ejemplo, mediante SPF . Para otra solución alternativa, se propuso que los reenvíos verifiquen la firma, modifiquen el correo electrónico y luego vuelvan a firmar el mensaje con un encabezado Sender: ^{[32] Sin embargo, esta solución tiene su riesgo con los mensajes firmados de terceros reenviados recibidos en receptores SMTP que admiten el protocolo} ADSP RFC 5617. Por lo tanto, en la práctica, el servidor receptor aún tiene que incluir en la lista blanca los flujos de mensajes conocidos .

La cadena de recepción autenticada (ARC) es un sistema de autenticación de correo electrónico diseñado para permitir que un servidor de correo intermedio, como una lista de correo o un servicio de reenvío, firme los resultados de autenticación originales de un correo electrónico. Esto permite que un servicio de recepción valide un correo electrónico cuando los registros SPF y DKIM del correo electrónico se invalidan debido al procesamiento de un servidor intermedio. ^[33] La ARC se define en la RFC 8617, publicada en julio de 2019, como "Experimental". ^[34]

En octubre de 2012, Wired informó que el matemático Zach Harris detectó y demostró una vulnerabilidad de suplantación de la fuente de correo electrónico con claves DKIM cortas para el google.comdominio corporativo, así como para varios otros dominios de alto perfil. Afirmó que la autenticación con claves de 384 bits se puede tener en cuenta en tan solo 24 horas "en mi computadora portátil", y claves de 512 bits, en aproximadamente 72 horas con recursos de computación en la nube. Harris descubrió que muchas organizaciones firman correo electrónico con claves tan cortas; las tuvo en cuenta todas y notificó a las organizaciones sobre la vulnerabilidad. Afirma que las claves de 768 bits podrían tener acceso a grandes cantidades de potencia informática, por lo que sugiere que la firma DKIM debería utilizar longitudes de clave superiores a 1024.

Wired afirmó que Harris informó, y Google confirmó, que comenzaron a utilizar nuevas claves más largas poco después de su divulgación. Según el RFC 6376, la parte receptora debe poder validar firmas con claves que van desde 512 bits a 2048 bits, por lo que el uso de claves más cortas que 512 bits podría ser incompatible y se debe evitar. El RFC 6376 también establece que los firmantes deben usar claves de al menos 1024 bits para claves de larga duración, aunque no se especifica la duración de la misma. ^[35]

DKIM surgió en 2004 de la fusión de dos esfuerzos similares, "Enhanced DomainKeys" de Yahoo y "Identified Internet Mail" de Cisco . ^{[36] [37]} Esta especificación fusionada ha sido la base para una serie de especificaciones de seguimiento de estándares IETF y documentos de soporte que finalmente resultaron en STD 76, actualmente RFC 6376. ^[38] "Identified Internet Mail" fue propuesto por Cisco como un estándar de autenticación de correo basado en firma, ^{[39] [40]} mientras que DomainKeys fue diseñado por Yahoo ^{[41] [42]} para verificar el dominio DNS de un remitente de correo electrónico y la integridad del mensaje .

Los aspectos de DomainKeys, junto con partes de Identified Internet Mail, se combinaron para crear DomainKeys Identified Mail (DKIM). ^{[41] [43] [44]} Entre los proveedores que marcan tendencia y que implementan DKIM se encuentran Yahoo , Gmail , AOL y FastMail . Todo correo de estas organizaciones debe llevar una firma DKIM. ^{[41] [45] [46] [47]}

Las discusiones sobre las firmas DKIM que pasan a través de flujos de correo indirectos, formalmente en el grupo de trabajo DMARC, tuvieron lugar justo después de que las primeras adopciones del nuevo protocolo causaran estragos en el uso regular de las listas de correo . Sin embargo, ninguno de los cambios propuestos para DKIM fue aprobado. En cambio, se modificó el software de las listas de correo. ^{[48] [ cita irrelevante ]}

En 2017, se lanzó otro grupo de trabajo, DKIM Crypto Update (dcrup), con la restricción específica de revisar las técnicas de firma. ^[49] RFC 8301 se emitió en enero de 2018. Prohíbe SHA-1 y actualiza los tamaños de clave (de 512-2048 a 1024-4096). ^[50] RFC 8463 se emitió en septiembre de 2018. Agrega un algoritmo de curva elíptica al RSA existente . El tipo de clave agregado es lo suficientemente fuerte al tiempo que presenta claves públicas cortas, más fácilmente publicables en DNS. ^[51]k=ed25519

El DomainKeys original fue diseñado por Mark Delany de Yahoo! y mejorado a través de los comentarios de muchos otros desde 2004. Está especificado en el histórico RFC 4870, reemplazado por el Standards Track RFC 4871, DomainKeys Identified Mail (DKIM) Signatures; ambos publicados en mayo de 2007. Una serie de aclaraciones y conceptualizaciones se recopilaron posteriormente y se especificaron en el RFC 5672, agosto de 2009, en forma de correcciones a la especificación existente. En septiembre de 2011, el RFC 6376 fusionó y actualizó los dos últimos documentos, al tiempo que preservó la esencia del protocolo DKIM. También es posible la compatibilidad de clave pública con el DomainKeys anterior.

DKIM fue producido inicialmente por un consorcio informal de la industria y luego fue presentado para su mejora y estandarización por el Grupo de trabajo DKIM de la IETF , presidido por Barry Leiba y Stephen Farrell, con Eric Allman de sendmail , Jon Callas de PGP Corporation , Mark Delany y Miles Libbey de Yahoo !, y Jim Fenton y Michael Thomas de Cisco Systems atribuidos como autores principales.

El desarrollo del código fuente de una biblioteca común está dirigido por el Proyecto OpenDKIM , siguiendo las incorporaciones de protocolo más recientes y con licencia bajo la Nueva Licencia BSD . ^[52]

Los proveedores de correo electrónico exigen cada vez más que los remitentes implementen la autenticación de correo electrónico para poder entregar con éxito el correo a los buzones de sus usuarios.

En febrero de 2024, Google comenzó a exigir a los remitentes masivos que autenticaran sus correos electrónicos con DKIM para entregarlos correctamente a los buzones alojados por Google. ^{[53] [54]}

De manera similar, en febrero de 2024, Yahoo comenzó a exigir a los remitentes masivos que implementaran SPF y DKIM para entregar con éxito correos electrónicos a los usuarios de Yahoo. ^[55]

• Cadena de recepción autenticada (ARC)
• Prácticas de firma de dominios de autor
• Mensaje de rebote
• Filtrado de contexto
• DMARC (Autenticación, informes y conformidad de mensajes basados ​​en dominios)
• Claves de dominio
• Autenticación de correo electrónico
• OpenPGP
• S/MIME
• Marco de políticas de remitentes (SPF)
• Aval por referencia

• RFC 4686 Análisis de las amenazas que motivan el correo identificado con claves de dominio (DKIM)
• RFC 4871 Propuesta de estándar para firmas de correo identificadas con claves de dominio (DKIM)
• RFC 5617 Prácticas de firma de dominios de autor de correo identificado con claves de dominio (DKIM) (ADSP)
• Descripción general del servicio de correo identificado con claves de dominio (DKIM) RFC 5585
• RFC 5672 RFC 4871 Firmas de correo identificadas con claves de dominio (DKIM) - Actualización
• RFC 5863 Desarrollo, implementación y operaciones de DKIM
• Borrador del estándar RFC 6376 para firmas de correo identificadas con claves de dominio (DKIM)
• RFC 6377 Correo identificado con claves de dominio (DKIM) y listas de correo
• Actualización del algoritmo criptográfico y uso de claves de RFC 8301 para correo identificado con claves de dominio (DKIM)
• RFC 8463 Un nuevo método de firma criptográfica para correo identificado con claves de dominio (DKIM)

• Correo identificado con claves de dominio (DKIM)