Validação DKIM: Uma Melhoria de Autenticação de Emails
Pássaro
8 de abr. de 2017
1 min read
Principais Conclusões
DKIM (DomainKeys Identified Mail) é um método de autenticação de e-mail baseado em conteúdo que verifica se uma mensagem foi alterada após ser assinada.
Diferentemente do SPF, que valida o caminho de envio, o DKIM valida o conteúdo da mensagem em si usando assinaturas criptográficas.
O DKIM utiliza duas chaves: uma chave privada para assinar mensagens de saída e uma chave pública publicada no DNS para que os receptores validem as assinaturas.
Uma assinatura DKIM inclui hashes tanto dos cabeçalhos quanto do corpo, seletores, carimbos de data/hora e campos de identidade — tudo isso que o receptor deve reproduzir e verificar.
A validação DKIM depende de receber a mensagem inteira primeiro, o que significa que falhas podem ocorrer no final do processo.
Resolver falhas na validação DKIM é frequentemente difícil porque remetentes e receptores não conseguem reproduzir os ambientes de assinatura/validação um do outro.
Mesmo quando o DKIM falha, geralmente não causa diretamente problemas de entrega na caixa de entrada, a menos que seja combinado com outros sinais de reputação negativa.
Destaques de Perguntas e Respostas
O que o DKIM realmente faz?
DKIM anexa uma assinatura criptográfica a um email, permitindo que o servidor receptor confirme se o conteúdo da mensagem foi modificado após ser enviado.
Como o DKIM é diferente do SPF?
SPF valida quem está autorizado a enviar e-mails para um domínio (baseado em caminho).
DKIM valida se o conteúdo está intacto (baseado em conteúdo).
Ambos têm propósitos diferentes e se complementam.
O que há dentro de um cabeçalho DKIM-Signature?
Os campos principais incluem:
v= versão
a= algoritmo
c= regras de canonização
d= domínio de assinatura
s= seletor
h= cabeçalhos incluídos na assinatura
bh= hash do corpo
b= dados da assinatura real
Cada parte contribui para como a assinatura é validada.
Como um servidor receptor valida o DKIM?
Extrai os valores de d= e s=.
Procura a chave pública em:
selector._domainkey.domain
Regenera os hashes do cabeçalho e do corpo.
Compara-os com os valores bh= e b= no e-mail.
Se corresponderem, a mensagem passa no DKIM.
O que causa a falha do DKIM?
Mensagem alterada em trânsito (até as alterações de espaço em branco se utilizar a canonicalização estrita)
Chave pública incorreta ou ausente no DNS
Erros de formatação do DNS
Selector removido ou rotacionado incorretamente
Identidades incompatíveis (i= deve ser o mesmo domínio ou subdomínio de d=)
Por que falhas no DKIM podem ser difíceis de solucionar?
Porque o signatário e o validador operam em ambientes completamente diferentes — nenhum dos lados pode reconstruir as condições de hashing ou o estado de assinatura do outro.
Isso torna falhas de “incompatibilidade de hash” opacas as mais frustrantes de diagnosticar.
Uma falha no DKIM significa que o e-mail irá para a pasta de spam?
Nem necessariamente.
DKIM é apenas um sinal. Se o domínio tiver uma boa reputação e passar por outras verificações (alinhamento SPF, DMARC, baixas taxas de reclamação), falhas isoladas de DKIM normalmente não impactam a entrega na caixa de entrada por conta própria.
Por que usar DKIM?
Protege a integridade das mensagens
Constrói a reputação do domínio
Habilita o alinhamento DMARC
Ajuda os provedores de caixa de entrada a distinguir remetentes legítimos de falsificadores
DKIM é considerado uma boa prática para todos os remetentes de e-mail sérios.
Quando falamos sobre “Autenticação de Email”, estamos nos referindo a uma técnica que proporciona ao destinatário de uma mensagem algum nível de certeza de que a mensagem realmente se originou na fonte reivindicada da mensagem. A ideia por trás dessas técnicas é alcançar algum nível de defesa contra e-mails fraudulentos, como phishing e spoofing, e-mails que podem erodir a confiança de um destinatário ao receber e-mails. Dito isso, o ato de enviar e-mails autenticados não afirma que o e-mail é bom ou desejado; apenas significa que o e-mail é tal que uma reputação para a parte autenticada pode ser estabelecida de forma confiável e usada nas decisões de aceitação e colocação de e-mails.
Existem duas formas de autenticação de e-mail em uso hoje:
Framework de Política do Remetente (SPF)
Chaves de Domínio Identificadas de E-mail (DKIM)
No post de hoje, estou cobrindo o que é DKIM e como funciona.
Quando falamos sobre “Autenticação de Email”, estamos nos referindo a uma técnica que proporciona ao destinatário de uma mensagem algum nível de certeza de que a mensagem realmente se originou na fonte reivindicada da mensagem. A ideia por trás dessas técnicas é alcançar algum nível de defesa contra e-mails fraudulentos, como phishing e spoofing, e-mails que podem erodir a confiança de um destinatário ao receber e-mails. Dito isso, o ato de enviar e-mails autenticados não afirma que o e-mail é bom ou desejado; apenas significa que o e-mail é tal que uma reputação para a parte autenticada pode ser estabelecida de forma confiável e usada nas decisões de aceitação e colocação de e-mails.
Existem duas formas de autenticação de e-mail em uso hoje:
Framework de Política do Remetente (SPF)
Chaves de Domínio Identificadas de E-mail (DKIM)
No post de hoje, estou cobrindo o que é DKIM e como funciona.
Quando falamos sobre “Autenticação de Email”, estamos nos referindo a uma técnica que proporciona ao destinatário de uma mensagem algum nível de certeza de que a mensagem realmente se originou na fonte reivindicada da mensagem. A ideia por trás dessas técnicas é alcançar algum nível de defesa contra e-mails fraudulentos, como phishing e spoofing, e-mails que podem erodir a confiança de um destinatário ao receber e-mails. Dito isso, o ato de enviar e-mails autenticados não afirma que o e-mail é bom ou desejado; apenas significa que o e-mail é tal que uma reputação para a parte autenticada pode ser estabelecida de forma confiável e usada nas decisões de aceitação e colocação de e-mails.
Existem duas formas de autenticação de e-mail em uso hoje:
Framework de Política do Remetente (SPF)
Chaves de Domínio Identificadas de E-mail (DKIM)
No post de hoje, estou cobrindo o que é DKIM e como funciona.
Visão Geral do DKIM
Diferente de seu contraparte de autenticação SPF, que fornece uma maneira para um domínio autorizar um host a enviar e-mails em seu nome, DKIM fornece uma maneira para uma entidade (domínio, organização, pessoa, etc.) assumir a responsabilidade por uma mensagem, independentemente da entidade que realmente enviou a mensagem. Embora em muitos casos a entidade responsável e a entidade remetente sejam a mesma, ou pelo menos intimamente relacionadas, com o DKIM não há requisito de que isso seja assim.
Meus objetivos para você com este post são que você aprenda e entenda os seguintes conceitos sobre DKIM:
DKIM é uma autenticação “baseada em conteúdo”, ao contrário da SPF “baseada em caminho”.
A entidade responsável afirma sua responsabilidade “assinando” a mensagem com um par de hashes criptográficos inseridos em um cabeçalho da mensagem.
A validação DKIM é feita pelo domínio receptor tentando gerar os mesmos dois hashes.
A validação DKIM não pode ser concluída em muitos casos até que a mensagem completa tenha sido transmitida pelo servidor de envio.
Falhas de validação podem ser difíceis de solucionar.
Diferente de seu contraparte de autenticação SPF, que fornece uma maneira para um domínio autorizar um host a enviar e-mails em seu nome, DKIM fornece uma maneira para uma entidade (domínio, organização, pessoa, etc.) assumir a responsabilidade por uma mensagem, independentemente da entidade que realmente enviou a mensagem. Embora em muitos casos a entidade responsável e a entidade remetente sejam a mesma, ou pelo menos intimamente relacionadas, com o DKIM não há requisito de que isso seja assim.
Meus objetivos para você com este post são que você aprenda e entenda os seguintes conceitos sobre DKIM:
DKIM é uma autenticação “baseada em conteúdo”, ao contrário da SPF “baseada em caminho”.
A entidade responsável afirma sua responsabilidade “assinando” a mensagem com um par de hashes criptográficos inseridos em um cabeçalho da mensagem.
A validação DKIM é feita pelo domínio receptor tentando gerar os mesmos dois hashes.
A validação DKIM não pode ser concluída em muitos casos até que a mensagem completa tenha sido transmitida pelo servidor de envio.
Falhas de validação podem ser difíceis de solucionar.
Diferente de seu contraparte de autenticação SPF, que fornece uma maneira para um domínio autorizar um host a enviar e-mails em seu nome, DKIM fornece uma maneira para uma entidade (domínio, organização, pessoa, etc.) assumir a responsabilidade por uma mensagem, independentemente da entidade que realmente enviou a mensagem. Embora em muitos casos a entidade responsável e a entidade remetente sejam a mesma, ou pelo menos intimamente relacionadas, com o DKIM não há requisito de que isso seja assim.
Meus objetivos para você com este post são que você aprenda e entenda os seguintes conceitos sobre DKIM:
DKIM é uma autenticação “baseada em conteúdo”, ao contrário da SPF “baseada em caminho”.
A entidade responsável afirma sua responsabilidade “assinando” a mensagem com um par de hashes criptográficos inseridos em um cabeçalho da mensagem.
A validação DKIM é feita pelo domínio receptor tentando gerar os mesmos dois hashes.
A validação DKIM não pode ser concluída em muitos casos até que a mensagem completa tenha sido transmitida pelo servidor de envio.
Falhas de validação podem ser difíceis de solucionar.
Autenticação Baseada em Conteúdo
DKIM é referido como autenticação “baseada em conteúdo”, em vez de “baseada em caminho”, porque se uma mensagem passa ou não na validação DKIM é baseado exclusivamente se o conteúdo mudou ou não entre o momento em que foi assinado e o momento em que a validação foi tentada.
DKIM é referido como autenticação “baseada em conteúdo”, em vez de “baseada em caminho”, porque se uma mensagem passa ou não na validação DKIM é baseado exclusivamente se o conteúdo mudou ou não entre o momento em que foi assinado e o momento em que a validação foi tentada.
DKIM é referido como autenticação “baseada em conteúdo”, em vez de “baseada em caminho”, porque se uma mensagem passa ou não na validação DKIM é baseado exclusivamente se o conteúdo mudou ou não entre o momento em que foi assinado e o momento em que a validação foi tentada.
Assinatura e Validação DKIM
Organizações que desejam assinar e-mails com DKIM primeiro gerarão duas chaves criptográficas. Uma das chaves é mantida em segredo e disponível para o servidor de envio para a assinatura do e-mail, e a outra deve ser tornada pública no DNS para uso pelos domínios receptores em tentativas de validar a assinatura. Os métodos para gerar essas chaves e instalá-las dependem da plataforma e vão além do escopo deste post, embora mais tarde eu descreverei a publicação no DNS da chave DKIM pública.
Organizações que desejam assinar e-mails com DKIM primeiro gerarão duas chaves criptográficas. Uma das chaves é mantida em segredo e disponível para o servidor de envio para a assinatura do e-mail, e a outra deve ser tornada pública no DNS para uso pelos domínios receptores em tentativas de validar a assinatura. Os métodos para gerar essas chaves e instalá-las dependem da plataforma e vão além do escopo deste post, embora mais tarde eu descreverei a publicação no DNS da chave DKIM pública.
Organizações que desejam assinar e-mails com DKIM primeiro gerarão duas chaves criptográficas. Uma das chaves é mantida em segredo e disponível para o servidor de envio para a assinatura do e-mail, e a outra deve ser tornada pública no DNS para uso pelos domínios receptores em tentativas de validar a assinatura. Os métodos para gerar essas chaves e instalá-las dependem da plataforma e vão além do escopo deste post, embora mais tarde eu descreverei a publicação no DNS da chave DKIM pública.
O Cabeçalho DKIM-Signature
Para começar nossa compreensão do DKIM, vamos primeiro olhar para um cabeçalho 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=;
O cabeçalho DKIM-Signature é uma série de pares chave-valor, alguns de maior interesse para o leitor do que outros, mas irei descrever todos eles aqui.
Primeiro, vamos olhar para aqueles que são principalmente de interesse passageiro para o leitor:
v=1; – Especifica a versão do DKIM (1 é o único valor válido)
a=rsa-sha256; – O algoritmo usado para construir os hashes criptográficos
c=relaxed/relaxed; – Existem dois conjuntos de regras sobre remoção de espaços em branco nos cabeçalhos e no corpo que podem ser aplicadas ao criar os hashes em uma assinatura DKIM; essas regras são chamadas de “regras de canonização” (daí a chave c) e os conjuntos de regras são “relaxed” ou “strict”.
t=1454417737; – O carimbo de data/hora de quando a assinatura foi criada.
Essas três partes do cabeçalho contêm as informações reais da assinatura:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este é o hash do corpo da mensagem.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta é uma lista dos cabeçalhos que foram usados para criar os dados da assinatura mostrados abaixo.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Esta é a real assinatura DKIM
Essas três partes são do maior interesse para o servidor receptor que estará validando a assinatura:
d=welcome.foo.com; – Isso identifica o domínio que assinou a mensagem
s=notices; – O seletor; os domínios podem ter múltiplos seletores que usam ao assinar mensagens.
i=@welcome.foo.com; – Esta é a identidade em nome de quem a mensagem foi assinada. Sintaticamente, isso parecerá um endereço de email, e pode até ser um; a parte local do endereço de email pode estar vazia, como neste exemplo, e a parte do domínio deve ser a mesma que ou um subdomínio do domínio na parte d= da assinatura.
A razão pela qual essas partes são de interesse para o servidor receptor é que elas fornecem as informações necessárias para ajudar o receptor a validar as assinaturas.
Campo | Significado | Como os Receptores Usam |
|---|---|---|
v= | versão DKIM (sempre 1) | Confirma o formato da assinatura |
a= | Algoritmo de hashing + assinatura (por exemplo, rsa-sha256) | Garante que o validador reproduza a assinatura corretamente |
c= | Regras de canonização (cabeçalho/corpo) | Normaliza espaços em branco antes de fazer o hash |
t= | Carimbo de data/hora da criação da assinatura | Usado para verificações de frescor e prevenção contra reprodução |
bh= | Hash do corpo | O receptor regenera isso para confirmar a integridade do corpo da mensagem |
h= | Lista de campos de cabeçalho assinados | Garante que os cabeçalhos usados na assinatura estão disponíveis e não foram modificados |
b= | Assinatura DKIM real | O receptor verifica esta assinatura contra a chave pública |
d= | Domínio de assinatura | Usado para localizar a chave pública DNS do signatário |
s= | Seletor | Juntamente com o domínio para formar: selector._domainkey.domain |
i= | Identidade de assinatura | Deve ser igual ou subdomínio de d=, identifica a entidade que assina |
Para começar nossa compreensão do DKIM, vamos primeiro olhar para um cabeçalho 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=;
O cabeçalho DKIM-Signature é uma série de pares chave-valor, alguns de maior interesse para o leitor do que outros, mas irei descrever todos eles aqui.
Primeiro, vamos olhar para aqueles que são principalmente de interesse passageiro para o leitor:
v=1; – Especifica a versão do DKIM (1 é o único valor válido)
a=rsa-sha256; – O algoritmo usado para construir os hashes criptográficos
c=relaxed/relaxed; – Existem dois conjuntos de regras sobre remoção de espaços em branco nos cabeçalhos e no corpo que podem ser aplicadas ao criar os hashes em uma assinatura DKIM; essas regras são chamadas de “regras de canonização” (daí a chave c) e os conjuntos de regras são “relaxed” ou “strict”.
t=1454417737; – O carimbo de data/hora de quando a assinatura foi criada.
Essas três partes do cabeçalho contêm as informações reais da assinatura:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este é o hash do corpo da mensagem.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta é uma lista dos cabeçalhos que foram usados para criar os dados da assinatura mostrados abaixo.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Esta é a real assinatura DKIM
Essas três partes são do maior interesse para o servidor receptor que estará validando a assinatura:
d=welcome.foo.com; – Isso identifica o domínio que assinou a mensagem
s=notices; – O seletor; os domínios podem ter múltiplos seletores que usam ao assinar mensagens.
i=@welcome.foo.com; – Esta é a identidade em nome de quem a mensagem foi assinada. Sintaticamente, isso parecerá um endereço de email, e pode até ser um; a parte local do endereço de email pode estar vazia, como neste exemplo, e a parte do domínio deve ser a mesma que ou um subdomínio do domínio na parte d= da assinatura.
A razão pela qual essas partes são de interesse para o servidor receptor é que elas fornecem as informações necessárias para ajudar o receptor a validar as assinaturas.
Campo | Significado | Como os Receptores Usam |
|---|---|---|
v= | versão DKIM (sempre 1) | Confirma o formato da assinatura |
a= | Algoritmo de hashing + assinatura (por exemplo, rsa-sha256) | Garante que o validador reproduza a assinatura corretamente |
c= | Regras de canonização (cabeçalho/corpo) | Normaliza espaços em branco antes de fazer o hash |
t= | Carimbo de data/hora da criação da assinatura | Usado para verificações de frescor e prevenção contra reprodução |
bh= | Hash do corpo | O receptor regenera isso para confirmar a integridade do corpo da mensagem |
h= | Lista de campos de cabeçalho assinados | Garante que os cabeçalhos usados na assinatura estão disponíveis e não foram modificados |
b= | Assinatura DKIM real | O receptor verifica esta assinatura contra a chave pública |
d= | Domínio de assinatura | Usado para localizar a chave pública DNS do signatário |
s= | Seletor | Juntamente com o domínio para formar: selector._domainkey.domain |
i= | Identidade de assinatura | Deve ser igual ou subdomínio de d=, identifica a entidade que assina |
Para começar nossa compreensão do DKIM, vamos primeiro olhar para um cabeçalho 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=;
O cabeçalho DKIM-Signature é uma série de pares chave-valor, alguns de maior interesse para o leitor do que outros, mas irei descrever todos eles aqui.
Primeiro, vamos olhar para aqueles que são principalmente de interesse passageiro para o leitor:
v=1; – Especifica a versão do DKIM (1 é o único valor válido)
a=rsa-sha256; – O algoritmo usado para construir os hashes criptográficos
c=relaxed/relaxed; – Existem dois conjuntos de regras sobre remoção de espaços em branco nos cabeçalhos e no corpo que podem ser aplicadas ao criar os hashes em uma assinatura DKIM; essas regras são chamadas de “regras de canonização” (daí a chave c) e os conjuntos de regras são “relaxed” ou “strict”.
t=1454417737; – O carimbo de data/hora de quando a assinatura foi criada.
Essas três partes do cabeçalho contêm as informações reais da assinatura:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este é o hash do corpo da mensagem.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta é uma lista dos cabeçalhos que foram usados para criar os dados da assinatura mostrados abaixo.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Esta é a real assinatura DKIM
Essas três partes são do maior interesse para o servidor receptor que estará validando a assinatura:
d=welcome.foo.com; – Isso identifica o domínio que assinou a mensagem
s=notices; – O seletor; os domínios podem ter múltiplos seletores que usam ao assinar mensagens.
i=@welcome.foo.com; – Esta é a identidade em nome de quem a mensagem foi assinada. Sintaticamente, isso parecerá um endereço de email, e pode até ser um; a parte local do endereço de email pode estar vazia, como neste exemplo, e a parte do domínio deve ser a mesma que ou um subdomínio do domínio na parte d= da assinatura.
A razão pela qual essas partes são de interesse para o servidor receptor é que elas fornecem as informações necessárias para ajudar o receptor a validar as assinaturas.
Campo | Significado | Como os Receptores Usam |
|---|---|---|
v= | versão DKIM (sempre 1) | Confirma o formato da assinatura |
a= | Algoritmo de hashing + assinatura (por exemplo, rsa-sha256) | Garante que o validador reproduza a assinatura corretamente |
c= | Regras de canonização (cabeçalho/corpo) | Normaliza espaços em branco antes de fazer o hash |
t= | Carimbo de data/hora da criação da assinatura | Usado para verificações de frescor e prevenção contra reprodução |
bh= | Hash do corpo | O receptor regenera isso para confirmar a integridade do corpo da mensagem |
h= | Lista de campos de cabeçalho assinados | Garante que os cabeçalhos usados na assinatura estão disponíveis e não foram modificados |
b= | Assinatura DKIM real | O receptor verifica esta assinatura contra a chave pública |
d= | Domínio de assinatura | Usado para localizar a chave pública DNS do signatário |
s= | Seletor | Juntamente com o domínio para formar: selector._domainkey.domain |
i= | Identidade de assinatura | Deve ser igual ou subdomínio de d=, identifica a entidade que assina |
Validação DKIM
Além do requisito mencionado de que o domínio i= deve ser o mesmo que o domínio d= ou um subdomínio do domínio d=, os bits d= e s= são usados pelo validador para procurar a chave pública DKIM do signatário no DNS. A chave é um registro TXT no DNS e sempre é encontrada na localização selector._domainkey.domain. Assim, no nosso exemplo aqui, com s=notices e d=welcome.foo.com, a chave pública DKIM seria encontrada no DNS em notices._domainkey.welcome.foo.com, e pode parecer algo assim:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
O validador usa essa chave (os bits p=) para produzir seu próprio conjunto de hashes da mensagem; se esses hashes coincidirem, então a mensagem não foi alterada durante a transmissão, e assim a mensagem pode contribuir para e, talvez, se beneficiar de qualquer reputação que esteja em vigor para o signatário da mensagem.
Além do requisito mencionado de que o domínio i= deve ser o mesmo que o domínio d= ou um subdomínio do domínio d=, os bits d= e s= são usados pelo validador para procurar a chave pública DKIM do signatário no DNS. A chave é um registro TXT no DNS e sempre é encontrada na localização selector._domainkey.domain. Assim, no nosso exemplo aqui, com s=notices e d=welcome.foo.com, a chave pública DKIM seria encontrada no DNS em notices._domainkey.welcome.foo.com, e pode parecer algo assim:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
O validador usa essa chave (os bits p=) para produzir seu próprio conjunto de hashes da mensagem; se esses hashes coincidirem, então a mensagem não foi alterada durante a transmissão, e assim a mensagem pode contribuir para e, talvez, se beneficiar de qualquer reputação que esteja em vigor para o signatário da mensagem.
Além do requisito mencionado de que o domínio i= deve ser o mesmo que o domínio d= ou um subdomínio do domínio d=, os bits d= e s= são usados pelo validador para procurar a chave pública DKIM do signatário no DNS. A chave é um registro TXT no DNS e sempre é encontrada na localização selector._domainkey.domain. Assim, no nosso exemplo aqui, com s=notices e d=welcome.foo.com, a chave pública DKIM seria encontrada no DNS em notices._domainkey.welcome.foo.com, e pode parecer algo assim:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
O validador usa essa chave (os bits p=) para produzir seu próprio conjunto de hashes da mensagem; se esses hashes coincidirem, então a mensagem não foi alterada durante a transmissão, e assim a mensagem pode contribuir para e, talvez, se beneficiar de qualquer reputação que esteja em vigor para o signatário da mensagem.
Falha de Validação e Solução de Problemas
Eu mencionei acima que falhas de DKIM podem ser difíceis de solucionar, e eu vou explicar por que isso acontece aqui.
Algumas falhas de validação de DKIM têm causas óbvias, como a mensagem não estar assinada, ou a chave pública do domínio assinante não ser encontrada no DNS ou não ser sintaticamente correta, ou talvez a mensagem tenha sido claramente alterada durante a transmissão. Quando esse tipo de falhas acontece, é fácil descobrir o problema e recomendar uma solução. No entanto, as difíceis, e aquelas que levam à experiência de suporte mais frustrante, são os casos em que a mensagem foi assinada, a chave pública existe no DNS, e a mensagem não foi obviamente alterada, mas o validador relata que a assinatura falhou na validação.
A razão pela qual essas são difíceis de solucionar é porque não há realmente uma maneira para nenhum dos lados reproduzir as condições sob as quais a mensagem foi assinada e validada. A mensagem tem em seu cabeçalho DKIM-Signature os hashes que foram gerados pelo signatário no momento da assinatura, mas o validador provavelmente não tem acesso à infraestrutura do signatário e, portanto, não pode tentar reproduzir a assinatura nas condições do signatário. Da mesma forma, o signatário provavelmente não tem acesso à infraestrutura do validador e, portanto, não tem como tentar validar a mensagem da maneira que o validador fez.
Falhas como as que estou descrevendo aqui são ocorrências raras, e falhas de validação de DKIM por si só geralmente não têm um impacto na colocação da entrega. Enquanto o DKIM lida com a autenticação de mensagens, implementar técnicas abrangentes de validação de e-mail garante que você está enviando para endereços legítimos que podem realmente receber e autenticar suas mensagens. Foi minha experiência que tais falhas geram mais chamados de suporte do que qualquer outro tipo de problema de DKIM.
Eu mencionei acima que falhas de DKIM podem ser difíceis de solucionar, e eu vou explicar por que isso acontece aqui.
Algumas falhas de validação de DKIM têm causas óbvias, como a mensagem não estar assinada, ou a chave pública do domínio assinante não ser encontrada no DNS ou não ser sintaticamente correta, ou talvez a mensagem tenha sido claramente alterada durante a transmissão. Quando esse tipo de falhas acontece, é fácil descobrir o problema e recomendar uma solução. No entanto, as difíceis, e aquelas que levam à experiência de suporte mais frustrante, são os casos em que a mensagem foi assinada, a chave pública existe no DNS, e a mensagem não foi obviamente alterada, mas o validador relata que a assinatura falhou na validação.
A razão pela qual essas são difíceis de solucionar é porque não há realmente uma maneira para nenhum dos lados reproduzir as condições sob as quais a mensagem foi assinada e validada. A mensagem tem em seu cabeçalho DKIM-Signature os hashes que foram gerados pelo signatário no momento da assinatura, mas o validador provavelmente não tem acesso à infraestrutura do signatário e, portanto, não pode tentar reproduzir a assinatura nas condições do signatário. Da mesma forma, o signatário provavelmente não tem acesso à infraestrutura do validador e, portanto, não tem como tentar validar a mensagem da maneira que o validador fez.
Falhas como as que estou descrevendo aqui são ocorrências raras, e falhas de validação de DKIM por si só geralmente não têm um impacto na colocação da entrega. Enquanto o DKIM lida com a autenticação de mensagens, implementar técnicas abrangentes de validação de e-mail garante que você está enviando para endereços legítimos que podem realmente receber e autenticar suas mensagens. Foi minha experiência que tais falhas geram mais chamados de suporte do que qualquer outro tipo de problema de DKIM.
Eu mencionei acima que falhas de DKIM podem ser difíceis de solucionar, e eu vou explicar por que isso acontece aqui.
Algumas falhas de validação de DKIM têm causas óbvias, como a mensagem não estar assinada, ou a chave pública do domínio assinante não ser encontrada no DNS ou não ser sintaticamente correta, ou talvez a mensagem tenha sido claramente alterada durante a transmissão. Quando esse tipo de falhas acontece, é fácil descobrir o problema e recomendar uma solução. No entanto, as difíceis, e aquelas que levam à experiência de suporte mais frustrante, são os casos em que a mensagem foi assinada, a chave pública existe no DNS, e a mensagem não foi obviamente alterada, mas o validador relata que a assinatura falhou na validação.
A razão pela qual essas são difíceis de solucionar é porque não há realmente uma maneira para nenhum dos lados reproduzir as condições sob as quais a mensagem foi assinada e validada. A mensagem tem em seu cabeçalho DKIM-Signature os hashes que foram gerados pelo signatário no momento da assinatura, mas o validador provavelmente não tem acesso à infraestrutura do signatário e, portanto, não pode tentar reproduzir a assinatura nas condições do signatário. Da mesma forma, o signatário provavelmente não tem acesso à infraestrutura do validador e, portanto, não tem como tentar validar a mensagem da maneira que o validador fez.
Falhas como as que estou descrevendo aqui são ocorrências raras, e falhas de validação de DKIM por si só geralmente não têm um impacto na colocação da entrega. Enquanto o DKIM lida com a autenticação de mensagens, implementar técnicas abrangentes de validação de e-mail garante que você está enviando para endereços legítimos que podem realmente receber e autenticar suas mensagens. Foi minha experiência que tais falhas geram mais chamados de suporte do que qualquer outro tipo de problema de DKIM.
