Este guia cobre a assinatura local do MailMarshal/SEG 8.0 e posterior, não o produto Cloud separado. Uma chave DNS sem uma regra de assinatura habilitada não autentica emails de saída. Faça um inventário dos domínios locais, dos nós de processamento e de qualquer gateway downstream que modifique o conteúdo assinado antes de selecionar a janela de alteração.
Configurar o domínio e a regra de assinatura
No Management Console, abra as propriedades do domínio local e seus DKIM guia. Adicione um exclusivo seletor, gere a chave, salve-a e copie a saída completa do registro DNS . O guia atual descreve 2048 bits geração por padrão. Publique seu Registro TXT no nome do seletor indicado; verifique a resposta real quanto a danos ou truncamento de espaços em branco. Habilite a chave somente depois que DNS estiver disponível. Em seguida, habilite uma regra de Análise de Conteúdo com Aplicar Assinatura DKIM. Defina o escopo dessa regra para o tráfego de saída pretendido, não para mensagens de entrada arbitrárias. Referência de configuração do MailMarshal
Verifique o DNS usado pelo MailMarshal e a resolução pública. O guia atual descreve uma consulta pública adicional do Array Manager, usando Google DNS 8.8.8.8 por padrão; confirme o servidor configurado e a versão do produto em vez de assumir que o resolvedor de entrega é a única verificação. Caso contrário, DNS dividido pode fazer com que um registro válido externamente falhe na validação local. Para erros de replicação de chave, o fornecedor identifica o serviço Windows CNG Key Isolation no Array Manager e nos servidores de processamento. Investigue essa dependência antes de substituir uma chave pública funcional. Siga seu processo de mudança para reinicializações; este guia não autoriza a interrupção do serviço.
Verifique DNS e um resultado de recebimento real
Antes de alterar as regras do gateway de saída, exporte os valores DNS existentes, registre a diferença aprovada e nomeie o proprietário da reversão. Confirme se o editor DNS espera um rótulo relativo ou um nome totalmente qualificado; duplicar o sufixo de domínio cria um recorde que nenhum verificador pretendido encontrará. Consulte o nome real do proprietário após salvar, incluindo qualquer CNAME alvo, em vez de confiar na bandeira de sucesso do editor.
SPF deve permanecer uma política no domínio relevante e permanecer dentro dos limites de prazo de consulta de DNS em RFC 7208. Adicionar um include por si só não estabelece alinhamento. Sob RFC 9989, DMARC passa quando pelo menos um resultado SPF ou DKIM bem-sucedido se alinha com o domínio From visível no modo aplicável. Não exija que ambos os mecanismos se alinhem como uma condição imposta pelo padrão e não confunda uma passagem de domínio de provedor com uma passagem de domínio de cliente alinhada.
Envie uma mensagem que realmente atravesse a regra de Análise de Conteúdo selecionada para uma caixa de correio que você controla. Salve os resultados de autenticação confiável do sistema receptor, De visível, identidade do envelope, valores DKIM d= e s=, carimbo de data/hora e status do provedor. Uma pesquisa DNS mostra apenas a chave disponível; RFC 6376 a verificação também avalia a assinatura da mensagem recebida. Use conteúdo não confidencial e evite expor mensagens completas dos clientes a verificadores públicos.
Use uma decisão limitada de aceitação e reversão
Um caso de aceitação ilustrativo é uma mensagem de alerts@example.com com uma assinatura válida usando d=example.com. Essa correspondência exata de domínio oferece suporte ao alinhamento DKIM em qualquer modo. Uma assinatura válida usando apenas d=vendor.example.net não se alinha com example.com ; sem SPF alinhado, essa amostra falha no teste de aceitação DMARC . Estes são exemplos de raciocínio, não resultados observados do Trustwave MailMarshal.
Se o teste falhar, separe DNS ausente, o seletor errado, a configuração do provedor inativo, o roteamento inesperado e a modificação da mensagem antes de fazer outra alteração. Teste novamente o mesmo fluxo de trabalho após cada correção aprovada. Não enfraqueça a política DMARC de todo o domínio para ocultar o problema de um único remetente. Quando a reversão for necessária, restaure o roteamento anterior aprovado ou a configuração do remetente e retenha os registros-chave enquanto as mensagens assinadas na fila ainda precisarem deles. Mantenha as evidências de teste e as exceções não resolvidas com o inventário do domínio. Nenhum acesso de locatário, alteração DNS ou envio real foi realizado na preparação deste guia.
Distinguir disponibilidade de chave da seleção de regras
O caso escrito MM-01 pressupõe que o seletor gateway1 está habilitado para example.org e sua chave pública está disponível, mas o fluxo de saída afetado não corresponde à regra de Análise de Conteúdo que contém Aplicar Assinatura DKIM . O From pretendido é alerts@example.org ; os resultados do receptor e as assinaturas emitidas são desconhecidos. O proprietário da regra deve inspecionar o roteamento e as condições antes de substituir uma chave ou reiniciar serviços. Se os logs de replicação mostrarem uma falha separada, investigue essa dependência documentada por meio de uma alteração aprovada, e não tratando cada mensagem não assinada como falha de replicação. Nenhum gateway, serviço do Windows, chave ou fluxo de mensagens foi alterado.
Preservar o limite de aplicação
RFC 9989 A Seção 7.4 exige DKIM válido, e não apenas SPF , para publicação de domínios p=rejecte alerta sobre a interoperabilidade de correio indireto e listas de discussão. Um único teste bem-sucedido de mensagem direta não é prova de que todas as rotas legítimas estejam prontas para políticas mais fortes. Mantenha a proteção aprovada existente enquanto diagnostica a lacuna real; qualquer mudança política necessita da sua própria decisão.