Como verificar o DKIM do e-mail de uma aplicação?

Trate a verificação de DKIM como quatro testes separados

Uma consulta DNS sozinha não é uma verificação completa de DKIM. Primeiro, confirme que a mensagem contém um campo DKIM-Signature e identifique a assinatura que você pretende testar. Segundo, obtenha e interprete o registro de chave pública indicado por essa assinatura. Terceiro, verifique se os cabeçalhos assinados e o corpo canonicalizado ainda correspondem à assinatura criptográfica. Quarto, determine se um domínio de assinatura aprovado está alinhado com o domínio From visível para o DMARC. Essas camadas respondem a perguntas diferentes. Um registro publicado pode não estar em uso, uma mensagem pode referenciar um seletor inexistente, uma assinatura pode falhar depois de o conteúdo ser modificado e uma aprovação criptográfica pode continuar desalinhada com o domínio do autor. Registre cada resultado, em vez de apresentar um único selo verde. Mantenha separados também os estados de transporte e de caixa postal: a aceitação pelo provedor, a aceitação pelo servidor de destino e a chegada à caixa de entrada não são resultados da verificação de DKIM.

Comece pela assinatura de uma mensagem real

Obtenha a mensagem bruta de um destinatário controlado alcançado pelo caminho normal da aplicação. Em cada campo DKIM-Signature, registre o domínio de assinatura `d=`, o seletor `s=`, o algoritmo `a=`, os modos de canonicalização `c=`, a lista de cabeçalhos assinados `h=`, o hash do corpo `bh=`, os dados da assinatura `b=` e os timestamps, quando presentes. A RFC 6376 define as tags de domínio de assinatura e de seletor e as usa para localizar a chave pública. Não adivinhe o seletor a partir do painel de um provedor nem consulte `_domainkey` sem ele. Uma mensagem pode carregar várias assinaturas de um remetente, de um intermediário ou de um sistema de listas de e-mail, então preserve o resultado de cada assinatura. Evite colar mensagens de produção em verificadores públicos: cabeçalhos e corpos brutos podem expor destinatários, identificadores de mensagem, detalhes de roteamento, tokens de descadastro e conteúdo da aplicação. Use armazenamento restrito e uma cópia de diagnóstico com dados ocultados quando o conteúdo completo não for necessário.

Consulte o seletor e o domínio de assinatura exatos

Monte o nome DNS a partir da assinatura como `<selector>._domainkey.<signing-domain>`. Se o cabeçalho contiver `s=app2026` e `d=notify.example.test`, consulte o TXT em `app2026._domainkey.notify.example.test`. Registre o nome original, o resolvedor, a resposta, o TTL e qualquer cadeia de CNAME. Interprete o registro tag-valor resultante, em vez de procurar um fragmento de texto. O registro pode declarar a versão, o tipo de chave, a restrição de serviço, flags, algoritmos de hash e os dados da chave pública. Um valor de chave pública vazio revoga a chave. Diferencie NXDOMAIN, resposta vazia, conteúdo malformado, algoritmo não suportado, chave inutilizável e falha transitória do resolvedor. Repita uma consulta alterada depois que o TTL expirar, usando um resolvedor independente, mas não presuma que todos os destinatários já se atualizaram. O sucesso no DNS prova apenas que um registro foi retornado naquele momento; não prova que a mensagem testada é verificada nem que o provedor está assinando o tráfego atual com esse seletor.

Verifique os cabeçalhos, o hash do corpo e a assinatura

A verificação de DKIM segue as regras de canonicalização declaradas na assinatura. O verificador canonicaliza o corpo, calcula o hash e o compara com `bh=`. Ele também canonicaliza os cabeçalhos assinados listados em `h=`, incorpora o campo DKIM-Signature conforme especificado e verifica `b=` com a chave pública. Use uma biblioteca de verificação mantida ou o resultado de autenticação confiável de um destinatário, em vez de recriar essas transformações com operações de string. Uma divergência no hash do corpo geralmente significa que o corpo mudou depois da assinatura, enquanto uma falha na assinatura dos cabeçalhos pode indicar modificação de cabeçalhos assinados, chave errada, dados de assinatura corrompidos ou erro de implementação. Registre qual fase falhou. Verifique se campos importantes como From, Subject, Date e Message-ID foram assinados, mas não invente uma política universal de cabeçalhos assinados. A canonicalização tolera alterações de formatação definidas; ela não torna seguras a inserção arbitrária de rodapés, a reescrita de MIME, danos nas quebras de linha ou modificações no transporte.

Leia os resultados do destinatário dentro da fronteira de confiança dele

A RFC 8601 define o cabeçalho Authentication-Results e os resultados de DKIM, incluindo none, pass, fail, policy, neutral, temperror e permerror. Um pass significa que o destinatário encontrou uma assinatura aceitável que passou nos testes de verificação. Um temperror pode refletir uma condição que tende a mudar, como uma falha temporária na consulta da chave; um permerror dificilmente terá sucesso em uma tentativa posterior sem correção. Registre o serviço de autenticação que reportou, o domínio de assinatura, o seletor e o algoritmo, quando informados. Confie apenas em resultados inseridos dentro da fronteira documentada do sistema de destino, porque um remetente pode adicionar um campo Authentication-Results forjado antes da transmissão. Examine o resultado confiável mais acima para o ambiente de destino final e leve em conta os saltos intermediários. Se destinatários diferentes discordarem, compare a versão exata da mensagem, a visão do DNS, o horário da avaliação, os algoritmos suportados e a política local. Não transforme `dkim=pass` em uma afirmação de que o provedor de caixa de entrada aprovou o conteúdo ou o colocou na caixa de entrada.

Verifique o alinhamento DMARC separadamente do pass do DKIM

Um pass do DKIM autentica o domínio de assinatura em `d=`; ele não exige que esse domínio seja igual ao domínio From visível da RFC 5322. A RFC 9989 usa um identificador autenticado por DKIM aprovado para o DMARC somente quando ele está alinhado com o domínio do autor, no modo de alinhamento aplicável, strict ou relaxed. Por exemplo, uma mensagem de `billing.example.test` assinada com `d=provider.test` pode passar no DKIM, mas continuar desalinhada. Uma assinatura válida de `d=example.test` pode estar alinhada no modo relaxed, dependendo do cálculo do domínio organizacional e da política. Informe três campos: resultado do DKIM, domínio de assinatura e decisão de alinhamento. Uma mensagem também pode passar no DMARC por meio de SPF alinhado quando o DKIM falha ou está desalinhado, então um pass no DMARC não prova que aquela assinatura DKIM específica passou. As diretrizes atuais do Gmail para remetentes incluem requisitos de autenticação e alinhamento para o tráfego aplicável, mas cumpri-los ainda não garante a aceitação pelo servidor de destino nem a chegada à caixa de entrada.

Verifique os algoritmos atuais e a rotação de chaves

A RFC 8301 atualiza os requisitos criptográficos do DKIM: os signatários devem usar `rsa-sha256`, os verificadores devem suportá-lo e `rsa-sha1` não deve ser usado. Ela também exige chaves de assinatura RSA de pelo menos 1024 bits, explicando por que chaves maiores são preferíveis quando isso é viável na operação. Um verificador deve identificar o algoritmo e sinalizar material obsoleto ou inutilizável, sem afirmar que o tamanho da chave, por si só, torna um fluxo de e-mail confiável. Os fluxos dos provedores variam. O Amazon SES documenta que o Easy DKIM usa chaves de 2048 bits por padrão e alerta que mudar o método de assinatura sem uma etapa intermediária pode criar um período em que as mensagens não são assinadas com DKIM. Planeje a rotação com dois seletores válidos ou com o mecanismo de sobreposição documentado pelo provedor, confirme que as novas mensagens usam o novo seletor, mantenha a chave pública antiga enquanto e-mails atrasados ainda puderem chegar e remova-a somente após o período de sobreposição. Nunca publique a chave privada de assinatura no DNS, em logs, em tickets ou em prompts.

Diagnostique falhas partindo da mensagem

Quando uma verificação falhar, preserve a mensagem bruta e o resultado do destinatário antes de alterar o DNS. Confirme que a aplicação e o provedor esperados realmente produziram a mensagem. Se não houver assinatura, verifique se a assinatura estava habilitada para aquela identidade, região, tenant ou classe de mensagem. Se a consulta do seletor falhar, compare os valores exatos de `d=` e `s=`, a zona DNS, o destino do CNAME, o TTL e rotações recentes. Se a chave for interpretada, mas o hash do corpo falhar, verifique gateways, rodapés de listas, reescritas de rastreamento, transformações de MIME, quebras de linha e produtos de segurança que possam modificar o conteúdo depois da assinatura. Se a assinatura criptográfica falhar com o hash do corpo correto, inspecione mudanças em cabeçalhos assinados, incompatibilidade de chave e a implementação da assinatura. Se o DKIM passar, mas o DMARC falhar, teste o alinhamento em vez de republicar a mesma chave. Teste novamente com destinatários controlados depois do TTL ou da propagação da configuração correspondente e registre evidências para cada classe de mensagem, em vez de declarar o domínio inteiro corrigido a partir de uma única amostra bem-sucedida.

Mantenha um registro auditável das verificações de DKIM

Para cada mensagem controlada, guarde um identificador de correlação não sensível, o sistema de envio, a conta ou workspace do provedor, o domínio From visível, o sistema de destino, o horário da mensagem e o resultado completo de cada assinatura. Inclua `d=`, `s=`, `a=`, a canonicalização, os cabeçalhos assinados, o nome da consulta DNS, o horário e o TTL da resposta DNS, o status do registro da chave, o resultado do hash do corpo, o resultado da assinatura, o valor confiável de Authentication-Results, a decisão de alinhamento DMARC e o responsável pela correção. Armazene mensagens brutas apenas onde houver controles adequados de acesso e retenção. Acrescente o cenário do teste: envio normal da aplicação, migração de provedor, rotação de chave, caminho por gateway ou caso de encaminhamento. Isso torna as regressões comparáveis e impede que uma captura de tela vire prova permanente depois que os seletores ou o processamento das mensagens mudarem. Verifique novamente após mudanças na configuração do provedor, no DNS, no método de assinatura, no roteamento ou após uma nova classe de mensagem. Um painel operacional deve mostrar explicitamente os estados desconhecido e indisponível, em vez de tratá-los silenciosamente como pass ou fail.

Entenda como o SendHQ se encaixa na verificação

O SendHQ exige um domínio From verificado e fornece eventos de entrega. Para uma verificação de DKIM, envie uma mensagem controlada pelo caminho pretendido da aplicação, inspecione a assinatura recebida, consulte os valores reais de `d=` e `s=` e registre o alinhamento separadamente. Não infira um seletor, tamanho de chave, algoritmo de assinatura, chegada à caixa de entrada ou garantia de entrega apenas pela documentação do produto.

Perguntas frequentes

Fontes

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor (em inglês)
• RFC 8301: Cryptographic Algorithm and Key Size Update to DomainKeys Identified Mail (DKIM) — RFC Editor (em inglês)
• RFC 8601: Authentication-Results Header Field — RFC Editor (em inglês)
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (em inglês)
• Gmail Email Sender Guidelines — Google (em inglês)
• Easy DKIM in Amazon SES — Amazon Web Services (em inglês)
• Contrato OpenAPI do SendHQ — SendHQ