Escopo e preparação
Este guia cobre a configuração do domínio de envio Taguchi. É um procedimento documental, não um relatório de teste de inquilino vivo. Obtenha um administrador, acesso DNS e um proprietário de campanha. Salve os registros existentes e decida qual domínio De a campanha está autorizada a usar. Reserve um separado caminho de retorno nome que ainda não carrega outro serviço.
Configure o domínio de envio
Em Configurações > Domínio, adicione o componente Do domínio e caminho de retorno, escolha um seletore salve. Publique o CNAME e entradas TXT geradas na coluna Registros DNS , usando sua própria configuração em vez dos exemplos da documentação. Taguchi distingue Pendente, Autorizado e Configurado. Após a autorização DNS , o suporte deve concluir a configuração; em seguida, selecione o domínio no tema do modelo. O provedor descreve uma janela de autorização de 24 horas. Verifique a precisão do registro antes de escalar um estado Pendente persistente. Veja a fonte de configuração do Taguchi abaixo.
Design original de aceitação da campanha
Prepare duas versões inofensivas da mesma campanha: uma antes de mudar o tema e outra depois. Grave o tema, do domínio, do domínio do envelope, de cada domínio de assinatura e dos resultados do receptor confiável para ambos. Isso isola uma alteração de configuração que existe no DNS , mas ainda não é usada pela campanha. Não interprete um rótulo Autorizado como evidência de que a campanha mudou.
Para um domínio fictício From notices.example.org , um envelope em bounce.notices.example.org ilustra por que relaxado SPF alinhamento e o alinhamento estrito SPF pode ser diferente. Estas são identidades de ensino, não valores emitidos por Taguchi ou resultados observados. Teste explicitamente o modo de alinhamento selecionado e prefira evidências da mensagem real em vez de suposições sobre um rótulo do painel. O projeto de aceitação abaixo não possui linhas de resultados observados; é uma orientação e não uma planilha de medição anexada.
Prove a identidade no destinatário
Use uma caixa de correio externa controlada e envie através do fluxo de trabalho de produção, com conteúdo inofensivo e sem dados do cliente. Salve a mensagem bruta, o carimbo de data e hora e o sistema receptor Authentication-Results. Ignore as asserções de autenticação inseridas por um remetente não confiável. Registre o domínio From visível, Return-Path ou a identidade do envelope autenticado e cada DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identidade.
A passagem SPF autoriza o servidor de conexão para a identidade do envelope avaliada. O passe DKIM valida uma assinatura para seu domínio de assinatura. DMARC precisa de um método de passagem cujo domínio se alinhe com o De visível: o alinhamento estrito requer o mesmo domínio; o alinhamento relaxado permite o relacionamento de domínio organizacional aplicável. Uma assinatura de propriedade do provedor pode passar sem autenticar seu De visível. Uma passagem alinhada Assinatura DKIM pode satisfazer DMARC mesmo quando outra assinatura falha. Essas regras de protocolo vêm da RFC 7208 , RFC 6376 e RFC 9989, listado abaixo.
Verifique DNS autoritativo antes de diagnosticar caches. Peça a um servidor autorizado o nome e o tipo exatos e compare um resolvedor recursivo após seu tempo de vida em cache. Para DKIM , siga qualquer CNAME até sua resposta TXT de chave pública. Nunca publique uma chave privada. Mantenha uma política SPF para cada nome avaliado e verifique o limite de dez prazos causadores de pesquisa de DNS em inclusões aninhadas. Não substitua uma política SPF compartilhada por um exemplo de provedor.
Recuperação e aceitação
Pause o fluxo de trabalho afetado se os testes mostrarem uma nova regressão. Compare o registro alterado com a versão salva e desfaça apenas essa alteração após verificar outros remetentes. Verifique novamente DNS e reenvie após a recuperação; reverter um valor não libera todos os resolvedores imediatamente. Mantenha registros de verificação DKIM antigos disponíveis enquanto mensagens assinadas anteriormente ainda estiverem em trânsito, a menos que um incidente de segurança exija revogação.
Aceite a alteração somente quando DNS , o estado do aplicativo e uma mensagem real recebida estiverem de acordo. Registre o proprietário do fluxo, o carimbo de data/hora da evidência e o acionador da próxima revisão. A colocação na caixa de entrada por si só não é prova de autenticação, e a autenticação bem-sucedida não garante a colocação na caixa de entrada. Não restrinja a política DMARC de um domínio compartilhado com base no teste de um provedor. Faça um inventário das outras fontes legítimas primeiro.
Use um livro-razão do estado antes do lançamento da campanha
O caso escrito TG-01 assume que o novo domínio é notices.example.org , o componente do caminho de retorno escolhido é bounce e o seletor é o valor real emitido pela conta, não fornecido neste exemplo. A autorização DNS é estipulada como completa, mas o status é Autorizado em vez de Configurado, e o tema da campanha ainda seleciona o domínio antigo. O proprietário do suporte deve concluir a ativação do provedor e, em seguida, o proprietário da campanha seleciona o domínio aprovado no tema e realiza um teste controlado. Até então, os resultados reais de From, envelope e DKIM para a campanha alterada são desconhecidos. Não marque-o como pronto apenas pelo DNS . Não ocorreu nenhuma solicitação de suporte, edição de modelo, consulta DNS ou envio de campanha.
Preservar o limite de aplicação
RFC 9989 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.