Identifique o cliente e o domínio juntos
Evalanche pode ser usado em marcas e clientes. Comece com uma matriz de endereço do remetente, domínio real, conta ou cliente e tipo de correspondência. Um domínio configurado em algum lugar do sistema não é evidência suficiente de que o cliente pretendido possa usá-lo corretamente. Inclua modelos herdados e rotas de automação no inventário porque um endereço De recém-selecionado pode criar um requisito de autenticação diferente.
O Guia de autenticação Evalanche, “entrada DKIM ” distingue a configuração global para uso de vários clientes das configurações no cliente correspondente ao operar para clientes. Resolva essa distinção com o administrador da sua implantação. Não presuma que “global” é sempre mais seguro ou que o domínio de um cliente pertence a todos os clientes.
Defina quais identidades a organização realmente aprova. Liste as caixas de correio usadas para respostas comuns separadamente da identidade do envelope usada para erros de entrega. Um endereço de resposta funcional e um nome de host de rastreamento personalizado não determinam se um receptor encontrará um endereço alinhado. DKIM ou SPF resultado.
Preparar a revisão de escopo e recuperação
Dê a cada objeto de domínio do remetente um proprietário comercial e um proprietário técnico. Registre quais campanhas ativas e automações dependem disso. Antes de editar uma chave ou domínio, capture o estado existente e identifique uma forma controlada de interromper ou adiar os envios afetados. Evite descobrir que um evento de aniversário ou de estilo transacional continua sendo enviado enquanto um administrador altera sua autenticação.
Revise a zona DNS autoritativa e qualquer existente seletor no nome proposto. Caso outro serviço ou cliente utilize esse proprietário, peça às equipes responsáveis que resolvam a colisão. Uma nova chave pública do mesmo proprietário pode invalidar mensagens assinadas com a chave antiga. Não presuma que um par recém-gerado seja uma mudança aditiva.
Este guia recomenda usar o fluxo de geração normal do produto em vez de manipular manualmente as chaves secretas. Se uma organização tiver um processo de chave externa aprovado, mantenha-o separado da verificação de domínio de rotina. Somente material de verificação pública pertence à planilha ou ao ticket de alteração DNS . Nunca cole uma chave privada em uma mensagem de suporte comum ou em um documento de campanha compartilhado.
Gere o registro de domínio no contexto correto
Nas seções “Criar entrada DKIM ” do guia de autenticação através das seções “Verificar entrada DKIM ”, Configurações de documentos do Evalanche → Domínio/ DKIM → Novo, salvando o domínio de envio, gerando um par de chaves e publicando o exibido Registro TXT. Seu padrão de proprietário documentado usa o seletor ems. A página diz que a assinatura é ativada automaticamente e que o status Válido pode levar de um a dois dias.
Registre o proprietário completo DNS e o valor público mostrado pela conta real. Trate o padrão de seletor documentado como contexto, não como permissão para inventar uma chave ou ignorar a saída específica da conta. Verifique o comportamento do sufixo do editor de zona. Um proprietário relativo em uma interface DNS pode precisar de um nome totalmente qualificado em outra; o que importa é o nome de pesquisa público exato produzido.
Publicar o valor completo, preservando seus caracteres. Quando um provedor DNS exibir conteúdo TXT longo como diversas strings, verifique se a resposta resultante representa o registro completo pretendido. Não trunque a chave para caber em um campo nem altere silenciosamente o tipo de registro. Peça ao administrador ou provedor DNS uma maneira compatível de inserir o valor emitido se a interface não estiver clara.
Capture evidências DNS público e status de aplicativos de forma independente. Se a chave estiver visível, mas o status não tiver sido atualizado, retenha as observações e seus tempos. Se o aplicativo indicar Válido enquanto um destinatário não puder recuperar a chave correspondente, inspecione os valores reais d= e s= usados pela mensagem em vez de presumir que o painel e a mensagem se referem ao mesmo objeto de domínio.
Revise cuidadosamente a autorização SPF publicada
A seção “Entrada SPF ” do guia publica a autorização, include:_spf.senders.scnem.com. Confirme se ele se aplica ao serviço e domínio reais antes de incorporá-lo à política. Preserve outros remetentes obrigatórios e avalie toda a política em vez de substituí-la pelo exemplo independente da página. Não há necessidade de copiar os mecanismos opcionais do exemplo apenas porque eles aparecem ao lado do include.
A página de ajuda usa palavras sobre entradas reversas, mas RFC 7208 , seções 2.3 e 3 define uma verificação SPF no SMTP CORREIO DE identidade e publicação usando TXT . Não crie um Registro PTR como a configuração SPF . Além disso, não presuma que o domínio após o endereço De visível seja automaticamente o domínio que um receptor avaliou para SPF .
Antes de alterar uma política, inspecione uma mensagem de linha de base e registre o resultado do domínio do envelope do destinatário. Se o envelope do serviço não estiver relacionado ao seu domínio De, um resultado SPF aprovado poderá não fornecer DMARC alinhamento. A documentação aqui inspecionada não estabelece um costume universal de autoatendimento Return-Path contexto. Pergunte ao suporte sobre a conta exata e a rota se SPF alinhado for um requisito.
As seções 4.5 e 4.6.4 RFC 7208 cobrem a seleção de registros e os dez mandatos Limite de pesquisa DNS. Mantenha uma política SPF em um proprietário, retenha a autorização existente necessária e verifique as inclusões aninhadas. Parar para uma reformulação da política caso a nova dependência ultrapasse o limite de avaliação; não remova outro sistema comercial simplesmente para fazer o remetente do marketing passar.
Mantenha a política DMARC fora do atalho da campanha
A página do Evalanche diz que nenhuma configuração especial de aplicativo é necessária para DMARC e fornece um exemplo DNS em “Estrutura de uma entrada”. Isso não significa que a organização já tenha uma política eficaz ou que a amostra seja adequada. Registre a política real, o modo de alinhamento e o proprietário do relatório do seu domínio De antes de fazer alterações.
Usar RFC 9989 , seção 4.4 para a regra de aceitação: pelo menos um resultado SPF ou DKIM aprovado deve estar alinhado com o domínio From visível. Uma assinatura de domínio de provedor não relacionada não é suficiente. Sob alinhamento estrito, apenas compartilhando um domínio organizacional é insuficiente; a correspondência de domínio exato é importante. Avalie as identidades sob a política que está realmente em vigor.
Não copie o exemplo de quarentena ou alinhamento estrito do provedor sobre uma política existente. A aplicação da política e os destinos dos relatórios afetam todos os remetentes no escopo da política, não apenas o Evalanche. Preserve as proteções existentes enquanto investiga uma campanha. Trate qualquer mudança proposta como uma decisão separada e revisada.
Teste os tipos e modelos de correspondência reais
Guia “O primeiro e-mail” do Evalanche, tipos de correspondência e configuração distingue mailings manuais, de eventos e de gatilho e instrui o operador a verificar a autenticação do remetente nos dados configurados do remetente. Também rotula o editor descrito como legado. Use a interface da conta atual para a campanha real; não presuma que uma sequência de telas em um editor mais antigo comprove a rota atual.
Selecione destinatários controlados e conteúdo inofensivo. Para cada rota de material, registre o identificador de correspondência, cliente, modelo, endereço De configurado e horário de envio. Quando um modelo herda o remetente, inspecione o valor efetivo após a criação da campanha. Uma revisão do modelo é útil, mas não pode substituir a evidência do que foi realmente entregue.
Leia os resultados da autenticação confiável do destinatário final. Capture o From visível, Return-Path , cada par DKIM d= e s=, resultado SPF , resultados DKIM e resultado DMARC . RFC 6376 , seção 3.5 define como o domínio e o seletor identificam a pesquisa de chave. Retenha informações suficientes para repetir a pesquisa sem reter dados desnecessários do destinatário ou conteúdo da mensagem.
Teste a rota externa e um destinatário interno se a filtragem interna for uma preocupação comercial. Uma lista de permissões local pode alterar o comportamento de entrega, mas não valida a autenticação pública vista em outros lugares. Se o teste externo for bem-sucedido e o teste interno falhar, investigue o gateway interno usando a mesma evidência de mensagem em vez de alterar aleatoriamente os registros DNS válidos.
Trabalhe com falhas por camada
Se não houver assinatura pretendida, inspecione primeiro o objeto de domínio do remetente, o escopo do cliente e o remetente da campanha efetiva. Se a assinatura estiver presente, mas não puder ser verificada, compare o proprietário da pesquisa e a chave pública com a conta. Se verificar, mas DMARC falhar, compare os domínios e o modo de alinhamento. Esses são problemas diferentes com soluções diferentes.
Se apenas algumas correspondências falharem, compare seus modelos, domínios, clientes e rotas downstream. Um remetente selecionado em uma automação pode ser diferente da campanha manual usada durante o teste. Se o hash de corpo falhar após o encaminhamento ou outro gateway, investigue as alterações após a assinatura, em vez de gerar novas chaves reflexivamente.
Crie um registro de revisão de cliente e domínio com colunas para observações, proprietário da evidência e próxima etapa de aceitação. Inclua o De efetivo, o escopo do cliente, o modelo herdado, o registro DNS emitido, as identidades/resultados do receptor e a decisão de recuperação para que essas camadas permaneçam separadas. Evidências em branco são uma tarefa aberta, não um resultado passageiro.
Exemplo fictício trabalhado: a chave certa no escopo errado
Apenas caso escrito fictício: EV-01 estipula um manual da agência enviado por correio com From agency@example.org e passando d=example.org. Em vez disso, um gatilho de cliente usa From offers@client.example , enquanto o objeto de domínio do cliente selecionado não é confirmado e seus resultados DKIM / SPF são desconhecidos. O passe da agência não prova nada sobre esse gatilho. O administrador do cliente deve resolver o escopo e as configurações herdadas do remetente e, em seguida, coletar evidências desse gatilho exato. Nenhuma implantação, geração de chave, consulta DNS ou mensagem foi executada.
Fechar somente após existir evidência de rota
Combine a recuperação com o proprietário da campanha antes de uma alteração. Pause os envios afetados quando a autenticação for incerta, preserve os seletores em funcionamento até que seu tempo de vida útil de verificação de mensagens seja compreendido e restaure apenas um estado anterior revisado. Teste novamente após a introdução de uma nova marca, cliente, remetente de modelo, chave ou gateway de entrega.
O escopo ativo, os valores emitidos pela conta, DNS público, as identidades das mensagens recebidas e o procedimento de recuperação permanecem não verificados neste rascunho documental. A revisão visual, a aprovação humana pelas PME e a publicação estão pendentes. O procedimento é um plano para produzir provas, não uma alegação de que um inquilino do Evalanche já foi autenticado.
Separe uma mensagem passageira da prontidão para aplicação
A Seção 7.4 RFC 9989 exige DKIM válido para uma publicação de domínio p=reject e alerta sobre a interoperabilidade de correio indireto. Um único resultado alinhado SPF não justifica, por si só, uma implementação de política de rejeição. Revise todas as rotas legítimas e propriedade de políticas separadamente da configuração deste provedor.