DKIM alinhamento é uma comparação de identidade após verificação de assinatura bem-sucedida. A questão é se o domínio responsável pelo DKIM corresponde ao domínio mostrado no campo De da mensagem. Uma assinatura válida de um serviço não relacionado pode deixar essa questão sem resposta.
Extraia o par certo de domínios
Use o domínio do autor do RFC5322 campo e o d= domínio de um verificado com sucesso Assinatura DKIM. Não substitua Responder para, Return-Path, o seletor ou o opcional i= identidade para o domínio de assinatura nesta comparação. Preserve a mensagem bruta e use um resultado de verificação do destinatário confiável, em vez de assumir que uma assinatura é válida porque está presente.
Por exemplo, uma mensagem exibida como Faturamento < billing@example.com > tem example.com como seu domínio de autor neste caso simples de autor único. Uma assinatura passageira com d=example.net autentica o signatário example.net; a palavra Faturamento, um logotipo familiar ou uma parte local idêntica da caixa de correio não o torna alinhado com example.com.
Aplicar a regra de alinhamento configurada
Seção 4.4 RFC 9989 define alinhamento estrito como domínios idênticos. Sua regra relaxada compara domínios organizacionais determinados pelo procedimento de descoberta aplicável. O modo de alinhamento DKIM é selecionado através adkim; relaxado é o padrão quando essa tag está ausente de uma política aplicável.
Um exato d=example.com combinar com o domínio do autor example.com satisfaz o alinhamento estrito e também evita ambigüidades sobre seu relacionamento. Uma assinatura de mail.example.com não é uma correspondência estrita com example.com. Seu status relaxado exige a determinação do domínio organizacional; não trate todo relacionamento pai-subdomínio como automaticamente suficiente em todas as configurações de política possíveis.
Seção 4.10 RFC 9989 substitui RFC 7489do modelo de descoberta com DNS Tree Walks para descoberta de domínio organizacional. Implementações mais antigas ainda podem usar o processo anterior baseado em sufixo público. Registre quais especificações e comportamento do receptor seu diagnóstico aborda. Uma discrepância na era da transição precisa de evidências sobre descoberta e política, e não uma afirmação geral de que uma captura de tela DNS descreve cada receptor.
Trabalhe com um exemplo explícito e relaxado
Suponha que a regra aplicável seja relaxada e o receptor determine a domínio organizacional de ambos mail.example.com e example.com ser example.com. Uma assinatura passageira com d=mail.example.com em seguida, alinha-se com um domínio de autor de example.com. No modo estrito, o mesmo par não se alinharia.
Altere apenas o resultado da assinatura para falhar. O relacionamento do domínio não mudou, mas não fornece mais um identificador autenticado por DKIM. A mensagem, portanto, não tem nenhuma contribuição de passagem DKIM dessa assinatura. Um alinhamento separado SPF passe ainda pode fornecer um DMARC caminho, portanto, não conclua que a mensagem inteira falha sem avaliá-la.
Estes são casos sintéticos com suposições declaradas. Em uma investigação ao vivo, registre a política descoberta, o modo de alinhamento, as evidências DNS relevantes e o resultado do receptor. Isso torna a conclusão reproduzível em vez de reduzir o alinhamento a um atalho de correspondência de sufixo.
Corrija a configuração do remetente em sua origem
Se o serviço assinar apenas com o seu próprio domínio não relacionado, determine se o seu produto atual suporta uma identidade de assinatura de cliente apropriada. Obtenha os registros gerados e ative a assinatura através do processo suportado. Publicando um Registro DMARC não altera o serviço d= valor e adicionar um provedor ao SPF não altera uma assinatura DKIM .
Quando o modo estrito for pretendido, verifique a assinatura exata do domínio para cada rota relevante antes de alterar a política. Não enfraqueça o alinhamento apenas para ocultar um serviço de envio não gerenciado. Da mesma forma, não presuma que o modo estrito é gratuito: documente quais rotas legítimas de assinatura de subdomínio ele exclui e a decisão operacional por trás dessa restrição.
Verifique a rota corrigida
Envie por meio do aplicativo real e, em seguida, capture a assinatura aprovada, seu domínio e a avaliação DMARC do destinatário confiável. Revise todas as assinaturas se houver mais de uma; Seção 4.4.1 RFC 9989 aceita qualquer identificador DKIM alinhado de passagem. Um teste de uma caixa de correio ou locatário diferente pode usar uma identidade diferente e não pode resolver o problema do aplicativo afetado.
Mantenha o alinhamento e os resultados de entrega distintos. A correção é comprovada quando o remetente pretendido produz uma identidade alinhada válida sob a política aplicável. O posicionamento da caixa de entrada ainda depende de decisões mais amplas do destinatário.
Compare três resultados sintéticos
Suponha o domínio do autor example.com e uma política aplicável. Uma assinatura passageira com d=example.com se alinha em ambos os modos. Uma assinatura passageira com d=mail.example.com falha no alinhamento estrito; ele se alinha no modo relaxado apenas sob a suposição declarada de que ambos os domínios organizacionais são example.com . Uma assinatura de passagem com d=vendor.example.net não se alinha em nenhum dos modos quando seu domínio organizacional é example.net . Em cada caso, avalie outras assinaturas e SPF antes de decidir o resultado geral DMARC . Estes são exemplos de comparação de domínio, não resultados capturados do receptor.
Mantenha um registro de investigação compacto
Use esta planilha sugerida para a rota em análise. É uma ajuda de planejamento, não uma evidência de um teste executado.
- Mensagem: rota da aplicação, referência de mensagem bruta e receptor de verificação confiável.
- Identidade: Domínio do Autor e cada domínio DKIM d de passagem.
- Política: política DMARC descoberta, adkim e modelo de descoberta do receptor.
- Conclusão: correspondência estrita ou relaxada, outros caminhos DKIM / SPF e resultado de entrega registrado separadamente.
Leitura relacionada
Múltiplas assinaturas DKIM : encontre a assinatura de passagem alinhada · DKIM TXT e CNAME publicação: siga o modelo de gerenciamento de chaves do provedor.