Verificador de DKIM:
a sua chave é suficientemente forte?

Introduza o domínio acima — o seletor é opcional. Vamos buscar o registo TXT em selector._domainkey.yourdomain (sondando dez seletores comuns se o deixar em branco), analisamos cada tag face à RFC 6376 e depois validamos a própria chave: o valor p= é descodificado em base64, a estrutura DER interna é percorrida campo a campo, e o módulo é medido e classificado — abaixo de 1024 bits é fraca, 1024 é aceitável, 2048+ é recomendado. Grátis, sem registo.

O seletor é o nome que vem antes de ._domainkey — escolhido por quem configurou a assinatura, invisível a qualquer listagem de DNS. Três formas de encontrar o seu: abra uma mensagem que enviou e leia a tag s= no cabeçalho DKIM-Signature («Mostrar original» no Gmail); cole esse cabeçalho completo nesta ferramenta e nós extraímo-lo; ou deixe o seletor em branco e sondamos as dez predefinições mais comuns — google, selector1/2, k1/k2, s1/s2, default, dkim, mail. Encontrar dois seletores ativos é normal — é a rotação a funcionar.

Aceitável, envelhecida, e vale a pena agendar a substituição. Ninguém fatorizou publicamente o RSA-1024 — mas o NIST proibiu-o para novas assinaturas em 2013, a RFC 8301 diz aos signatários DKIM que devem usar 2048, e os grandes fornecedores de correio assinam eles próprios com 2048. O 1024 não é a emergência — essa é a de 512, fatorizada em 2012 com computação na nuvem alugada. É a chave que roda segundo o seu próprio calendário, em vez de, eventualmente, o de um atacante.

Modo de teste. A RFC 6376 §3.6.1 instrui os verificadores a tratarem o correio de um domínio em modo de teste exatamente como correio não assinado — mesmo quando a assinatura verifica na perfeição. Existe para permitir testar o DKIM durante o lançamento sem consequências. O problema é que funciona bem demais: nada se avaria enquanto está ativo, por isso nunca é removido. O domínio passa então anos a assinar correio sem qualquer benefício. Se esta ferramenta encontrar um, a correção é eliminar quatro caracteres.

Uma revogação deliberada. A RFC 6376 define um p= vazio como «esta chave pública foi revogada». É o sinal formal correto para um seletor retirado, e mais claro do que eliminar o registo, que fica indistinguível de um erro de escrita. Daqui resultam duas leituras. Se já rodou para outro seletor e nada assina com este, é boa prática: deixe-o assim. Se algum remetente ainda assinar com ele, todas essas mensagens estão a falhar o DKIM neste momento. Verifique os seus relatórios DMARC à procura de dkim=fail com este seletor.

Os verificadores têm de suportar até 4096 bits (RFC 8301). Mas uma chave de 4096 bits produz um valor TXT longo o suficiente para exigir divisão em várias strings, o que algumas interfaces de fornecedores de DNS estragam. Não traz segurança prática adicional face aos 2048 bits para uma chave que deve rodar de qualquer forma, por isso 2048 é o ponto ideal. A outra direção é k=ed25519 (RFC 8463): chaves minúsculas de 32 bytes, criptografia moderna. O suporte dos verificadores ainda não é universal, por isso as implementações que o usam costumam assinar em duplicado com RSA. Esta ferramenta lê k= e diz qual publicou.

Sozinha — não, e preferimos dizê-lo já. O DKIM prova duas coisas: que a mensagem não foi alterada desde a assinatura, e que o domínio em d= a apadrinha. Não prova que a linha From: que o destinatário vê corresponde a esse domínio — um falsificador pode assinar impecavelmente com o seu próprio domínio enquanto mostra o seu. Fechar essa lacuna é trabalho do DMARC (alinhamento), e dizer que servidores podem enviar de todo é trabalho do SPF. A combinação que funciona é SPF + DKIM + DMARC. Esta ferramenta garante que a parte do DKIM é real — uma chave revogada ou em modo de teste enfraquece silenciosamente as outras duas.