SPF, DKIM e DMARC
Inspecione SPF, DKIM e DMARC em uma ordem sensata sem confundir DNS publicado com entrega bem sucedida.
Inventário os serviços que enviam para você
Comece com uma lista dos sistemas que você realmente usa: um provedor de correio, plataforma de newsletter, serviço transacional e qualquer software de suporte ou faturamento. Para cada um, registre o domínio visível do domínio, o domínio de retorno esperado e o seletor DKIM fornecido pelo provedor. Este inventário dá o contexto dos resultados do DNS. Um registro pode parecer plausível em isolamento enquanto omite um serviço que envia cartas legítimas ou mantém um serviço que sua organização não usa mais.
SPF descreve um caminho de envio autorizado
SPF avalia o envio de IP contra a política associada ao domínio remetente de envelopes, ao invés de simplesmente ler o endereço visível. Sua estrutura de inclusão e redirecionamento pode depender de mais respostas DNS. Use o verificador SPF para inspecionar o registro publicado ou colado e sua estimativa conservadora. Uma contagem estática não pode reproduzir completamente cada avaliação dependente de mensagens. Se um pedido de DNS não terminar, mantenha o resultado inconclusivo em vez de tratar o registro indisponível como um passe.
DKIM conecta uma assinatura a uma chave publicada
Um sistema de envio sinaliza conteúdo de mensagem com uma chave privada. Os receptores usam o selecionador e o domínio de assinatura para localizar uma chave pública no DNS, geralmente sob selector._domainkey.example.com. Este verificador pode inspecionar publicações, etiquetas comuns e codificação base64. Não valida a estrutura da chave ASN.1 ou a força do módulo. Não pode verificar uma mensagem sem a assinatura da mensagem e conteúdo assinado. Grave o seletor que seu provedor usa, consultar um seletor adivinhado pode produzir uma ausência que diz pouco sobre outro seletor válido.
DMARC traz o remetente visível para a comparação.
A DMARC verifica o alinhamento entre o domínio visível e uma identidade bem sucedida do SPF ou DKIM, e publica uma política de manejo solicitada. Um verificador de registros ajuda a inspecionar as etiquetas e políticas, um registro gerado é um rascunho para revisar contra seu inventário de envio. Não assuma que mudar de política corrige um serviço desalinhado. Confirme a configuração de autenticação de cada serviço primeiro, em seguida, use observações e orientação do provedor ao decidir como lidar com mensagens que falham nas verificações alinhadas.
| Cheque. | Usos | Não estabelece |
|---|---|---|
| Registro SPF | Política de entrega de envelopes | Visível do alinhamento ou colocação da caixa de entrada |
| DKIM recorde | Chave seletor publicada e codificação básica | Estrutura da chave RSA ou um passe de assinatura de mensagem |
| Registro de DMARC | Ajustes de alinhamento e política solicitada | Que cada serviço de envio está alinhado. |
| Cabeçalhos / relatórios | Observações relatadas pelo receptor. | Autenticidade de evidências arbitrárias coladas |
Use mensagens reais e relatórios como evidência separada.
Para uma verificação prática, envie uma mensagem de teste comum através de cada serviço esperado e inspecione os cabeçalhos adicionados por um sistema de recepção confiável. Compare o domínio visível, caminho de retorno e domínio de assinatura com seu inventário. Relatórios agregados da DMARC fornecem outra visão: fontes, contagens de mensagens e resultados de autenticação relatados durante um período. Use o leitor de relatórios para identificar uma fonte que valha a pena investigar. Um relatório pode resumir falhas, mas não explica automaticamente se são abuso, encaminhamento ou uma legítima má configuração.
Mantenha o escopo e a confiança visíveis.
Cabeçalhos colados e relatórios XML são dados fornecidos à ferramenta; o leitor não estabelece sua autenticidade. Uma linha copiada de resultados de autenticação de uma parte não confiável de uma mensagem não deve superar os resultados confiáveis do provedor do destinatário. Da mesma forma, uma chave pública do DNS prova a publicação, não que seu serviço tenha assinado a mensagem que você inspecionou. Mantenha um pequeno registro de evidências contendo o registro, a mensagem ou relatório relevante, o provedor e a hora do cheque antes de chegar a uma conclusão.
Investigue a entrega com uma lista mais ampla.
Passar autenticação é apenas uma parte da entrega do correio. Gmail publica requisitos de remetente que também cobrem o envio de infraestrutura, formatação de mensagens e práticas voltadas para o usuário. Comece uma investigação de entrega com a resposta exata do provedor e um exemplo reprodutível. Reveja as mudanças no seu inventário de remetentes antes de mudar o DNS novamente. Ferramentas de autenticação esclarecem registros e observações, não podem prometer a colocação da caixa de entrada, ignorar as políticas de um provedor ou determinar a reputação de um único registro.