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.
Descripción general 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 proporciona una manera para que una entidad (dominio, organización, persona, etc.) se responsabilice de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad emisora serán la misma, o al menos estarán estrechamente relacionadas, con DKIM no hay un requisito de que 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 SPF "basada en ruta".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado del 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 se puede completar en muchos casos hasta que el mensaje completo haya sido transmitido por el servidor emisor.
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 proporciona una manera para que una entidad (dominio, organización, persona, etc.) se responsabilice de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad emisora serán la misma, o al menos estarán estrechamente relacionadas, con DKIM no hay un requisito de que 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 SPF "basada en ruta".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado del 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 se puede completar en muchos casos hasta que el mensaje completo haya sido transmitido por el servidor emisor.
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 proporciona una manera para que una entidad (dominio, organización, persona, etc.) se responsabilice de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad emisora serán la misma, o al menos estarán estrechamente relacionadas, con DKIM no hay un requisito de que 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 SPF "basada en ruta".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado del 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 se puede completar en muchos casos hasta que el mensaje completo haya sido transmitido por el servidor emisor.
Las fallas de validación pueden ser difíciles de solucionar.
Autenticación basada en “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 con 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 hará pública en DNS para su uso por los dominios receptores en intentos de 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 con 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 hará pública en DNS para su uso por los dominios receptores en intentos de 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 con 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 hará pública en DNS para su uso por los dominios receptores en intentos de 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 DKIM-Signature Header
Para comenzar nuestra comprensión de 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, veremos los que son mayormente de interés pasajero para el lector:
v=1; – Especifica la versión de DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo utilizado para construir los hashes criptográficos
c=relaxed/relaxed; – Existen dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y cuerpo que pueden aplicarse al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canonicalización” (de ahí la clave de c) y los conjuntos de reglas son “relaxed” o “strict”.
t=1454417737; – La marca de tiempo de cuando se creó la firma.
Estas tres partes del encabezado contienen la información de 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 que se muestran a continuación.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos reales de 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 serlo; 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 la misma o un subdominio del dominio en la parte d= de la firma.
La razón por la que 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.
Para comenzar nuestra comprensión de 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, veremos los que son mayormente de interés pasajero para el lector:
v=1; – Especifica la versión de DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo utilizado para construir los hashes criptográficos
c=relaxed/relaxed; – Existen dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y cuerpo que pueden aplicarse al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canonicalización” (de ahí la clave de c) y los conjuntos de reglas son “relaxed” o “strict”.
t=1454417737; – La marca de tiempo de cuando se creó la firma.
Estas tres partes del encabezado contienen la información de 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 que se muestran a continuación.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos reales de 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 serlo; 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 la misma o un subdominio del dominio en la parte d= de la firma.
La razón por la que 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.
Para comenzar nuestra comprensión de 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, veremos los que son mayormente de interés pasajero para el lector:
v=1; – Especifica la versión de DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo utilizado para construir los hashes criptográficos
c=relaxed/relaxed; – Existen dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y cuerpo que pueden aplicarse al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canonicalización” (de ahí la clave de c) y los conjuntos de reglas son “relaxed” o “strict”.
t=1454417737; – La marca de tiempo de cuando se creó la firma.
Estas tres partes del encabezado contienen la información de 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 que se muestran a continuación.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos reales de 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 serlo; 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 la misma o un subdominio del dominio en la parte d= de la firma.
La razón por la que 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.
DKIM Validation
Además del requisito mencionado de que el dominio i= debe ser el mismo que 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 DNS. La clave es un registro TXT en 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 DNS en notices._domainkey.welcome.foo.com, y podría verse algo como esto:
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 usa 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 y quizás beneficiarse de cualquier reputación que esté en su lugar para el firmante del mensaje.
Además del requisito mencionado de que el dominio i= debe ser el mismo que 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 DNS. La clave es un registro TXT en 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 DNS en notices._domainkey.welcome.foo.com, y podría verse algo como esto:
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 usa 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 y quizás beneficiarse de cualquier reputación que esté en su lugar para el firmante del mensaje.
Además del requisito mencionado de que el dominio i= debe ser el mismo que 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 DNS. La clave es un registro TXT en 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 DNS en notices._domainkey.welcome.foo.com, y podría verse algo como esto:
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 usa 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 y quizás beneficiarse de cualquier reputación que esté en su lugar para el firmante del mensaje.
Fallo de Validación y Solución de Problemas
Mencioné anteriormente que las fallas de DKIM pueden ser difíciles de solucionar, y explicaré por qué es así aquí.
Algunas fallas en la validación de DKIM tienen causas obvias, como que el mensaje no esté firmado, o que la clave pública del dominio firmante no se encuentre en el DNS o no sea sintácticamente correcta, o tal vez el mensaje haya sido obviamente alterado durante el tránsito. Cuando ocurren ese tipo de fallas, es fácil identificar el problema y recomendar una solución. Sin embargo, las difíciles, y las que conducen a la experiencia de soporte más frustrante, son los casos en que el mensaje fue firmado, la clave pública existe en el DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no pasó la validación.
La razón por la que estas fallas son difíciles de solucionar es porque no hay una manera 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 DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero el validador probablemente 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 manera de intentar validar el mensaje de la misma manera que lo hizo el validador.
Fallos como los que estoy describiendo aquí son eventos raros, y las fallas de validación de DKIM por sí solas generalmente no tienen un impacto en la colocación de entrega. Mientras que DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico integrales asegura que estás enviando a direcciones legítimas que pueden recibir y autenticar tus mensajes realmente. En mi experiencia, tales fallos generan más tickets de soporte que cualquier otro tipo de problema relacionado con DKIM.
Mencioné anteriormente que las fallas de DKIM pueden ser difíciles de solucionar, y explicaré por qué es así aquí.
Algunas fallas en la validación de DKIM tienen causas obvias, como que el mensaje no esté firmado, o que la clave pública del dominio firmante no se encuentre en el DNS o no sea sintácticamente correcta, o tal vez el mensaje haya sido obviamente alterado durante el tránsito. Cuando ocurren ese tipo de fallas, es fácil identificar el problema y recomendar una solución. Sin embargo, las difíciles, y las que conducen a la experiencia de soporte más frustrante, son los casos en que el mensaje fue firmado, la clave pública existe en el DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no pasó la validación.
La razón por la que estas fallas son difíciles de solucionar es porque no hay una manera 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 DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero el validador probablemente 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 manera de intentar validar el mensaje de la misma manera que lo hizo el validador.
Fallos como los que estoy describiendo aquí son eventos raros, y las fallas de validación de DKIM por sí solas generalmente no tienen un impacto en la colocación de entrega. Mientras que DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico integrales asegura que estás enviando a direcciones legítimas que pueden recibir y autenticar tus mensajes realmente. En mi experiencia, tales fallos generan más tickets de soporte que cualquier otro tipo de problema relacionado con DKIM.
Mencioné anteriormente que las fallas de DKIM pueden ser difíciles de solucionar, y explicaré por qué es así aquí.
Algunas fallas en la validación de DKIM tienen causas obvias, como que el mensaje no esté firmado, o que la clave pública del dominio firmante no se encuentre en el DNS o no sea sintácticamente correcta, o tal vez el mensaje haya sido obviamente alterado durante el tránsito. Cuando ocurren ese tipo de fallas, es fácil identificar el problema y recomendar una solución. Sin embargo, las difíciles, y las que conducen a la experiencia de soporte más frustrante, son los casos en que el mensaje fue firmado, la clave pública existe en el DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no pasó la validación.
La razón por la que estas fallas son difíciles de solucionar es porque no hay una manera 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 DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero el validador probablemente 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 manera de intentar validar el mensaje de la misma manera que lo hizo el validador.
Fallos como los que estoy describiendo aquí son eventos raros, y las fallas de validación de DKIM por sí solas generalmente no tienen un impacto en la colocación de entrega. Mientras que DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico integrales asegura que estás enviando a direcciones legítimas que pueden recibir y autenticar tus mensajes realmente. En mi experiencia, tales fallos generan más tickets de soporte que cualquier otro tipo de problema relacionado con DKIM.
