Mantenha o Account Engagement separado de outros produtos de email Salesforce
Salesforce Account Engagement tem seu próprio fluxo de trabalho de gerenciamento de domínio. Comece confirmando se a mensagem foi enviada por meio do Account Engagement, anteriormente chamado de Pardot, em vez do email principal Salesforce ou do Marketing Cloud Engagement. Uma receita DNS para outro produto Salesforce pode usar controles diferentes e não deve ser importada simplesmente porque a organização usa o mesmo fornecedor. Este guia aborda a verificação do domínio de envio do Account Engagement, DKIM e o caminho de retorno personalizado assistido por suporte opcional.
Liste cada unidade de negócios, marca e domínio De pretendido usado pela conta. Inclua o remetente real selecionado pelas configurações de campanha e automação. Um domínio que aparece no endereço de caixa de correio de um usuário não é configurado automaticamente para cada rota do Account Engagement. Designe um proprietário de marketing e um administrador DNS para revisar o inventário juntos antes de alterar os registros de um domínio compartilhado.
O objetivo de aceitação é uma mensagem recebida controlada com um mecanismo de autenticação de passagem alinhado. A validação da propriedade do domínio, a publicação DNS e um status de gestão verde são evidências intermediárias úteis. Nenhum por si só prova que uma campanha específica utilizou a identidade pretendida ou que um servidor receptor aceitou a sua autenticação.
Entenda o caminho SPF padrão antes de editar DNS raiz
Salesforce's Orientação sobre DNS de envolvimento da conta afirma que o e-mail do Account Engagement passa SPF por meio de sua infraestrutura de envio controlada e não requer alteração SPF do cliente para essa configuração padrão. Não adicione uma inclusão genérica Salesforce SPF ao domínio raiz da organização apenas porque o nome do produto aparece em um DMARC relatório. Confirme primeiro a rota real e a identidade avaliada.
SPF autentica o SMTP CORREIO DE identidade, com tratamento separado para HELO, sob RFC 7208. Seu resultado é distinto de alinhamento com o De visível. Uma verificação SPF de domínio de provedor bem-sucedida pode coexistir com SPF desalinhado. Alterar a política de um domínio diferente não altera o domínio de envelope que uma mensagem usa.
Preservar a política SPF necessária aos outros serviços da organização. Se uma configuração personalizada autorizada separadamente exigir uma alteração de política, revise uma política completa desse proprietário, incluindo os termos de consulta de DNS aninhados e o limite de pesquisa de protocolo. Não crie um segundo Registro SPF ou remova remetentes não relacionados para abrir espaço para um requisito não verificado.
Verifique a propriedade e DKIM como registros separados
Use o gerenciamento de domínio para identificar o domínio de envio de e-mail pretendido e suas entradas DNS esperadas. O Orientação DNS distingue a chave de validação do domínio de seu DomainKey. O valor de validação estabelece a propriedade para envio; o valor DKIM oferece suporte à assinatura de mensagens. Preserve ambos os propósitos na planilha em vez de tratar qualquer Registro TXT contendo um valor Salesforce como evidência intercambiável.
Copie os valores da conta real. Salve o proprietário completo do registro, tipo, valor e data da instrução antes de fazer a alteração DNS . Verifique se outra conta do Account Engagement ou um serviço diferente já depende do mesmo proprietário. Não substitua um registro conflitante, reutilize o valor de outro cliente ou altere um seletor a um nome inventado. Peça suporte para uma resolução apoiada quando os arranjos de contas colidirem.
Mantenha o domínio de envio de e-mail distinto do domínio rastreador. Salesforce alerta explicitamente contra o uso de domínio idêntico para essas duas funções. Um nome de host de rastreamento de marca não é a mesma coisa que o domínio De, mesmo quando ambos compartilham um pai. Dependências de rastreamento de inventário separadamente para que o trabalho de autenticação não altere inadvertidamente URLs de ativos ou links de campanha.
Publique o DomainKey por meio do fluxo de trabalho documentado
Salesforce's Instruções de implementação DKIM exigem a função de Administrador do Account Engagement. No aplicativo Lightning, abra Configurações de envolvimento da conta e, em seguida, Gerenciamento de domínio. Na interface alternativa do Account Engagement, o ponto de partida documentado é Admin. Em Domínios de envio de email, abra Entradas DNS esperadas para o domínio escolhido e copie o valor DomainKey para publicação como TXT .
Use o proprietário e o valor mostrados para essa conta e domínio. O artigo atual diz para permitir até 24 horas para que a assinatura entre em vigor após a adição do registro. Trate isso como uma orientação de tempo do provedor, não como uma garantia de que todo cache ou receptor DNS será atualizado no mesmo instante. Registre o horário de publicação e aguarde o estado esperado antes de julgar um novo teste.
Confirme a resposta DNS público, incluindo o proprietário exato e totalmente qualificado. Às vezes, os editores DNS acrescentam o nome da zona ao campo do host, criando um sufixo duplicado quando um nome completo é inserido. Revise a resposta resultante em vez de confiar no formulário de entrada. Salve qualquer erro de gerenciamento de domínio e seus detalhes para que o suporte possa investigar a falha real em vez de um status parafraseado.
Decida se um caminho de retorno personalizado é necessário
Salesforce's Artigo de suporte DMARC descreve DKIM alinhado como o caminho DMARC normal e explica que o padrão caminho de retorno domínio não se alinha com o De visível. Ele também documenta uma solicitação de caminho de retorno personalizado com suporte. A limitação declarada é um domínio fixo de caminho de retorno personalizado por unidade de negócios, em vez de um domínio variável selecionado para cada mensagem.
Antes de solicitar esta opção, identifique o requisito comercial. Uma organização que precisa SPF alinhado, bem como DKIM deve avaliar o arranjo real do domínio e o modo de alinhamento com suporte. Uma unidade de negócios que envia marcas não relacionadas não deve presumir que um caminho de retorno fixo possa se alinhar com todos os domínios De. Mantenha essa questão de design em aberto até que as identidades observadas e a configuração suportada a resolvam.
Obtenha os registros DNS exatos do caso de suporte e peça ao proprietário DNS para revisar conflitos e dependências. Este artigo não fornece nenhum destino universal de caminho de retorno personalizado ou opção de ativação. Publicar registros adivinhados ou copiar a configuração do domínio de rejeição de outro produto pode interromper uma rota de trabalho sem atender ao requisito.
Teste o remetente selecionado por meio do fluxo de mensagens real
Envie mensagens controladas e inofensivas por meio de cada domínio de envio e rota de unidade de negócios materialmente diferentes. Use a mesma seleção de remetente da campanha ou automação planejada. Registre a referência da campanha, ID da mensagem, horário UTC e destinatário do teste externo. Se um recurso de visualização ou teste usar um caminho diferente da produção, resolva essa diferença antes de tratá-la como evidência representativa.
No sistema de recebimento confiável, capture From, Return-Path e todos os domínios e seletores de assinatura DKIM . RFC 6376 define os valores d= e s= usados para localizar a chave de verificação pública. Compare o domínio de assinatura observado com o domínio de envio configurado. Um registro DNS pode estar correto enquanto uma mensagem ainda usa um remetente inesperado ou outra rota.
Aplicar RFC 9989 aos resultados reais. DMARC pode passar por uma passagem alinhada Assinatura DKIM ou passando SPF alinhado. Registre qual mecanismo forneceu o resultado e qual modo de alinhamento aplicado. Mantenha autenticação SPF , alinhamento SPF , autenticação DKIM e alinhamento DKIM em campos separados. Isso evita que um único status verde oculte um requisito não testado.
Solucione o problema do limite com falha em vez de alterar todos os controles
Se o domínio de envio não for verificado, compare sua chave de validação e o proprietário exato DNS com as entradas DNS esperadas. Se DKIM estiver ausente após o período de ativação esperado, confirme o domínio De e a conta selecionados e verifique os erros de gerenciamento de domínio. Se uma assinatura falhar, verifique o seletor e o valor público e inspecione qualquer sistema downstream que altere a mensagem após a assinatura.
Se DMARC falhar durante a passagem SPF , investigue o alinhamento e se DKIM alinhado foi configurado para esse remetente. Não trate o sucesso padrão SPF como uma promessa de sucesso DMARC . Se um caminho de retorno personalizado estiver envolvido, compare a identidade do envelope observada com a configuração fixa da unidade de negócios e as instruções fornecidas pelo suporte. Preservar uma mensagem representativa de falha para diagnóstico.
Mantenha a política DMARC da organização e os destinos de relatórios sob sua propriedade existente. O artigo Salesforce descreve a necessidade de monitoramento DMARC externo em vez do Account Engagement coletar esses relatórios de falhas. O trabalho de autenticação DNS não deve substituir silenciosamente os destinos de relatórios ou reduzir a aplicação entre remetentes não relacionados. Revise qualquer alteração de política proposta separadamente com os proprietários de correio e segurança.
Planilha de domínio do Account Engagement
- Conta, unidade de negócios, marca e fluxo de trabalho de envio: ____.
- Endereço De selecionado e domínio de envio de e-mail configurado: ____.
- Domínio rastreador separado e suas dependências existentes: ____.
- Chave de validação e referências de registro DKIM de entradas DNS esperadas: ____.
- Respostas DNS público, horário de publicação e status de gerenciamento: ____.
- Projeto de caminho de retorno personalizado padrão ou assistido por suporte: ____.
- Limitação do caminho de retorno personalizado e confirmação de suporte quando relevante: ____.
- Teste ID da mensagem, hora UTC, De, Return-Path e identidades DKIM : ____.
- Resultados de autenticação confiável e mecanismo DMARC alinhado: ____.
- Exceções, monitoramento do proprietário e recuperação aprovada: ____.
Exemplo fictício de sucesso SPF sem alinhamento
Apenas caso escrito fictício: AE-01 assume que a unidade de negócios Norte envia como news@example.org e a unidade de negócios Sul envia como news@example.net . Um caminho de retorno personalizado fixo proposto em bounce.example.org pode se alinhar com o primeiro no alinhamento SPF relaxado, mas não pode ser assumido que esteja alinhado com o segundo não relacionado. As assinaturas DKIM e os resultados SPF permanecem desconhecidos, portanto, nenhuma das rotas possui um veredicto DMARC declarado. Os proprietários de marketing e e-mail devem separar as configurações da unidade de negócios e validar DKIM alinhado por domínio De selecionado antes de solicitar qualquer edição SPF raiz. Todas as identidades e arranjos são inventados; nenhum caso de suporte, consulta DNS ou mensagem foi executada.
Mantenha a conclusão vinculada a evidências reais
O fluxo de trabalho documentado não verifica as permissões de um locatário real, os valores gerados ou a capacidade de caminho de retorno personalizado. Essas verificações de conta, DNS ao vivo e verificação de cabeçalho, revisão visual e aprovação humana das PME permanecem pendentes. Este guia não é publicado e não deve ser apresentado como prova de que as campanhas de uma organização são autenticadas em produção.
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.