O útil mais rápido DMARC a solicitação de evidência solicita uma mensagem representativa, a rota que a produziu e o resultado do sistema receptor. Uma captura de tela dizendo “SPF aprovado” ou “domínio verificado” geralmente omite as identidades necessárias para explicar a falha.
Solicite o menor conjunto de evidências que possa distinguir um problema de autenticação, um alinhamento problema, um problema DNS e um problema de entrega. Expanda a solicitação somente quando permanecer uma incerteza específica. Isso reduz a exposição desnecessária do conteúdo do cliente e dá ao remetente uma tarefa que ele pode realmente concluir.
Peça primeiro uma reprodução segura
Sempre que for prático, peça ao proprietário do aplicativo que envie uma mensagem de teste não confidencial por meio do fluxo de trabalho de produção afetado para um destinatário de teste autorizado. O fluxo de trabalho é importante: um botão de teste no console do provedor pode usar um remetente ou rota diferente de faturas, redefinições de senha ou notificações programadas.
Registre o aplicativo, a conta do cliente ou a referência do locatário usada internamente, acionando a ação, o horário de envio UTC, o sistema de destinatário pretendido e se o encaminhamento ou um gateway está envolvido. Um identificador de mensagem pode ajudar a correlacionar logs, mas compartilhá-los somente por meio do canal de suporte acordado. Não solicite senhas, chaves de assinatura privadas, credenciais de API ou exportações de caixas de correio não relacionadas.
Mantenha a solicitação inicial focada no problema técnico. Se a falha envolver uma mensagem real de um cliente, use controles de acesso e manuseio aprovados antes de compartilhar seu conteúdo com terceiros.
Preservar as evidências que distinguem as identidades
Solicite a mensagem original recebida no destino afetado ou uma exportação de diagnóstico do destinatário que retenha os cabeçalhos relevantes. Os campos úteis incluem o domínio De visível, identidade do envelope quando disponível, relevante DKIM assinaturas e o sistema receptor Authentication-Results.
O operador receptor deve identificar qual resultado é confiável. Somente o texto do cabeçalho pode ser falsificado ou transportado de uma fonte não confiável; RFC 8601 §1.2 e RFC 8601 §7.1 explicar o requisito do limite de confiança. Se existirem vários campos Authentication-Results , não assuma que a passagem superior é automaticamente autoritativa.
Para a triagem inicial, um administrador pode extrair os campos relevantes de identidade e resultado, mantendo o original com segurança. Isso é diferente de verificar novamente DKIM criptograficamente. A edição de cabeçalhos assinados ou do corpo pode invalidar uma assinatura, portanto, uma cópia editada não pode necessariamente reproduzir a validação original. Se for necessária uma nova verificação independente, providencie acesso controlado a uma amostra não modificada ou gere um novo teste seguro. O tratamento sensível à assinatura segue RFC 6376 §3.4 e RFC 6376 §3.7.
Um pedido mínimo que você pode adaptar
Use o seguinte como modelo operacional, não como uma solicitação de divulgação de credenciais:
“Por favor, envie um teste não sensível através do fluxo de trabalho afetado e forneça:
- O aplicativo e o fluxo de trabalho exato, o horário de envio em UTC e se a rota inclui encaminhamento ou gateway.
- A mensagem original recebida por meio de nosso canal de suporte aprovado ou o domínio extraído do administrador do destinatário, identidade e resultado avaliados pelo SPF, cada DKIM relevante
d=es=valor e resultado e resultado DMARC confiável. - A resposta exata de rejeição se a entrega falhar, incluindo qual sistema a retornou. Se não existir nenhuma mensagem de destinatário, forneça detalhes de rastreamento do lado do remetente.
- As configurações de autenticação usadas por esse fluxo de trabalho específico e as instruções atuais do provedor para a configuração de domínio do cliente compatível.
- Qualquer alteração recente DNS , chave, gateway ou endereço do remetente e seu carimbo de data/hora.
Não inclua senhas de contas, chaves de API, chaves DKIM privadas ou registros de clientes não relacionados. Mantenha a amostra original inalterada se a verificação da assinatura for necessária.”
Esta solicitação cria um ponto de referência comum. Ele não pressupõe que a infraestrutura compartilhada do fornecedor ou um IP de origem familiar comprove que sua organização autorizou o remetente.
Combine cada resposta com uma pergunta de diagnóstico
Crie uma pequena planilha de evidências antes de propor alterações.
- Evidência: Do domínio; A pergunta responde: Qual domínio de autor DMARC está avaliando?
- Evidência: resultado SPF e domínio avaliado; A pergunta responde: SPF passou por uma identidade relevante para esta rota?
- Evidência: resultados DKIM ,
d=es=; A pergunta responde: Quais identidades de assinatura foram verificadas e quais chaves foram usadas? - Evidência: Políticas aplicáveis e modos de alinhamento; A pergunta responde: Uma identidade passageira está alinhada com a regra relevante?
- Evidência: resposta SMTP ou disposição final; A pergunta responde: O que realmente aconteceu com a entrega?
- Evidência: Mudança de carimbos de data/hora e observações atuais DNS ; A pergunta responde: O tempo de configuração poderia explicar diferentes observações?
As verificações de identidade e alinhamento seguem RFC 9989 §5.3.3, RFC 9989 §5.3.4 e RFC 9989 §5.3.5. A planilha e o formato da solicitação são recomendações práticas.
Lidar com evidências ausentes explicitamente
Se o remetente fornecer apenas o status do console, solicite uma amostra recebida do fluxo de trabalho real. Se um destinatário rejeitou antes de aceitar a mensagem, reconheça que pode não existir nenhuma cópia final da caixa de correio. Use o rastreamento de saída do remetente, a resposta de rejeição e os logs do operador de recebimento, quando disponíveis.
Se DNS atual for diferente do carimbo de data/hora da mensagem, não afirme que isso prova o que o destinatário anterior viu. Peça o histórico de alterações ou uma nova reprodução controlada. Se o provedor não puder oferecer uma identidade alinhada com suporte, registre essa lacuna de capacidade e o fluxo de trabalho afetado em vez de inventar valores DNS .
Conclua a investigação com uma comparação de identidade antes e depois, a alteração exata e um novo resultado confiável. Vincule essa evidência ao inventário do remetente. O guia de falha de alinhamento ajuda a interpretá-lo, enquanto o guia de privacidade para relatórios apoia decisões sobre evidências retidas.
Torne a próxima decisão explícita
Se existir apenas uma captura de tela do console, marque o domínio SPF avaliado, a identidade DKIM alinhada e o limite de confiança do receptor como ausentes. Solicite esses campos em vez de declarar uma correção DNS . Se a rejeição impediu a entrega da caixa de correio, use a resposta SMTP e o rastreamento do remetente. Registre o carimbo de data/hora de cada observação separadamente da inspeção posterior DNS ; nenhuma mensagem original foi coletada ou verificada aqui.