Veeva possui superfícies de e-mail distintas. Este procedimento segue a documentação atual do Vault CRM Approved Email, e não notificações genéricas do aplicativo Vault ou uma tela de CRM herdada equivalente presumida. Identifique o fluxo de trabalho licenciado e o modelo exato da identidade antes de alterar um domínio. A autenticação por si só não estabelece consentimento de marketing de saúde ou conformidade legal.
Provisione o domínio de envio com o Support
Defina um domínio de envio, de preferência um subdomínio dedicado sob recomendação do fornecedor, e abra um tíquete de suporte do Vault CRM para provisioná-lo. Publique os registros específicos Suprimentos de suporte: SPF TXT, DKIM TXT e um rastreamento CNAME. O guia especifica 2048 bits Chaves DKIM . Se sua interface DNS exigir agrupamento, mantenha os fragmentos em um registro de recurso TXT , e não em registros de chave concorrentes. Peça ao suporte para validar as entradas. Após a verificação, configure aprovado_email_domain__v na configuração personalizada de e-mail aprovado. Configuração do domínio do Vault CRM
Ao usar um subdomínio, coordene os endereços De do modelo com o campo de fórmula do usuário e as permissões descritas no guia e, em seguida, sincronize o conteúdo. Um relacionamento de subdomínio pode satisfazer DMARC alinhamento, mas o alinhamento estrito requer domínios de correspondência exata para o mecanismo em que se baseia. Não presuma que uma alteração Responder para corrige o alinhamento.
Preservar rastreamento e conteúdo anterior
Mantenha os registros de autenticação distintos do CNAME de rastreamento. O fornecedor documenta o tratamento somente DNS para esse CNAME ao usar Cloudflare e compatibilidade CAA para emissão de certificados HTTPS. Resolva questões de política de certificados com o proprietário da segurança, em vez de desativar as proteções casualmente. A remoção de um domínio de envio do e-mail aprovado pode interromper o acesso a links em mensagens enviadas anteriormente. Planeje a retirada de conteúdo antigo e também de novos envios; excluir o domínio não é uma reversão de rotina.
Verifique o endereço do usuário gerado quanto a nomes com espaços ou caracteres especiais; uma fórmula pode gerar um endereço inválido mesmo quando DNS está correto. Conceda acesso de leitura ao campo, faça referência a ele em cada modelo aplicável e sincronize o Vault com o Vault CRM. Para domínios registrados antes de 12 de janeiro de 2022, o guia orienta os administradores ao suporte para ativação de HTTPS. Um antigo caminho CDN de terceiros também precisa de coordenação de suporte. Não faça downgrade para HTTP ou altere a política de certificados apenas para obter uma verificação verde DNS .
Verifique DNS e um resultado de recebimento real
Antes de alterar o e-mail aprovado do Vault CRM, exporte os valores DNS existentes, registre a diferença aprovada e nomeie o proprietário da reversão. Confirme se o editor DNS espera um rótulo relativo ou um nome totalmente qualificado; duplicar o sufixo de domínio cria um recorde que nenhum verificador pretendido encontrará. Consulte o nome real do proprietário após salvar, incluindo qualquer destino CNAME , em vez de confiar no banner de sucesso do editor.
SPF deve permanecer uma política no domínio relevante e permanecer dentro dos limites de prazo de consulta do DNS em RFC 7208. Adicionar uma inclusão não estabelece alinhamento por si só. Sob RFC 9989, DMARC é aprovado quando pelo menos um resultado SPF ou DKIM bem-sucedido se alinha com o domínio From visível no modo aplicável. Não exija que ambos os mecanismos se alinhem como uma condição imposta pelo padrão e não confunda uma passagem de domínio de provedor com uma passagem de domínio de cliente alinhada.
Envie um e-mail aprovado gerado com o modelo relevante e a identidade do usuário para uma caixa de correio que você controla. Salve os resultados de autenticação confiável do sistema receptor, De visível, identidade do envelope, valores DKIM d= e s=, carimbo de data/hora e status do provedor. Uma pesquisa DNS mostra apenas a chave disponível; RFC 6376 a verificação também avalia a assinatura da mensagem recebida. Use conteúdo não confidencial e evite expor mensagens completas dos clientes a verificadores públicos.
Use uma decisão limitada de aceitação e reversão
Apenas caso de diagnóstico escrito fictício: VE-01 assume De alex@clinic.example e um válido Assinatura DKIM com d=mail.clinic.example. Esta assinatura se alinha no modo relaxado, mas não no modo estrito. SPF e outras assinaturas são desconhecidos, portanto, a falha DMARC em modo estrito não foi estabelecida. O proprietário do Vault CRM deve comparar o modo de alinhamento efetivo e a fórmula do modelo, verificar os endereços gerados dos usuários afetados e sincronizar o conteúdo aprovado antes de testar novamente. Nenhum dado do paciente é necessário. Nenhuma conta, DNS , retransmissão ou mensagem foi testada para este exemplo.
Se o teste falhar, separe DNS ausente, errado seletor, configuração de provedor inativa, roteamento inesperado e modificação de mensagens antes de fazer outra alteração. Teste novamente o mesmo fluxo de trabalho após cada correção aprovada. Não enfraqueça a política DMARC de todo o domínio para ocultar o problema de um único remetente. Quando a reversão for necessária, restaure o roteamento anterior aprovado ou a configuração do remetente e retenha os registros-chave enquanto as mensagens assinadas na fila ainda precisarem deles. Mantenha as evidências de teste e as exceções não resolvidas com o inventário do domínio. Nenhum acesso de locatário, alteração DNS ou envio real foi realizado na preparação deste guia.
Mantenha um registro de aceitação responsável
Crie uma linha por conta, domínio e rota materialmente diferente. Registre o proprietário da empresa, o proprietário DNS , a referência de mudança, o De pretendido, o De observado, o domínio do envelope e o resultado SPF , cada DKIM d= e s= com seu resultado, modo de alinhamento aplicável, receptor confiável e carimbo de data/hora, estado de ativação do provedor, observação de posicionamento, pergunta não resolvida e próxima ação. Marque os valores ausentes como desconhecidos, em vez de tratá-los como aprovados ou reprovados. O proprietário aceita apenas o percurso pretendido e a identidade suportada pelas provas registadas; caso contrário, mantenha essa rota e siga o plano de recuperação aprovado.
Separe uma mensagem passageira da prontidão para aplicação
RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínio p=reject e alertas 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.