Confirme a implantação do CMS antes de escolher as instruções
O Optimizely CMS cria mensagens de aplicativo, mas o transporte configurado as envia. Comece registrando a versão do CMS, o modelo de hospedagem, o ambiente e a integração de correio que trata do fluxo de trabalho afetado. Não se pode presumir que um CMS em execução em DXP, uma instalação auto-hospedada e um aplicativo com seu próprio retransmissor de terceiros compartilhem um SPF ou DKIM configuração. O Optimizely Campaign é um produto separado e seus registros de domínio de correio de marketing não devem ser emprestados para notificações CMS.
A página do servidor de e-mail DXP original recuperada para este guia é rotulada como DXP para CMS 12 e Commerce 14. Ela documenta uma nuvem e-mail transacional serviço, uma configuração SMTP apoiada por SendGrid e um processo de autenticação de domínio assistido por suporte. Este artigo usa essa rota como seu ramo de implementação concreto. A aplicabilidade a outra versão do CMS, nível de hospedagem ou integração personalizada requer a documentação atual correspondente e evidências de implantação. O rótulo do catálogo geral Optimizely CMS é mais amplo do que o escopo de configuração estabelecido aqui. Configuração do servidor de e-mail DXP
Antes de editar a configuração, nomeie o proprietário do aplicativo, o operador de implantação, o administrador de email e o proprietário DNS . Combine qual fluxo de trabalho demonstrará sucesso: uma notificação de projeto, uma mensagem de aprovação de conteúdo ou outro e-mail de inscrição explicitamente configurado. Use conteúdo sintético e um destinatário controlado. Um boletim informativo de marketing não é um substituto apropriado para um teste de notificação CMS simplesmente porque ambos os produtos têm o mesmo nome de fornecedor.
Rastreie a mensagem do evento do aplicativo para retransmitir
Divida a rota em criação de eventos, envio de aplicativos, envio SMTP , entrega de provedor e autenticação de receptor. Registre quais evidências estão disponíveis em cada estágio. Se o aplicativo nunca produzir ou enviar uma notificação, a edição SPF não poderá criá-la. Se SMTP rejeitar credenciais, a mensagem ainda não atingiu o estágio em que o destinatário avalia DMARC.
A documentação do CMS 13 Projects da Optimizely descreve separadamente o envio de notificações e diz que as configurações SMTP devem ser configuradas para notificações por e-mail. Isso suporta a verificação do estágio de acionamento e despacho quando a instalação real é o CMS 13; ele não estabelece que uma implantação do CMS 12 tenha padrões de trabalho idênticos ou que o exemplo DXP SMTP se aplique inalterado. Combine as instruções de configuração com a versão instalada em vez de misturar trechos de versão. Notificações de projeto CMS 13
Para cada ambiente, diferencie a configuração de tempo de execução efetiva de um arquivo de origem que pode ser substituído durante a implantação. Um sucesso de preparação pode coexistir com uma falha de produção causada por uma configuração ausente ou um endereço De diferente. Colete configurações limpas e logs de aplicativos por meio do processo normal de engenharia. Não exponha credenciais SMTP , chaves de API ou segredos de produção não relacionados no pacote de evidências.
Configure o transporte DXP documentado por meio de uma implantação controlada
O guia DXP diz que a configuração do email não é aplicada automaticamente pelas transformações de configuração padrão. Descreve a obtenção da credencial de serviço de e-mail por meio do portal de gerenciamento DXP e o fornecimento de configurações SMTP ao aplicativo. Seu exemplo inclui configurações de identidade de notificação de aplicativo, bem como configurações de transporte. Use o mecanismo de configuração compatível para a versão e o ambiente implementados e revise os valores efetivos resultantes. Configuração do servidor de e-mail DXP
Trate a criação, o armazenamento e a rotação de credenciais como uma operação de segurança controlada separada. Este guia não exige uma nova credencial se já existir uma credencial funcional aprovada. Nunca cole um segredo em um artigo público, exemplo de repositório, registro DNS ou captura de tela de suporte. Em vez disso, faça referência ao armazenamento secreto aprovado e ao operador responsável. Confirme se os logs de implantação e os relatórios de erros não imprimem a credencial durante o teste.
O serviço DXP documentado é para comunicação transacional automatizada em sites. O guia direciona os clientes que precisam de outros recursos SendGrid , como o uso de seu próprio modelo HTML personalizado, para uma conta assinada separadamente ou outro provedor SMTP . Confirme o uso pretendido em vez de presumir que o acesso ao DXP SMTP é acesso irrestrito a uma conta SendGrid gerenciada pelo cliente. Uma conta separada tem sua própria propriedade e procedimento de autenticação de domínio.
Solicitar autenticação para cada domínio de envio
Para a rota DXP documentada, entre em contato com a Optimizely com o domínio de envio para obter assistência na ativação da autenticação do remetente. O mesmo guia diz que DKIM deve ser solicitado para cada domínio de envio de email e requer registros DNS adicionais. Obtenha o conjunto de registros e o plano de ativação exatos para o ambiente antes de publicar qualquer coisa. Não é universal seletor, CNAME o destino ou a chave privada podem ser derivados do nome do produto. Domínio DXP e configuração DKIM
Liste todos os domínios De visíveis usados pelas notificações relevantes. Se aplicativos multisite ou fluxos de trabalho configurados separadamente usarem domínios diferentes, pergunte ao suporte qual configuração de autenticação cobre cada um deles. Não presuma que a verificação do domínio corporativo principal ativa automaticamente todos os subdomínios ou marcas alternativas. Registre quem deve confirmar a ativação do remetente após a publicação DNS .
A página DXP inclui exemplos de políticas SPF . Trate-os como exemplos de documentação, não como prescrições completas para um domínio de produção. Determine o verdadeiro proprietário do envelope, preserve outros remetentes autorizados e mantenha uma política SPF válida. Avalie os limites de pesquisa recursiva antes de mesclar a autorização. Se o transporte configurado for diferente do serviço DXP documentado, obtenha as instruções atuais do próprio transporte. SPF RFC 7208
Publique cada registro DKIM fornecido no proprietário exato com o tipo fornecido. Preserve os seletores ativos durante uma transição planejada, resolva conflitos CNAME antes de salvar e mantenha as chaves privadas fora DNS . Consulte os servidores autorizados para verificar o nome e o valor resultantes; uma visualização do editor DNS não é suficiente. Um registro público oferece suporte à validação somente quando a mensagem de saída real usa sua identidade de assinatura correspondente. DKIM RFC 6376
Mantenha a identidade do remetente e a política DMARC coordenadas
Combine o endereço De visível pretendido antes do teste. Um nome de host SMTP correto e uma credencial funcional não provam que o aplicativo usa o domínio De aprovado. Registre a identidade de notificação efetiva e qualquer substituição no nível do aplicativo separadamente da configuração de transporte. Revise o tratamento de respostas para que os destinatários não sejam direcionados para uma caixa de correio autônoma sem uma decisão comercial.
Inspecione a política DMARC atual para o domínio visível e mantenha sua aplicação aprovada, alinhamento e configuração de relatórios. DMARC é bem-sucedido quando pelo menos uma identidade SPF ou DKIM aprovada se alinha ao modo aplicável. Um domínio de assinatura de propriedade do provedor pode passar na validação criptográfica sem se alinhar com o domínio De visível da organização. Não responda enfraquecendo a política de todo o domínio antes de examinar a rota suportada de autenticação do remetente. DMARC RFC 9989
A conectividade do aplicativo, a autenticação do provedor e o posicionamento da caixa de entrada são resultados de aceitação separados. Um log do CMS que informa que uma mensagem foi enviada não é um recibo da caixa de correio final. Uma mensagem recebida com aprovação DMARC ainda pode ser filtrada por outros motivos. Mantenha essas distinções no relatório de alterações para que uma camada bem-sucedida não esconda um problema não resolvido em outro lugar.
Planilha de rota reutilizável de CMS e DXP
Preencha uma cópia separada para cada ambiente de implementação e identidade de envio materialmente diferente.
- Versão do CMS, modelo de hospedagem, projeto e ambiente: ______.
- Fluxo de trabalho exato, gatilho sintético e destinatário esperado: ______.
- Fonte de configuração, revisão de implantação e configurações de tempo de execução efetivas: ______.
- Provedor de transporte, proprietário da conta e apenas referência secreta aprovada: ______.
- Visível de, nome de exibição, destino da resposta e expectativa de envelope: ______.
- Caso de suporte confirmando a aplicabilidade do DXP e cada domínio de envio: ______.
- Proprietários DNS emitidos, tipos, valores e requisitos de ativação: ______.
- Políticas SPF e DMARC existentes e conjunto de alterações aprovado: ______.
- Respostas confiáveis, tempos de consulta e status de verificação do provedor: ______.
- Evidência de envio, envio SMTP e entrega do provedor: ______.
- Mensagem recebida de, envelope, todos os pares DKIM d=/s= e resultados confiáveis: ______.
- Implantação de reversão, plano de restauração DNS e aceitação humana: pendente.
Diagnóstico fictício de uma falha de notificação de produção
Este exemplo é fictício. Uma equipe testa com êxito uma notificação de aprovação na preparação e implanta o aplicativo. As mensagens de produção usam um domínio De visível diferente. O envio SMTP foi bem-sucedido, mas um receptor independente relata uma assinatura de provedor válida que não está alinhada com esse domínio de produção. A equipe propõe copiar um alvo Campaign DKIM no DNS porque ele também pertence à Optimizely.
O diagnóstico proposto compara a identidade de produção efetiva com os domínios cobertos pela solicitação de suporte DXP. Neste cenário, apenas a identidade de preparação foi incluída. O plano corretivo é solicitar a configuração de autenticação suportada para o domínio de envio de produção, publicar os registros emitidos e testar novamente o fluxo de trabalho de aprovação real. O empréstimo de um registro do Campaign não estabeleceria que o signatário DXP o utiliza. Este é um exemplo prático, não um teste ao vivo ou uma afirmação sobre qualquer implantação do cliente.
Recuperar na camada que mudou
Se o aplicativo parar de enviar mensagens, compare as configurações de implantação e transporte antes de reverter DNS . Se a verificação do domínio falhar, compare os proprietários emitidos pelo suporte com respostas confiáveis. Se a autenticação for aprovada, mas a entrega falhar, inspecione as respostas do provedor e do destinatário sem ampliar desnecessariamente as permissões do remetente. Preserve as evidências antes de novas tentativas para que notificações duplicadas possam ser identificadas.
A reversão deve restaurar a implantação ou alteração DNS estreitamente afetada, e não alternar todas as credenciais ou redefinir toda a zona. Retire os seletores substituídos somente depois que o proprietário do email confirmar que nenhuma rota ativa ou na fila precisa deles. A filial DXP documentada foi estabelecida, mas a aplicabilidade mais ampla da versão do CMS, as configurações específicas do locatário, os valores emitidos pelo suporte, DNS ativo, as mensagens recebidas, a revisão visual e a aprovação humana do PME permanecem pendentes. Nenhuma configuração de aplicativo, credencial, registro DNS ou fluxo de trabalho em tempo real foi alterado para este guia.
Mantenha a segurança do transporte fora de exemplos copiados
A página pública mistura exemplos de arquivos de configuração e inclui uma configuração de código desabilitado para SSL. Este artigo não aprova essa configuração ou um snippet com versão incompatível. Faça com que o proprietário da implantação confirme o transporte compatível e o comportamento TLS para o tempo de execução real sem expor credenciais. No caso fictício, a assinatura do provedor por si só não determina o resultado SPF não especificado.
Separe a aceitação de mensagens da implementação de políticas
Um resultado SPF alinhado e aprovado pode satisfazer uma avaliação de mensagem, mas não justifica por si só mover um domínio inteiro para rejeição. RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínios p=reject e alerta sobre a interoperabilidade de correio indireto. Faça um inventário de todos os remetentes legítimos e rotas indiretas antes que o proprietário da política aprove a aplicação. Nenhuma alteração DNS , operação de locatário ou teste de mensagem recebida foi executada para este artigo.