Com uma política aplicável e uma avaliação completa, SPF e DKIM ambos podem passar enquanto DMARC falha em RFC 9989 §5.3.5. Isso acontece quando os domínios autenticados por esses mecanismos não se alinham com o domínio que as pessoas veem no endereço De.
Cada mecanismo responde a uma pergunta diferente. SPF verifica se a fonte de conexão está autorizada para a identidade do envelope avaliada. DKIM verifica uma assinatura associada a um domínio de assinatura. DMARC então verifica se uma identidade de passagem tem o relacionamento necessário com o domínio De visível. A maneira de diagnosticar esse problema é comparar essas identidades, e não contar os rótulos de passe verde.
Colete as identidades de uma mensagem recebida
Obtenha uma mensagem original do sistema receptor, incluindo seus resultados de autenticação confiável. Um cabeçalho arbitrário informando pass pode ser fornecido por um remetente não confiável; identificar o limite de recebimento que gerou as evidências sob RFC 8601 §7.1.
Registre estes campos:
- Evidência: Visível do domínio; O que estabelece: O Domínio do Autor, ou seja, o domínio no endereço De visível
- Evidência: resultado SPF e avaliado CORREIO DE identidade; O que estabelece: Se a fonte de conexão foi autorizada para aquela identidade de envelope
- Evidência: Cada resultado DKIM e seu domínio d=; O que estabelece: Qual assinatura de domínio verificada
- Evidência: Modos aspf e adkim aplicáveis; O que estabelece: se são necessárias relações de domínio exatas ou relaxadas
- Evidência: resultado confiável DMARC e contexto de diagnóstico; O que estabelece: A avaliação observada do receptor
Sob RFC 5321 §4.4, para mensagens comuns, o entregue Return-Path pode ajudar a identificar a identidade de devolução do envelope. Correlacione-o com resultados SPF confiáveis e evidências de rota, em vez de assumir que um campo de exibição conta toda a história SMTP .
Exemplo resolvido: duas passagens, sem identidade alinhada
Esta é uma ilustração sintética, assumindo uma política válida aplicável e verificações concluídas, e não uma mensagem capturada do cliente:
- Campo: De; Valor observado: accounts@example.com
- Campo: SPF ; Valor observado: passe para bounce.example.net
- Campo: DKIM ; Valor observado: passe com d=example.org
- Campo: DMARC alinhamento; Valor observado: nenhum domínio de passagem está alinhado com example.com
Ambos os mecanismos tiveram sucesso em seu próprio trabalho. Nenhum dos dois estabelece a relação necessária com example.com, portanto, eles não fornecem um caminho de passagem DMARC para esse domínio From visível.
Uma correção suportada pode configurar um domínio de cliente Assinatura DKIM. Outra possibilidade é um domínio de envelope personalizado suportado que produza um caminho SPF alinhado de passagem. A opção disponível depende do produto e da rota de envio reais.
Não invente valores DNS . Obtenha a configuração suportada do serviço, publique-a com os nomes de proprietário corretos, ative o recurso de envio relevante e envie um novo teste por meio do mesmo fluxo de trabalho do aplicativo.
Aplique o alinhamento estrito e relaxado corretamente
Com alinhamento estrito, os domínios relevantes devem corresponder exatamente sob RFC 9989 §3.2.10.2, para qualquer mecanismo. Os identificadores DKIM e SPF relevantes são especificados em RFC 9989 §4.4.1 e RFC 9989 §4.4.2, respectivamente. Com um alinhamento relaxado, DMARC usa o relacionamento do domínio organizacional aplicável e as regras de descoberta em RFC 9989 §4.10.2.
Para um caso ilustrativo simples, uma identidade de envelope de passagem em bounce.example.com pode se alinhar com um domínio De de example.com sob alinhamento relaxado SPF . Não satisfaz o alinhamento estrito SPF porque os dois nomes são diferentes.
Não generalize a descoberta de domínio organizacional em uma regra que sempre leva os dois últimos rótulos. Os limites do domínio e as regras atuais de descoberta DMARC são importantes. Verifique a política e implementação reais para estruturas de domínio mais complexas.
Quando existirem várias assinaturas DKIM , inspecione todas as assinaturas relevantes. Uma assinatura de passagem não alinhada não invalida uma assinatura de passagem alinhada separada. Por outro lado, a presença do seu domínio em uma assinatura com falha não cria um caminho de passagem.
Encontre as configurações de identidade suportadas no serviço de envio
Isso geralmente aparece depois que uma equipe começa a usar um CRM, uma ferramenta de cobrança ou um serviço de campanha. O fornecedor diz que a autenticação está habilitada, mas alguns destinatários rejeitam as mensagens. Ambas as afirmações podem ser verdadeiras se a plataforma autenticar seu próprio domínio enquanto a empresa exibe o seu.
Peça ao operador para mostrar uma mensagem afetada e explicar o remetente visível, o remetente do envelope e o domínio de assinatura. Uma resolução útil demonstra que o fluxo de trabalho de negócios real é enviado por meio de uma identidade alinhada com suporte. Uma captura de tela mostrando duas marcas verdes é insuficiente.
Mantenha o proprietário do aplicativo envolvido. A solução certa pode ser uma configuração ou capacidade específica do plano nesse serviço, em vez de uma mudança na plataforma de correio dos funcionários.
Teste a correção através da rota original
Envie uma mensagem de substituição controlada por meio do serviço afetado. Compare seu domínio From, identidade do envelope e todas as assinaturas DKIM relevantes com a amostra anterior. Mantenha o resultado do receptor confiável e a alteração da configuração juntos.
Se um teste direto simples for aprovado, mas a rota de negócios ainda falhar, inspecione o encaminhamento, os gateways e as modificações de mensagens. Eles podem alterar qual caminho de autenticação sobrevive. Distinga também um passe DMARC da colocação na caixa de entrada; o receptor pode aplicar filtragem adicional sob RFC 9989 §5.4.
Use o Guia Microsoft 365 ou Guia Google Workspace onde esses sistemas são os remetentes reais. Se a mensagem usar outro aplicativo, investigue a rota desse aplicativo. Usar relatórios agregados para procurar o mesmo padrão no tráfego observado.
Decida o que a falha lhe diz
Uma falha de alinhamento estabelece um resultado técnico. Não estabelece, por si só, se a mensagem era legítima, um serviço não autorizado, uma vítima de encaminhamento ou uma tentativa de falsificação de identidade.
Exija um proprietário e uma finalidade comercial para um remetente antes de aprovar um novo trust. A infraestrutura compartilhada e um nome de provedor reconhecível são pistas úteis, mas não provam que sua organização autorizou a conta ou o fluxo de trabalho.
Registre o escopo aceito da correção. Uma identidade de assinatura alinhada pode satisfazer DMARC enquanto a conta é posteriormente comprometida ou o aplicativo gera conteúdo inseguro. Continue os controles de conta, validação de aplicativos e aprovação independente de transações confidenciais.
A lição prática
Encerre o problema quando o fluxo de trabalho afetado produzir uma nova mensagem com um resultado alinhado de passagem confiável. Mantenha a comparação de identidade e a mudança de configuração juntas. Isso explica por que a mensagem original falhou e por que a correção funciona.
Torne a próxima decisão explícita
Para o dispositivo de duas passagens, registre “nenhum caminho de passagem alinhado” em vez de “ SPF quebrado”. Escolha a identidade com suporte de serviço para reparar e deixe a alteração pendente até que uma nova mensagem do mesmo fluxo de trabalho seja verificada. Se a descoberta da política ou o processamento DNS estiver incompleto, não force a observação em um rótulo de aprovação/reprovação; RFC 9989 §5.3.6 trata os erros DNS necessários separadamente. Nenhuma configuração do cliente ou teste de entrega foi realizado.