Validação DKIM: Uma Melhoria de Autenticação de Emails

Email

·

Validação DKIM: Uma Melhoria de Autenticação de Emails

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?

    1. Extrai os valores de d= e s=.

    2. Procura a chave pública em:

    selector._domainkey.domain
    selector._domainkey.domain
    selector._domainkey.domain
    1. Regenera os hashes do cabeçalho e do corpo.

    2. 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.

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.

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.

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.

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.

Outras notícias

Saiba mais sobre esta categoria

A person is standing at a desk while typing on a laptop.

A plataforma completa nativa de IA que escalará com o seu negócio.

© 2026 Pássaro

A person is standing at a desk while typing on a laptop.

A plataforma completa nativa de IA que escalará com o seu negócio.

© 2026 Pássaro