O DKIM (DomainKeys Identified Mail) é uma assinatura digital que o domínio remetente acrescenta a cada email. Permite ao servidor de destino verificar que a mensagem vem mesmo desse domínio e que não foi alterada pelo caminho, o que limita a usurpação de identidade (spoofing) e pesa na entregabilidade. A IETF normalizou-o em 2007 (RFC 4871) e reviu-o em 2011 (RFC 6376).
O que verifica exatamente um servidor quando escreve dkim=pass no cabeçalho de uma mensagem? Constata que uma assinatura anexada pelo domínio remetente corresponde a uma chave pública publicada no DNS desse domínio, e que o corpo da mensagem não mudou durante o trânsito. Mais nada. Um painel de emailing que mostra «DKIM OK» não diz, portanto, nada sobre a lista visada nem sobre a reputação do IP.
Desde 1 de fevereiro de 2024, a Google exige autenticação SPF, DKIM e DMARC aos remetentes que enviam mais de 5 000 mensagens por dia para o Gmail. Este guia lê uma assinatura campo a campo, mostra o registo a publicar e detalha depois o teste e as causas de falha.
O cabeçalho DKIM-Signature, campo a campo
Abra o original de um email recebido: o cabeçalho tem este aspeto (valores ilustrativos, assinatura encurtada).
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exemplo.pt; s=s1; t=1760000000; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Zm9ybWF0IGQnaWxsdXN0cmF0aW9u...
Cada etiqueta responde a uma definição da RFC 6376, publicada pela IETF em setembro de 2011.
| Etiqueta | Valor de exemplo | Função |
|---|---|---|
| v | 1 | Versão da especificação DKIM |
| a | rsa-sha256 | Algoritmo de assinatura: RSA e hash SHA-256 |
| c | relaxed/relaxed | Canonização dos cabeçalhos e do corpo (tolerância a espaços e quebras de linha) |
| d | exemplo.pt | Domínio assinante, comparado com o domínio do From para o alinhamento DMARC |
| s | s1 | Seletor, que designa a chave a obter no DNS |
| t | 1760000000 | Data e hora Unix da assinatura (9 de outubro de 2025 às 08:53 UTC) |
| h | from:to:subject:date:message-id | Lista dos cabeçalhos cobertos pela assinatura |
| bh | 47DEQpj8… | Hash do corpo da mensagem |
| b | Zm9ybWF0… | Assinatura, calculada sobre os cabeçalhos listados em h |
Há duas etiquetas que se confundem com frequência. A bh contém o hash do corpo, a b a própria assinatura, calculada sobre os cabeçalhos de h e sobre o cabeçalho DKIM-Signature (com b vazio). Um hash SHA-256 ocupa 32 bytes, o que dá 44 carateres em base64 em bh. Um corpo alterado num único byte quebra a bh; um cabeçalho assinado e alterado quebra a b. O algoritmo rsa-sha1 está proscrito desde a RFC 8301 (janeiro de 2018): uma assinatura moderna mostra rsa-sha256. A etiqueta opcional l, que limita o assinado a um número de bytes do corpo, deixa a porta aberta ao acréscimo de conteúdo depois da parte coberta; a RFC 6376 descreve a sua má utilização na secção 8.2.
Da assinatura à verificação: quem faz o quê
O vocabulário corrente («cifrar o hash com a chave privada») baralha os papéis. Na prática, a sequência tem quatro tempos.
- O servidor de envio (MTA) canoniza o corpo, calcula o hash SHA-256 e coloca-o em bh.
- Calcula o hash dos cabeçalhos listados em h e o do próprio cabeçalho DKIM-Signature, depois assina o resultado com a chave privada. Essa assinatura passa a ser b. A chave privada nunca sai do servidor de envio.
- O servidor de destino lê d e s, consulta o DNS em s._domainkey.d e obtém a chave pública. O remetente já não intervém nesta fase.
- O destinatário recalcula o hash do corpo e compara-o com bh, depois verifica b com a chave pública. Os dois controlos coincidem: dkim=pass.
Seletor e registo TXT: onde a chave é publicada
O seletor, valor da etiqueta s, constrói o nome DNS que o destinatário vai consultar: s._domainkey.d. Para s=s1 e d=exemplo.pt, a consulta incide sobre s1._domainkey.exemplo.pt, onde se espera um registo TXT.
s1._domainkey.exemplo.pt. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
A etiqueta v anuncia a versão, k o tipo de chave, p a chave pública em base64. Um p vazio indica uma chave revogada. O início do valor denuncia o tamanho: MIIBIjANBgkq… corresponde a uma chave RSA de 2048 bits, MIGfMA0GCSqG… a uma chave de 1024 bits.
A RFC 8301 impõe aos assinantes chaves RSA de pelo menos 1024 bits e recomenda 2048 bits. Uma chave de 1024 bits ocupa cerca de 216 carateres. Uma chave de 2048 bits pesa 392 carateres em base64: excede os 255 carateres de uma cadeia DNS, pelo que o registo tem de ser dividido em várias cadeias entre aspas, o que algumas interfaces DNS fazem sozinhas e outras não. Cada ferramenta de envio (Google Workspace, um CRM, um ESP) recebe o seu próprio seletor sob o mesmo domínio, o que explica que uma zona contenha vários.
Última armadilha: consoante a interface, o campo «nome do anfitrião» espera s1._domainkey sozinho ou o nome completo. Introduzir o nome completo onde o domínio é acrescentado automaticamente produz s1._domainkey.exemplo.pt.exemplo.pt, que o destinatário não consegue encontrar. Este registo vive na mesma zona que os outros registos DNS do remetente (SPF, MX, DMARC): uma só interface a alterar, um só proprietário da zona a identificar.
Configurar o DKIM no Google Workspace, no Microsoft 365 ou num ESP
No Google Workspace, o caminho passa pela consola de administração: Aplicações > Google Workspace > Gmail > Autenticar email. O botão «Gerar novo registo» cria o par de chaves; copia-se o valor TXT para a zona DNS e inicia-se a autenticação. Depois de ativar o Gmail, a chave só aparece na consola ao fim de 24 a 72 horas, segundo a documentação de ajuda do Google Workspace.
O Microsoft 365 (Office 365 nas documentações antigas) procede de outra forma. O portal Microsoft Defender (security.microsoft.com), na secção «Email authentication settings», fornece dois seletores chamados selector1 e selector2, a publicar em CNAME para registos alojados pela Microsoft, segundo o modelo selector1-exemplo-pt._domainkey.locatario.onmicrosoft.com. Só um dos dois seletores assina de cada vez, o outro aguarda a próxima rotação: a mudança faz-se sem interrupção.
Com um ESP, a plataforma fornece os registos TXT ou CNAME a copiar. Enquanto a zona DNS não os contiver, o ESP assina com o seu próprio domínio: o teste mostra dkim=pass. O domínio d não corresponde, porém, ao From, pelo que a assinatura não conta para o DMARC. Efeito idêntico com uma gateway de saída que acrescenta um rodapé: o corpo muda depois da assinatura, um caso que a documentação do Google Workspace refere expressamente.
Testar o DKIM: ler o Authentication-Results
Envie uma mensagem de teste para uma caixa Gmail, abra o menu de três pontos da mensagem e escolha Mostrar original. O Gmail apresenta aí «DKIM: PASS» com o domínio e detalha depois o veredito no cabeçalho Authentication-Results.
Authentication-Results: mx.google.com; dkim=pass header.i=@exemplo.pt header.s=s1 header.b=Zm9ybWF0; spf=pass smtp.mailfrom=exemplo.pt; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=exemplo.pt
Na linha dkim, header.s indica o seletor utilizado, header.i a identidade assinante, header.b os primeiros carateres da assinatura. Este formato é o da RFC 8601. Os vereditos possíveis: pass, fail (assinatura inválida), none (nenhuma assinatura), neutral, temperror e permerror (erro DNS passageiro ou definitivo).
Para isolar um problema de DNS antes de qualquer envio, o comando dig +short TXT s1._domainkey.exemplo.pt devolve o valor publicado; uma ferramenta de teste DKIM em linha (dkim lookup, dkim checker) faz o mesmo pedido com o valor de s do cabeçalho.
Porque falha uma assinatura DKIM
Um dkim=fail deve-se quase sempre a um destes casos.
- O corpo mudou depois da assinatura: rodapé acrescentado por um relay. A bh deixa de corresponder.
- O seletor não é encontrado: erro de escrita ou nome de anfitrião duplicado com o domínio.
- A chave pública está truncada: TXT de 2048 bits não dividido.
- A chave privada foi regenerada no fornecedor sem atualização do DNS.
- A mensagem passa por uma lista de distribuição ou um reencaminhamento que reescreve o assunto ou acrescenta um rodapé: a assinatura de origem já não cobre o conteúdo recebido.
- A assinatura passa, mas o domínio d difere do domínio do From: o DMARC rejeita-a por falta de alinhamento.
Alinhamento DMARC e exigências do Gmail e do Yahoo
O Yahoo aplica as suas exigências desde fevereiro de 2024: o seu Sender Hub pede que o domínio do From esteja alinhado com o domínio SPF ou com o domínio DKIM (boas práticas do Yahoo). No modo relaxed, valor por defeito, um d=news.exemplo.pt alinha com um From em exemplo.pt; o modo strict (adkim=s) exige a identidade exata, segundo a RFC 7489 de 2015. Uma mensagem enviada por um ESP com d=mailer.esp-exemplo.com e um From em @exemplo.pt falha, portanto, o alinhamento DKIM; se o Return-Path também pertencer ao ESP, o SPF falha igualmente. Sob uma política DMARC em p=reject, uma mensagem cujo SPF e DKIM não estejam alinhados é rejeitada.
Os limiares diferem consoante o volume. Para qualquer remetente para o Gmail, a Google pede SPF ou DKIM desde 1 de fevereiro de 2024; acima de 5 000 mensagens por dia, SPF e DKIM são ambos exigidos. A Google pede também um DMARC publicado (p=none basta), registos DNS direto e inverso válidos e uma ligação TLS; o formato das mensagens segue a RFC 5322. Quanto à reputação, a página visa uma taxa de spam abaixo de 0,10% no Postmaster Tools e proíbe atingir 0,30%. O Yahoo exige SPF e DKIM em conjunto, um DMARC pelo menos em p=none e o mesmo teto de 0,3%. O SPF sozinho já não chega, portanto, para um grande volume.
Rotação das chaves
Substituir uma chave sem interrupção exige dois seletores, por exemplo s1 e depois s2. Publica-se a nova chave em s2 enquanto s1 ainda assina, passa-se a assinatura para s2 e deixa-se s1 no DNS o tempo necessário para que as mensagens em fila sejam verificadas. Removê-lo cedo demais provoca dkim=fail em envios legítimos, que se tomam por engano por uma avaria de DNS.
O que o DKIM não verifica
Um spammer pode assinar os seus envios com o próprio domínio e obter dkim=pass: a assinatura prova a origem da mensagem, não avalia o conteúdo nem a qualidade da lista. Um domínio perfeitamente assinado que escreve para endereços mortos acumula hard bounces. A sua reputação de remetente ressente-se na mesma.
Antes da próxima campanha, passe uma amostra da lista por uma verificação de endereços: o resultado indica quantos endereços inválidos a base contém antes de chegarem ao Postmaster Tools.
