DKIM fail indica que o destinatário não conseguiu validar uma assinatura DKIM. O resultado merece investigação, mas não determina sozinho a confiabilidade da mensagem nem sua chegada à caixa de entrada. Para coordenar SPF, DKIM, DMARC, rotas e caixas, comece pelo guia de e-mail empresarial.
A mensagem parece normal na saída, mas Gmail, Microsoft ou Yahoo mostram dkim=fail. Isso pode afetar a filtragem ou a aceitação, junto com outros sinais. É necessário descobrir se o erro está no DNS, no sistema de envio ou em um equipamento que modifica a mensagem durante o trânsito.
Trate a falha como um incidente de autenticação: leia o resultado, identifique a categoria, confira seletor e chave e investigue o que ocorreu depois da assinatura. Corrija o ponto comprovado, sem alterar registros por tentativa e erro.
O que DKIM fail realmente significa?
Um resultado DKIM inválido significa que a assinatura não foi validada. Alterações do conteúdo podem produzir fail; uma chave ausente ou inválida pode produzir permerror; um erro temporário de consulta DNS, temperror. Diferencie os resultados e confira se as chaves pública e privada correspondem.
A RFC 6376 define o hash do corpo em bh= e a assinatura em b=. Se a verificação falha, a assinatura não passa. Isso não comprova necessariamente falsificação: assinatura cedo demais na rota, chave incorreta ou alterações posteriores também podem explicar o resultado.
Pense no DKIM como um lacre: se não pode ser verificado, é preciso investigar por quê. Um lacre inválido não prova sozinho que todo o pacote seja malicioso.
Examine primeiro Authentication-Results na mensagem recebida. O exemplo abaixo reúne resultados ilustrativos inconsistentes como situação normal: com SPF válido e alinhado ao mesmo domínio From, o DMARC normalmente deveria passar mesmo com falha DKIM.
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
spf=pass smtp.mailfrom=example.com;
dmarc=fail header.from=example.comAntes de alterar o remetente, compare sua configuração com os registros DNS obrigatórios do TrekMail.
Quatro categorias comuns de falhas DKIM
O diagnóstico costuma se concentrar no hash do corpo, no seletor ou na chave, no formato DNS e nas alterações de encaminhamentos ou relays. Classificar primeiro evita trocar chaves quando o problema está em outro ponto.
| Resultado de autenticação | Possível significado | Primeira verificação |
|---|---|---|
dkim=fail (body hash did not verify) | O corpo assinado não corresponde após a canonicalização | Relays de saída, avisos legais, links e canonicalização |
dkim=fail (signature did not verify) | Chaves diferentes, cabeçalhos alterados ou outro erro de assinatura | Seletor, rotação recente, remetente e cabeçalhos assinados |
dkim=permerror (no key for signature) | Não foi obtida uma chave pública utilizável | Nome do seletor, caches DNS e formato do registro |
dkim=temperror | Erro temporário de DNS ou do resolvedor | DNS autoritativo, TTL e disponibilidade dos servidores |
A tabela orienta a triagem. Depois confirme a causa com os dados da mensagem e do DNS.
Tipo de falha 1: divergência no hash do corpo
O hash recalculado do corpo recebido, após a canonicalização indicada na assinatura, não corresponde ao hash assinado. Não é sempre uma comparação byte a byte, e esse resultado não comprova que o DNS esteja correto.
Segundo a RFC 6376, se o hash recalculado não corresponde a bh=, essa verificação falha permanentemente. Confira alterações posteriores à assinatura, a configuração do signatário e a integridade da amostra analisada.
Causas comuns:
- Microsoft 365, Exchange ou gateways acrescentam avisos legais depois da assinatura.
- Mimecast, Barracuda, Proofpoint ou outros filtros reescrevem links.
- Um relay altera espaços ou finais de linha além do que a canonicalização tolera.
- Uma aplicação assina antes de um gateway mudar limites MIME ou inserir avisos como
[External].
Confira c=. O modo c=simple/simple tolera menos alterações que o relaxado. A canonicalização relaxada do corpo descrita na RFC 6376 ignora espaços no fim das linhas e agrupa espaços repetidos dentro delas. Isso ajuda com determinadas mudanças de formatação, mas não corrige alterações substanciais do conteúdo.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=tm1; h=from:to:subject:date:mime-version;
bh=...; b=...Uma melhoria de arquitetura é assinar no fim da rota que você controla, depois de rodapés, reescritas e regras de conformidade. Isso reduz alterações internas posteriores, mas não garante que intermediários externos preservem os dados assinados.
Se você encaminha mensagens, consulte configuração de encaminhamento de e-mail e encaminhar e-mail de domínio ao Gmail. Uma rota testada pode se comportar de outra forma quando surgem novos intermediários.
Tipo de falha 2: seletor ou chaves incorretos
A assinatura pode indicar um seletor sem chave utilizável, ou a pública no DNS pode não corresponder à privada do remetente. Esse é um problema de configuração; outras falhas de assinatura podem vir de cabeçalhos assinados que foram alterados.
Localize o domínio e o seletor na assinatura:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...Consulte exatamente esse seletor:
dig txt k1._domainkey.example.com +shortUma resposta vazia pode decorrer de registro ausente, nome incorreto, caches ou erros de consulta. Confira o estado DNS antes de concluir. Se obtiver uma chave, compare com a esperada pelo remetente atual. Em migrações ou ambientes mistos, outro sistema pode continuar usando uma privada antiga.
Isso pode ocorrer com vários remetentes para um domínio: aplicações via SES, suporte via Microsoft 365 e campanhas por outro ESP. Uma rotação mal coordenada pode gerar falhas intermitentes.
Com envio gerenciado do TrekMail, consulte Managed TrekMail SMTP e confira onde a assinatura ocorre na rota disponível. Com Nano ou um remetente externo, veja SMTP próprio (BYO): o serviço que realmente envia precisa ser configurado para assinar.
Tipo de falha 3: publicação incorreta de chaves longas
Uma chave de 2048 bits pode ser publicada incorretamente se a interface tratar mal o TXT. O resultado pode ser permerror, erro de formato ou uma chave incompleta na resposta.
A RFC 8301 exige chaves RSA de pelo menos 1024 bits e recomenda pelo menos 2048 bits. Essa orientação criptográfica não garante compatibilidade com todos os painéis DNS.
Confira se as strings TXT pertencem a um único registro, sem truncamento ou aspas incorretas. O exemplo ilustra a estrutura; os fragmentos não formam uma chave utilizável.
; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"restOfThePublicKeyContinuesHere..."
)Consulte o DNS e examine todas as strings, não apenas o primeiro fragmento:
dig txt k1._domainkey.example.com +shortRevise esse ponto principalmente após trocar o provedor DNS, mover zonas ou copiar registros à mão. Compare a resposta completa com a chave esperada.
Tipo de falha 4: encaminhamento, relays e falta de alinhamento
Um intermediário pode invalidar DKIM ao alterar dados assinados, enquanto SPF pode falhar com a nova rota. DMARC falha se não restar outra autenticação válida e alinhada; a aceitação ainda depende da política do destinatário.
Imagine uma mensagem de example.com enviada a uma universidade que encaminha ao Gmail. SPF pode falhar porque o encaminhador não está autorizado pelo domínio original. DKIM pode sobreviver se os dados assinados forem preservados; um rodapé, link reescrito ou alteração em um assunto assinado pode invalidá-lo. DMARC falha se também não houver outro resultado válido e alinhado.
Para remetentes gerais a contas pessoais do Gmail, o Google exige SPF ou DKIM; para remetentes em massa, ambos e DMARC, com o alinhamento aplicável. Encaminhamentos e listas têm particularidades; ARC pode transportar resultados anteriores. O destinatário decide se confia em ARC, que não garante aceitação nem corrige a assinatura original.
Se encaminha mensagens, considere SRS e uma rota que preserve os dados assinados. Conforme a configuração disponível, o TrekMail pode usar SRS para validar SPF com o novo remetente do envelope. SRS não restaura o alinhamento com o From original nem substitui DKIM.
Com muitos aliases, leia encaminhamento de aliases e e-mail com domínio próprio. A rota real de cada mensagem importa mais que a quantidade de aliases.
Onde verificar quando aparece DKIM fail
Use uma sequência repetível: resultado de autenticação, consulta do seletor, rota de assinatura e alinhamento. Isso ajuda a distinguir erros DNS de alterações posteriores sem mudar a configuração errada.
- Abra a mensagem original e localize
Authentication-Results. Anote o resultado DKIM exato. - Encontre
d=,s=ec=no cabeçalhoDKIM-Signature. - Consulte o seletor com
dige confira o nomeselector._domainkey.example.com. - Confirme qual plataforma assina de fato. Vários remetentes podem causar falhas intermitentes.
- Confira se um gateway, filtro ou encaminhador altera o corpo ou os cabeçalhos assinados.
- Confira o alinhamento:
d=deve estar alinhado ao domínioFrom:visível para que DKIM contribua para aprovar DMARC, conforme o modo relaxado ou estrito.
Outra precaução: colar fragmentos em um verificador externo pode gerar falsos erros de hash. Analise a mensagem original completa ou um arquivo .eml exportado sem alterações.
Corrigir DKIM fail com um fluxo coordenado no TrekMail
Ajustar DNS, relays e rodapés em vários provedores exige identificar quem assina e quando. Um fluxo coordenado assina no fim da rota controlada, verifica o DNS e diferencia envio gerenciado de SMTP próprio.
| Problema comum | Abordagem coordenada |
|---|---|
| Vários saltos internos alteram mensagens já assinadas | Assinar depois das alterações no último gateway controlado |
| Rotação manual em diferentes ferramentas | Conferir a gestão de assinatura e chaves do SMTP gerenciado disponível |
| Alterações DNS com SPF duplicado ou seletores incorretos | Usar registros consistentes e verificar cada um |
| Encaminhamento sem considerar SRS ou ARC | Preservar a autenticação quando possível e avaliar os mecanismos aplicáveis |
O TrekMail diferencia Nano com SMTP próprio dos planos pagos com envio gerenciado, conforme suas condições. Como referência, estes são anunciados a partir de $3.50 por mês. Para assinatura de saída gerenciada pelo TrekMail, confirme o plano e a rota disponíveis. Se sua configuração SES, SendGrid ou Mailgun assina, investigue DKIM nesse serviço. Os planos pagos podem oferecer uma avaliação de 14 dias que exige cartão. Consulte os termos vigentes em preços do TrekMail.
Com SMTP próprio, a investigação costuma envolver seletor, chaves e alterações da rota externa. Confira os dados antes de atribuir o problema à caixa ou a um provedor específico.
Checklist final para um incidente DKIM fail
Trate DKIM fail como um erro específico de verificação, não como explicação universal da entregabilidade. Leia o resultado, consulte o seletor e examine a rota antes de alterar a configuração.
Antes de mudar a produção:
- Leia o cabeçalho completo, não apenas o resumo de uma devolução.
- Diferencie hash do corpo, verificação de assinatura, permerror e temperror.
- Consulte o seletor exato no DNS.
- Confira se a chave está completa e as strings formam o registro correto.
- Assine no fim da rota controlada se houver alterações posteriores.
- Considere
c=relaxed/relaxedpara mudanças de formatação compatíveis, não alterações substanciais. - Confira o alinhamento DMARC entre
d=e o domínioFrom:visível.
Se a falha persistir, investigue a causa em vez de esperar sem dados. Corrija o ponto de assinatura, o seletor ou o intermediário responsável e confirme o resultado com mensagens reais.
