Validación DKIM: Una mejor práctica de autenticación de correo electrónico
Pájaro
8 abr 2017
Correo electrónico
1 min read
Puntos clave
DKIM (DomainKeys Identified Mail) es un método de autenticación de correo electrónico basado en contenido que verifica si un mensaje fue alterado después de ser firmado.
A diferencia de SPF, que valida la ruta de envío, DKIM valida el contenido del mensaje en sí utilizando firmas criptográficas.
DKIM utiliza dos claves: una clave privada para firmar los mensajes salientes y una clave pública publicada en DNS para que los receptores validen las firmas.
Una firma DKIM incluye hashes de tanto los encabezados como el cuerpo, selectores, marcas de tiempo y campos de identidad —todo lo cual el receptor debe reproducir y verificar.
La validación de DKIM depende de recibir primero el mensaje completo, lo que significa que pueden ocurrir fallos tarde en el proceso.
Resolver problemas de validaciones DKIM fallidas es a menudo difícil porque los remitentes y receptores no pueden reproducir los entornos de firma/verificación de cada uno.
Incluso cuando DKIM falla, típicamente no causa problemas de entrega directamente por sí solo a menos que se combine con otras señales de reputación negativas.
Destacados de Q&A
¿Qué hace realmente DKIM?
DKIM adjunta una firma criptográfica a un correo electrónico, lo que permite al servidor receptor confirmar si el contenido del mensaje fue modificado después de que se envió.
¿Cómo es diferente DKIM de SPF?
SPF valida quién está autorizado a enviar correo para un dominio (basado en ruta).
DKIM valida si el contenido está intacto (basado en contenido).
Ambos sirven para diferentes propósitos y se complementan entre sí.
¿Qué hay dentro de un encabezado DKIM-Signature?
Campos clave incluyen:
v= versión
a= algoritmo
c= reglas de canonicalización
d= dominio de firma
s= selector
h= encabezados incluidos en la firma
bh= hash del cuerpo
b= datos de la firma real
Cada parte contribuye a cómo se valida la firma.
¿Cómo valida un servidor receptor DKIM?
Extrae los valores d= y s=.
Busca la clave pública en:
selector._domainkey.domain
Regenera los hashes de la cabecera y el cuerpo.
Los compara con los valores bh= y b= en el correo electrónico.
Si coinciden, el mensaje pasa DKIM.
¿Qué causa que DKIM falle?
Mensaje alterado en tránsito (incluso cambios de espacios si se utiliza la canonización estricta)
Clave pública incorrecta o faltante en DNS
Errores de formato DNS
Selector eliminado o girado incorrectamente
Identidades no coinciden (i= debe ser el mismo dominio o subdominio de d=)
¿Por qué pueden ser difíciles de resolver los fallos de DKIM?
Porque el firmante y el validador operan en entornos completamente distintos: ninguna de las partes puede reconstruir las condiciones de hashing o el estado de firma de la otra.
Esto hace que los fallos opacos de “desajuste de hash” sean los más frustrantes de diagnosticar.
¿Un fallo de DKIM significa que el correo electrónico llegará a spam?
No necesariamente.
DKIM es solo una señal. Si el dominio tiene una reputación fuerte y pasa otras verificaciones (SPF, alineación DMARC, bajas tasas de quejas), los fallos aislados de DKIM típicamente no afectan la entrega en Inbox por sí mismos.
¿Por qué usar DKIM en absoluto?
Protege la integridad del mensaje
Construye la reputación del dominio
Permite la alineación de DMARC
Ayuda a los proveedores de buzones a distinguir entre remitentes legítimos e impostores
DKIM se considera una práctica recomendada para todos los remitentes de correo electrónico serios.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que proporciona al destinatario de un mensaje un cierto nivel de certeza de que el mensaje realmente proviene de la fuente que se indica. La idea detrás de estas técnicas es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, correos que podrían erosionar la confianza del destinatario en recibir correos electrónicos. Dicho esto, el acto de enviar un correo electrónico autenticado no afirma que el correo electrónico sea bueno o deseado; solo significa que el correo es tal que se puede establecer y utilizar de manera confiable una reputación para la parte autenticada en las decisiones de aceptación y colocación de correos electrónicos.
Existen dos formas de autenticación de correo electrónico en uso hoy en día:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
En la publicación de hoy, estoy cubriendo qué es DKIM y cómo funciona.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que proporciona al destinatario de un mensaje un cierto nivel de certeza de que el mensaje realmente proviene de la fuente que se indica. La idea detrás de estas técnicas es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, correos que podrían erosionar la confianza del destinatario en recibir correos electrónicos. Dicho esto, el acto de enviar un correo electrónico autenticado no afirma que el correo electrónico sea bueno o deseado; solo significa que el correo es tal que se puede establecer y utilizar de manera confiable una reputación para la parte autenticada en las decisiones de aceptación y colocación de correos electrónicos.
Existen dos formas de autenticación de correo electrónico en uso hoy en día:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
En la publicación de hoy, estoy cubriendo qué es DKIM y cómo funciona.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que proporciona al destinatario de un mensaje un cierto nivel de certeza de que el mensaje realmente proviene de la fuente que se indica. La idea detrás de estas técnicas es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, correos que podrían erosionar la confianza del destinatario en recibir correos electrónicos. Dicho esto, el acto de enviar un correo electrónico autenticado no afirma que el correo electrónico sea bueno o deseado; solo significa que el correo es tal que se puede establecer y utilizar de manera confiable una reputación para la parte autenticada en las decisiones de aceptación y colocación de correos electrónicos.
Existen dos formas de autenticación de correo electrónico en uso hoy en día:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
En la publicación de hoy, estoy cubriendo qué es DKIM y cómo funciona.
Resumen de DKIM
A diferencia de su contraparte de autenticación SPF, que proporciona una forma para que un dominio autorice a un host a enviar correo en su nombre, DKIM ofrece una manera para que una entidad (dominio, organización, persona, etc.) asuma la responsabilidad de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad que envía serán las mismas, o al menos estrechamente relacionadas, con DKIM no hay requisito de que esto sea así.
Mis objetivos para ti con este artículo son que aprendas y entiendas los siguientes conceptos sobre DKIM:
DKIM es una autenticación "basada en contenido", a diferencia de la SPF "basada en rutas".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado de mensaje.
La validación de DKIM es realizada por el dominio receptor que intenta generar los mismos dos hashes.
La validación de DKIM no puede completarse en muchos casos hasta que el servidor que envía ha transmitido el mensaje completo.
Las fallas de validación pueden ser difíciles de solucionar.
A diferencia de su contraparte de autenticación SPF, que proporciona una forma para que un dominio autorice a un host a enviar correo en su nombre, DKIM ofrece una manera para que una entidad (dominio, organización, persona, etc.) asuma la responsabilidad de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad que envía serán las mismas, o al menos estrechamente relacionadas, con DKIM no hay requisito de que esto sea así.
Mis objetivos para ti con este artículo son que aprendas y entiendas los siguientes conceptos sobre DKIM:
DKIM es una autenticación "basada en contenido", a diferencia de la SPF "basada en rutas".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado de mensaje.
La validación de DKIM es realizada por el dominio receptor que intenta generar los mismos dos hashes.
La validación de DKIM no puede completarse en muchos casos hasta que el servidor que envía ha transmitido el mensaje completo.
Las fallas de validación pueden ser difíciles de solucionar.
A diferencia de su contraparte de autenticación SPF, que proporciona una forma para que un dominio autorice a un host a enviar correo en su nombre, DKIM ofrece una manera para que una entidad (dominio, organización, persona, etc.) asuma la responsabilidad de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad que envía serán las mismas, o al menos estrechamente relacionadas, con DKIM no hay requisito de que esto sea así.
Mis objetivos para ti con este artículo son que aprendas y entiendas los siguientes conceptos sobre DKIM:
DKIM es una autenticación "basada en contenido", a diferencia de la SPF "basada en rutas".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado de mensaje.
La validación de DKIM es realizada por el dominio receptor que intenta generar los mismos dos hashes.
La validación de DKIM no puede completarse en muchos casos hasta que el servidor que envía ha transmitido el mensaje completo.
Las fallas de validación pueden ser difíciles de solucionar.
Autenticación “Content-Based”
DKIM se refiere a la autenticación “basada en contenido”, en lugar de “basada en ruta”, porque si un mensaje pasa la validación DKIM se basa únicamente en si el contenido ha cambiado entre el momento en que fue firmado y el momento en que se intentó la validación.
DKIM se refiere a la autenticación “basada en contenido”, en lugar de “basada en ruta”, porque si un mensaje pasa la validación DKIM se basa únicamente en si el contenido ha cambiado entre el momento en que fue firmado y el momento en que se intentó la validación.
DKIM se refiere a la autenticación “basada en contenido”, en lugar de “basada en ruta”, porque si un mensaje pasa la validación DKIM se basa únicamente en si el contenido ha cambiado entre el momento en que fue firmado y el momento en que se intentó la validación.
DKIM Signing y Validation
Las organizaciones que deseen firmar correos DKIM primero generarán dos claves criptográficas. Una de las claves se mantiene privada y disponible para el servidor de envío para la firma de correos, y la otra se debe hacer pública en DNS para que los dominios receptores intenten validar la firma. Los métodos para generar estas claves e instalarlas dependen de la plataforma y están fuera del alcance de esta publicación, aunque más adelante describiré la publicación en DNS de la clave pública DKIM.
Las organizaciones que deseen firmar correos DKIM primero generarán dos claves criptográficas. Una de las claves se mantiene privada y disponible para el servidor de envío para la firma de correos, y la otra se debe hacer pública en DNS para que los dominios receptores intenten validar la firma. Los métodos para generar estas claves e instalarlas dependen de la plataforma y están fuera del alcance de esta publicación, aunque más adelante describiré la publicación en DNS de la clave pública DKIM.
Las organizaciones que deseen firmar correos DKIM primero generarán dos claves criptográficas. Una de las claves se mantiene privada y disponible para el servidor de envío para la firma de correos, y la otra se debe hacer pública en DNS para que los dominios receptores intenten validar la firma. Los métodos para generar estas claves e instalarlas dependen de la plataforma y están fuera del alcance de esta publicación, aunque más adelante describiré la publicación en DNS de la clave pública DKIM.
El Encabezado DKIM-Signature
Para empezar a comprender DKIM, primero veamos un encabezado DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
El encabezado DKIM-Signature es una serie de pares clave-valor, algunos de más interés para el lector que otros, pero describiré todos aquí.
Primero, veamos los que son principalmente de interés pasajero para el lector:
v=1; – Especifica la versión DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo utilizado para construir los hashes criptográficos
c=relaxed/relaxed; – Hay dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y el cuerpo que pueden aplicarse al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canalización” (de ahí la clave c) y los conjuntos de reglas son “relajadas” o “estrictas”.
t=1454417737; – La marca de tiempo de cuando se creó la firma.
Estos tres partes del encabezado contienen la información de la firma real:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este es el hash del cuerpo del mensaje.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta es una lista de los encabezados que se utilizaron para crear los datos de la firma mostrados a continuación.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos reales de la firma DKIM
Estas tres partes son de mayor interés para el servidor receptor que estará validando la firma:
d=welcome.foo.com; – Esto identifica el dominio que firmó el mensaje
s=notices; – El selector; los dominios pueden tener múltiples selectores que utilizan al firmar mensajes.
i=@welcome.foo.com; – Esta es la identidad en cuyo nombre se firmó el mensaje. Sintácticamente, esto parecerá una dirección de correo electrónico, e incluso podría ser una; la parte local de la dirección de correo electrónico puede estar vacía, como en este ejemplo, y la parte del dominio debe ser igual o un subdominio del dominio en la parte d= de la firma.
La razón por la cual estas partes son de interés para el servidor receptor es que proporcionan la información necesaria para ayudar al receptor a validar las firmas.
Campo | Significado | Cómo lo usan los receptores |
|---|---|---|
v= | Versión DKIM (siempre 1) | Confirma el formato de la firma |
a= | Algoritmo de hashing + firma (por ejemplo, rsa-sha256) | Garantiza que el validador reproduzca correctamente la firma |
c= | Reglas de canalización (encabezado/cuerpo) | Normaliza los espacios en blanco antes de aplicar el hash |
t= | Marca de tiempo de la creación de la firma | Utilizado para comprobar frescura y prevenir replays |
bh= | Hash del cuerpo | El receptor regenera esto para confirmar la integridad del cuerpo del mensaje |
h= | Lista de campos de encabezado firmados | Garantiza que los encabezados utilizados al firmar estén disponibles y sin modificar |
b= | Firma DKIM real | El receptor verifica esta firma contra la clave pública |
d= | Dominio firmante | Usado para localizar la clave pública DNS del firmante |
s= | Selector | Combinado con el dominio forma: selector._domainkey.domain |
i= | Identidad firmante | Debe ser igual o subdominio de d=, identifica la entidad firmante |
Para empezar a comprender DKIM, primero veamos un encabezado DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
El encabezado DKIM-Signature es una serie de pares clave-valor, algunos de más interés para el lector que otros, pero describiré todos aquí.
Primero, veamos los que son principalmente de interés pasajero para el lector:
v=1; – Especifica la versión DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo utilizado para construir los hashes criptográficos
c=relaxed/relaxed; – Hay dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y el cuerpo que pueden aplicarse al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canalización” (de ahí la clave c) y los conjuntos de reglas son “relajadas” o “estrictas”.
t=1454417737; – La marca de tiempo de cuando se creó la firma.
Estos tres partes del encabezado contienen la información de la firma real:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este es el hash del cuerpo del mensaje.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta es una lista de los encabezados que se utilizaron para crear los datos de la firma mostrados a continuación.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos reales de la firma DKIM
Estas tres partes son de mayor interés para el servidor receptor que estará validando la firma:
d=welcome.foo.com; – Esto identifica el dominio que firmó el mensaje
s=notices; – El selector; los dominios pueden tener múltiples selectores que utilizan al firmar mensajes.
i=@welcome.foo.com; – Esta es la identidad en cuyo nombre se firmó el mensaje. Sintácticamente, esto parecerá una dirección de correo electrónico, e incluso podría ser una; la parte local de la dirección de correo electrónico puede estar vacía, como en este ejemplo, y la parte del dominio debe ser igual o un subdominio del dominio en la parte d= de la firma.
La razón por la cual estas partes son de interés para el servidor receptor es que proporcionan la información necesaria para ayudar al receptor a validar las firmas.
Campo | Significado | Cómo lo usan los receptores |
|---|---|---|
v= | Versión DKIM (siempre 1) | Confirma el formato de la firma |
a= | Algoritmo de hashing + firma (por ejemplo, rsa-sha256) | Garantiza que el validador reproduzca correctamente la firma |
c= | Reglas de canalización (encabezado/cuerpo) | Normaliza los espacios en blanco antes de aplicar el hash |
t= | Marca de tiempo de la creación de la firma | Utilizado para comprobar frescura y prevenir replays |
bh= | Hash del cuerpo | El receptor regenera esto para confirmar la integridad del cuerpo del mensaje |
h= | Lista de campos de encabezado firmados | Garantiza que los encabezados utilizados al firmar estén disponibles y sin modificar |
b= | Firma DKIM real | El receptor verifica esta firma contra la clave pública |
d= | Dominio firmante | Usado para localizar la clave pública DNS del firmante |
s= | Selector | Combinado con el dominio forma: selector._domainkey.domain |
i= | Identidad firmante | Debe ser igual o subdominio de d=, identifica la entidad firmante |
Para empezar a comprender DKIM, primero veamos un encabezado DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
El encabezado DKIM-Signature es una serie de pares clave-valor, algunos de más interés para el lector que otros, pero describiré todos aquí.
Primero, veamos los que son principalmente de interés pasajero para el lector:
v=1; – Especifica la versión DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo utilizado para construir los hashes criptográficos
c=relaxed/relaxed; – Hay dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y el cuerpo que pueden aplicarse al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canalización” (de ahí la clave c) y los conjuntos de reglas son “relajadas” o “estrictas”.
t=1454417737; – La marca de tiempo de cuando se creó la firma.
Estos tres partes del encabezado contienen la información de la firma real:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este es el hash del cuerpo del mensaje.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta es una lista de los encabezados que se utilizaron para crear los datos de la firma mostrados a continuación.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos reales de la firma DKIM
Estas tres partes son de mayor interés para el servidor receptor que estará validando la firma:
d=welcome.foo.com; – Esto identifica el dominio que firmó el mensaje
s=notices; – El selector; los dominios pueden tener múltiples selectores que utilizan al firmar mensajes.
i=@welcome.foo.com; – Esta es la identidad en cuyo nombre se firmó el mensaje. Sintácticamente, esto parecerá una dirección de correo electrónico, e incluso podría ser una; la parte local de la dirección de correo electrónico puede estar vacía, como en este ejemplo, y la parte del dominio debe ser igual o un subdominio del dominio en la parte d= de la firma.
La razón por la cual estas partes son de interés para el servidor receptor es que proporcionan la información necesaria para ayudar al receptor a validar las firmas.
Campo | Significado | Cómo lo usan los receptores |
|---|---|---|
v= | Versión DKIM (siempre 1) | Confirma el formato de la firma |
a= | Algoritmo de hashing + firma (por ejemplo, rsa-sha256) | Garantiza que el validador reproduzca correctamente la firma |
c= | Reglas de canalización (encabezado/cuerpo) | Normaliza los espacios en blanco antes de aplicar el hash |
t= | Marca de tiempo de la creación de la firma | Utilizado para comprobar frescura y prevenir replays |
bh= | Hash del cuerpo | El receptor regenera esto para confirmar la integridad del cuerpo del mensaje |
h= | Lista de campos de encabezado firmados | Garantiza que los encabezados utilizados al firmar estén disponibles y sin modificar |
b= | Firma DKIM real | El receptor verifica esta firma contra la clave pública |
d= | Dominio firmante | Usado para localizar la clave pública DNS del firmante |
s= | Selector | Combinado con el dominio forma: selector._domainkey.domain |
i= | Identidad firmante | Debe ser igual o subdominio de d=, identifica la entidad firmante |
DKIM Validation
Además del requisito mencionado de que el dominio i= debe ser el mismo o un subdominio del dominio d=, los bits d= y s= son utilizados por el validador para buscar la clave pública DKIM del firmante en el DNS. La clave es un registro TXT en el DNS, y siempre se encuentra en la ubicación selector._domainkey.domain. Así que, en nuestro ejemplo aquí, con s=notices y d=welcome.foo.com, la clave pública DKIM se encontraría en el DNS en notices._domainkey.welcome.foo.com, y podría verse algo así:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
El validador utiliza esa clave (los bits p=) para producir su propio conjunto de hashes del mensaje; si esos hashes coinciden, entonces el mensaje no ha sido alterado en tránsito, y por lo tanto, el mensaje puede contribuir a, y quizá beneficiarse de, la reputación que esté en vigor para el firmante del mensaje.
Además del requisito mencionado de que el dominio i= debe ser el mismo o un subdominio del dominio d=, los bits d= y s= son utilizados por el validador para buscar la clave pública DKIM del firmante en el DNS. La clave es un registro TXT en el DNS, y siempre se encuentra en la ubicación selector._domainkey.domain. Así que, en nuestro ejemplo aquí, con s=notices y d=welcome.foo.com, la clave pública DKIM se encontraría en el DNS en notices._domainkey.welcome.foo.com, y podría verse algo así:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
El validador utiliza esa clave (los bits p=) para producir su propio conjunto de hashes del mensaje; si esos hashes coinciden, entonces el mensaje no ha sido alterado en tránsito, y por lo tanto, el mensaje puede contribuir a, y quizá beneficiarse de, la reputación que esté en vigor para el firmante del mensaje.
Además del requisito mencionado de que el dominio i= debe ser el mismo o un subdominio del dominio d=, los bits d= y s= son utilizados por el validador para buscar la clave pública DKIM del firmante en el DNS. La clave es un registro TXT en el DNS, y siempre se encuentra en la ubicación selector._domainkey.domain. Así que, en nuestro ejemplo aquí, con s=notices y d=welcome.foo.com, la clave pública DKIM se encontraría en el DNS en notices._domainkey.welcome.foo.com, y podría verse algo así:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
El validador utiliza esa clave (los bits p=) para producir su propio conjunto de hashes del mensaje; si esos hashes coinciden, entonces el mensaje no ha sido alterado en tránsito, y por lo tanto, el mensaje puede contribuir a, y quizá beneficiarse de, la reputación que esté en vigor para el firmante del mensaje.
Fallo de Validación y Solución de Problemas
Mencioné anteriormente que los fallos de DKIM pueden ser difíciles de solucionar, y aquí explicaré por qué es así.
Algunos fallos de validación de DKIM tienen causas evidentes, como que el mensaje no esté firmado, o que la clave pública del dominio de firma no se encuentre en DNS o no sea sintácticamente correcta, o tal vez el mensaje fue obviamente alterado en tránsito. Cuando ocurren ese tipo de fallos es fácil identificar el problema y recomendar una solución. Los difíciles, sin embargo, y los que conducen a la experiencia de soporte más frustrante, son los casos en los que el mensaje fue firmado, la clave pública existe en DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no se pudo validar.
La razón por la que estos son difíciles de solucionar es porque no hay una forma real para que ninguna de las partes reproduzca las condiciones bajo las cuales el mensaje fue firmado y validado. El mensaje tiene en su encabezado de DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero probablemente el validador no tiene acceso a la infraestructura del firmante y, por lo tanto, no puede intentar reproducir la firma bajo las condiciones del firmante. De manera similar, el firmante probablemente no tiene acceso a la infraestructura del validador y, por lo tanto, no tiene forma de intentar validar el mensaje de la manera en que lo hizo el validador.
Los fallos como los que describo aquí son raros, y los fallos de validación de DKIM por sí solos generalmente no tienen un impacto en la ubicación de la entrega. Mientras DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico exhaustivas garantiza que estés enviando a direcciones legítimas que realmente pueden recibir y autenticar tus mensajes. Ha sido mi experiencia que tales fallos generan más tickets de soporte que cualquier otro tipo de problema de DKIM.
Mencioné anteriormente que los fallos de DKIM pueden ser difíciles de solucionar, y aquí explicaré por qué es así.
Algunos fallos de validación de DKIM tienen causas evidentes, como que el mensaje no esté firmado, o que la clave pública del dominio de firma no se encuentre en DNS o no sea sintácticamente correcta, o tal vez el mensaje fue obviamente alterado en tránsito. Cuando ocurren ese tipo de fallos es fácil identificar el problema y recomendar una solución. Los difíciles, sin embargo, y los que conducen a la experiencia de soporte más frustrante, son los casos en los que el mensaje fue firmado, la clave pública existe en DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no se pudo validar.
La razón por la que estos son difíciles de solucionar es porque no hay una forma real para que ninguna de las partes reproduzca las condiciones bajo las cuales el mensaje fue firmado y validado. El mensaje tiene en su encabezado de DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero probablemente el validador no tiene acceso a la infraestructura del firmante y, por lo tanto, no puede intentar reproducir la firma bajo las condiciones del firmante. De manera similar, el firmante probablemente no tiene acceso a la infraestructura del validador y, por lo tanto, no tiene forma de intentar validar el mensaje de la manera en que lo hizo el validador.
Los fallos como los que describo aquí son raros, y los fallos de validación de DKIM por sí solos generalmente no tienen un impacto en la ubicación de la entrega. Mientras DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico exhaustivas garantiza que estés enviando a direcciones legítimas que realmente pueden recibir y autenticar tus mensajes. Ha sido mi experiencia que tales fallos generan más tickets de soporte que cualquier otro tipo de problema de DKIM.
Mencioné anteriormente que los fallos de DKIM pueden ser difíciles de solucionar, y aquí explicaré por qué es así.
Algunos fallos de validación de DKIM tienen causas evidentes, como que el mensaje no esté firmado, o que la clave pública del dominio de firma no se encuentre en DNS o no sea sintácticamente correcta, o tal vez el mensaje fue obviamente alterado en tránsito. Cuando ocurren ese tipo de fallos es fácil identificar el problema y recomendar una solución. Los difíciles, sin embargo, y los que conducen a la experiencia de soporte más frustrante, son los casos en los que el mensaje fue firmado, la clave pública existe en DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no se pudo validar.
La razón por la que estos son difíciles de solucionar es porque no hay una forma real para que ninguna de las partes reproduzca las condiciones bajo las cuales el mensaje fue firmado y validado. El mensaje tiene en su encabezado de DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero probablemente el validador no tiene acceso a la infraestructura del firmante y, por lo tanto, no puede intentar reproducir la firma bajo las condiciones del firmante. De manera similar, el firmante probablemente no tiene acceso a la infraestructura del validador y, por lo tanto, no tiene forma de intentar validar el mensaje de la manera en que lo hizo el validador.
Los fallos como los que describo aquí son raros, y los fallos de validación de DKIM por sí solos generalmente no tienen un impacto en la ubicación de la entrega. Mientras DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico exhaustivas garantiza que estés enviando a direcciones legítimas que realmente pueden recibir y autenticar tus mensajes. Ha sido mi experiencia que tales fallos generan más tickets de soporte que cualquier otro tipo de problema de DKIM.
