Estabeleça o escopo de envio e branding do Eloqua
Trate uma campanha Eloqua e uma mensagem de vendas personalizada como casos de domínios potencialmente diferentes. Identifique a instância, marca e domínio de envio do Eloqua antes de solicitar alterações ao proprietário DNS . A Oracle descreve a conversão para um domínio de marca antes da primeira campanha para novas contas de assinatura. Esse pré-requisito de branding não é, por si só, uma prova de que uma campanha específica seja aprovada DMARC. Ver Autenticação de e-mail e marca Eloqua.
O escopo deste artigo é um plano de implementação e verificação do Eloqua baseado em documentação pública. Chaves exatas, seletor nomes, domínios de envelope e etapas de ativação de locatário devem vir da integração atual do Eloqua ou do fluxo de trabalho de suporte. Não copie registros do OCI Email Delivery ou Responsys simplesmente porque eles também são produtos Oracle.
Confirme o pré-requisito De e devolução
Antes da publicação DNS ou de um envio de teste, confirme se o domínio De pretendido corresponde ao subdomínio de um domínio de retorno do Eloqua já configurado. A Oracle afirma que uma incompatibilidade pode produzir erros de validação e envios bloqueados. Seu exemplo emparelha um subdomínio de envio de go.example.com com return@go.example.com ou bounce@go.example.com . Registre o endereço de retorno e o domínio reais configurados para a marca selecionada; não trate um valor de retorno proposto como uma configuração existente. Ver Configuração de autenticação de e-mail Eloqua, Endereço de devolução de e-mail e padrões de e-mail: endereço de origem e de resposta.
Verifique os padrões de e-mail e quaisquer substituições por e-mail. A Oracle observa que o domínio de bounceback pode ser alterado quando vários domínios forem configurados. Um campo De editável não estabelece que um domínio corporativo arbitrário seja permitido. Se uma regra de assinatura propor um domínio De diferente, obtenha a confirmação específica da conta do remetente corporativo compatível e seu emparelhamento de devolução configurado antes de ativar a rota. Mantenha-o pressionado se esse pré-requisito não puder ser verificado. DKIM assinar a cobertura por si só não elimina esse requisito de envio.
Reconcilie domínios de campanha e remetentes corporativos
A página de configuração de autenticação da Oracle descreve SPF como parte da implantação do Eloqua e solicita a publicação de chave pública no domínio corporativo quando as regras de assinatura do domínio corporativo são enviadas em nome da equipe de vendas. Isso torna o inventário de domínio real importante, especialmente quando campanhas e mensagens de vendas personalizadas usam domínios diferentes. Ver Configuração de autenticação de e-mail Eloqua.
Liste os endereços De permitidos, seus pares de retorno configurados confirmados e o modelo ou regra de assinatura que produz cada um. Capture uma linha de base do caminho da campanha principal e de qualquer caminho de domínio corporativo. Um teste enviado de um subdomínio de marketing não pode estabelecer cobertura de assinatura para o endereço corporativo de um vendedor. Preserve Reply-To separadamente porque as respostas e a autenticação têm finalidades diferentes.
Obtenha e publique um conjunto de alterações específico da conta
Solicite as instruções atuais do Eloqua para a instância e os domínios identificados. O pacote de revisão deve incluir proprietários exatos DNS público, tipos e valores de registro, o domínio de assinatura esperado, etapas de ativação e quaisquer pré-requisitos para domínios de marca existentes. A documentação pública estabelece os conceitos de fluxo de trabalho, mas não fornece um conjunto universal de registros de copiar e colar para cada conta.
Antes da publicação, inspecione a zona atual e identifique a autorização SPF existente. Não adicione uma segunda política SPF do mesmo proprietário. O padrão SPF define a seleção de registros e os limites de consulta DNS; uma adição proposta deve ser avaliada com os mecanismos existentes e não como uma sequência isolada. Ver Estrutura de Política do Remetente RFC 7208. Preserve remetentes legítimos não relacionados e seletores DKIM não relacionados.
Depois que o proprietário DNS publicar as alterações aprovadas, confirme a resposta oficial e peça ao proprietário do Eloqua para concluir a ativação especificada. Grave cada lado de forma independente. Uma chave pública pode estar presente enquanto o aplicativo ainda assina com outra identidade, e o status de um aplicativo pode parecer pronto enquanto uma zona delegada está configurada incorretamente.
Teste cada caminho real de campanha
Somente depois que o emparelhamento De e bounceback configurado passar na validação do Eloqua, envie um pequeno teste consentido da configuração real da campanha para os receptores controlados. Inclua uma rota de domínio corporativo personalizada somente depois que sua configuração de envio compatível e emparelhamento de retorno forem confirmados. Se o Eloqua bloquear um remetente incompatível antes da transmissão, resolva esse pré-requisito antes de diagnosticar a autenticação do receptor. Gravar de, Return-Path, DKIM d= e s=, e os resultados SPF , DKIM e DMARC do sistema receptor. Assinatura DKIM verificação e DMARC alinhamento são testes distintos. Ver Correio identificado por DomainKeys RFC 6376 e Relatório e conformidade de autenticação de mensagens baseadas em domínio RFC 9989.
Compare a mensagem entregue com o inventário de domínio aprovado. Quando um endereço De muda dinamicamente, teste mais de um valor representativo. Não infira a cobertura geral a partir de uma visualização de modelo estático. Verifique também se as respostas vão para a caixa de correio pretendida e se os links rastreados se comportam conforme o esperado, sem tratar nenhum dos testes como prova de autenticação.
Planilha de aceitação de domínio Eloqua
Use uma linha separada para o domínio da campanha e para cada caso de assinatura de domínio corporativo:
- Instância e marca: ____; regra de campanha ou assinatura: ____.
- Endereço real e domínio: ____; proprietário de domínio permitido: ____; Resposta monitorada para: ____.
- Endereço de bounceback e domínio já configurados para esta marca: ____; evidência de que From corresponde ao subdomínio de devolução configurado: ____.
- Padrão versus por e-mail Da substituição: ____; domínio configurado selecionado se vários domínios estiverem habilitados: ____.
- Confirmação de rota de regra de assinatura corporativa e referência de conta/suporte: ____; Resultado da validação do remetente Eloqua antes do envio: ____.
- Instruções de conta ou referência de suporte: ____; proprietário e tipo do registro emitido: ____.
- Dependências SPF existentes e fusão proposta: ____; Seletor DKIM e domínio de assinatura: ____.
- Observação oficial DNS : ____; Confirmação de ativação do Eloqua: ____.
- Carimbo de data/hora do teste controlado e ID da mensagem: ____; receptor: ____.
- Identidade e resultado SPF : ____; Identidade e resultado DKIM : ____; mecanismo alinhado: ____.
- Proprietário da exceção, rota de recuperação e decisão de liberação: ____.
Rejeite linhas com um emparelhamento de bounceback não configurado ou incompatível, uma rota de regra de assinatura corporativa não confirmada, um seletor copiado de outra instância ou uma amostra bem-sucedida com um domínio De diferente. Marque as instruções da conta ausentes como não resolvidas, em vez de substituí-las por uma receita de terceiros.
Diagnóstico fictício de falha na assinatura de vendas
Apenas exemplo fictício: Riverbend confirmou separadamente a rota de remetente corporativo suportada pela conta, configurou seu emparelhamento de retorno para example.com e passou na validação de remetente do Eloqua para mensagens de vendas de salesperson@example.com . Sua rota de campanha de news.example.com também possui um emparelhamento de retorno configurado válido. Estas são suposições explícitas do exemplo, não as configurações do cliente observadas ou a permissão para selecionar um domínio De corporativo arbitrário.
Uma mensagem de vendas entregue passa DKIM com d=news.example.com , mas falha DMARC porque o domínio fictício usa alinhamento DKIM estrito ( adkim=s), o domínio From visível é example.com e não há nenhum resultado SPF de passagem alinhado. Uma amostra de campanha bem-sucedida, portanto, não pode comprovar o alinhamento desta rota de vendas. Sob o alinhamento relaxado DKIM , os domínios de assinatura e De relacionados poderiam se alinhar; o exemplo não deve ser generalizado para esse modo.
A equipe mantém a configuração válida de envio e devolução, solicita a cobertura correta de assinatura específica da conta para a rota corporativa suportada e verifica uma nova mensagem de vendas após a ativação. Se os pré-requisitos De e devolução tivessem sido inválidos, o primeiro diagnóstico teria sido a validação do Eloqua ou a condição de envio bloqueado, e não esta falha de alinhamento da mensagem recebida. Nenhuma conta ou mensagem da Riverbend foi inspecionada.
Fechar o ciclo operacional
Depois que a autenticação funcionar, lide com a integração do ciclo de feedback como uma tarefa operacional separada. A Oracle descreve como entrar em contato com o suporte após a configuração DKIM e concluir o processo de confirmação relevante. Não reivindicar reclamação, o relatório está ativado apenas porque uma mensagem está assinada. Ver Configuração de autenticação de e-mail Eloqua.
Mantenha um plano de reversão para uma alteração de domínio com falha, preserve os seletores em funcionamento até que o proprietário remetente confirme a desativação e teste novamente após alterações na marca, nas regras de assinatura ou no domínio do remetente. A autenticação não garante a colocação na caixa de entrada nem autoriza uma lista de contatos. Registros emitidos por contas, DNS ao vivo, testes de receptor, inspeção visual, aprovação e publicação humana por PME permanecem pendentes para este candidato a documentário.
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.