Escopo do guia para a rota de subdomínio dedicado da Conversica
Convérsica Instruções de configuração de subdomínio, atualizado em 29 de outubro de 2025, descreve o registro de um subdomínio de envio dedicado no painel e a publicação dos registros DNS gerados. Este é o percurso percorrido aqui. Não é um guia para uma integração SMTP não relacionada ou uma prova de que todas as contas Conversica têm configurações idênticas. Confirme a conta corrente, assistente e transporte antes de selecionar um caminho de configuração.
O guia exige que o subdomínio informado em Adicionar Domínio seja utilizado exclusivamente pelo assistente Conversica. Comece com um nome que a organização controle e não tenha atribuído a outro serviço. Trate a escolha como uma decisão de roteamento e propriedade, não apenas uma preferência de marca. A fonte explica que esse acordo permite que a Conversica cuide do envio e recebimento de e-mails do assistente; substituir registros por um nome já utilizado pode, portanto, afetar mais do que a autenticação de saída.
Registre quem é o proprietário DNS , quem administra o assistente, quais categorias de mensagens o utilizam e quais dependências existentes devem permanecer intactas. Evite copiar endereços de leads ou conteúdo de conversas nesse inventário. O domínio, rota e referência de configuração são suficientes para iniciar a revisão técnica. Nenhum dado de assistente, domínio ou destinatário foi acessado para este manuscrito.
Registre o subdomínio e preserve o conjunto de registros gerado
A navegação documentada é Configurações DNS , Adicionar domínio e, em seguida, o subdomínio desejado, em vez de apenas o domínio organizacional. Configurações avançadas permitem personalizar DKIM seletores. A abertura do ID de domínio resultante exibe nove registros: dois TXT , três MX e quatro CNAME registros. Preserve os nomes de proprietários, valores e prioridades MX reais gerados, em vez de tratar uma captura de tela ou um exemplo lembrado como um modelo universal. Guia de configuração do Conversica
As entradas TXT cobrem SPF e FBL SPF . As entradas MX cobrem dois registros de roteamento de correio e FBL MX . As entradas CNAME cobrem verificação, links e dois registros DKIM . Mantenha essas funções distintas na solicitação de mudança. Um alias de propriedade verificado não substitui nenhum dos alias DKIM , e um link de rastreamento funcional não prova que o caminho de retorno ou a rota de recebimento estejam corretos.
O guia oferece download de CSV para os registros emitidos e um link gerado da página de configuração DNS que pode ser enviado a uma equipe de TI. Um link gerado pode transmitir capacidade de configuração ou informações ao seu destinatário, portanto, use um destinatário aprovado e uma rota de compartilhamento. Este guia não gera, transmite ou testa tal link. Um registro de mudança local pode identificar a transferência autorizada sem expô-la em um artigo público.
Preservar as restrições de modo SPF e DNS do provedor
Conversica diz explicitamente que Macros SPF não são permitidos no configurado Registro TXT e que o registro deve conter conversica.com . Essas são restrições do produto, não limitações gerais do SPF . Não as reduza a sugestões nem reescreva silenciosamente as instruções geradas para se adequarem a um padrão de automação existente. Se um gerador de política organizacional usar macros, resolva a compatibilidade com o provedor e o proprietário da política antes de continuar. Guia de configuração do Conversica
Para DNS gerenciado pela Cloudflare, o mesmo guia exige que todos os registros CNAME relacionados ao Conversica sejam apenas DNS , em vez de proxy. Esta instrução tem como escopo a configuração documentada. Não é permissão para alterar configurações de proxy, rede ou segurança não relacionadas. Identifique os registros específicos na alteração aprovada e deixe outras dependências de serviço intactas. Registre o modo resultante como um item de aceitação em vez de assumir que um CNAME salvo tem o comportamento necessário.
Os editores DNS usam rótulos diferentes para nomes e valores de proprietários. Copie os campos Domínio e Entrada do provedor nos campos corretos do editor, preservando as prioridades MX separadamente. Confirme o proprietário totalmente qualificado produzido pelo editor para que um sufixo não seja repetido acidentalmente. Um nome aparentemente plausível para o proprietário errado pode deixar o registro pretendido ausente e ainda parecer correto em um ticket de alteração.
Distinguir a nova configuração da migração legada documentada
A Conversica também publica um Guia de migração de DNS legado para DNS aprimorado, atualizado em 30 de setembro de 2021. A idade é importante: estabeleça a aplicabilidade da conta corrente antes de usá-la. Não misture sua contagem de registros intermediários com o procedimento de novos subdomínios de outubro de 2025 ou presuma que todos os domínios existentes ainda exigem essa migração.
O fluxo de trabalho histórico começa com um domínio marcado como Validado (Legado), verifica seis registros legados e adiciona ou confirma a verificação CNAME . Somente após a validação desses registros ele passa para registros DNS aprimorados. O estágio posterior altera as entradas MX herdadas e adiciona as dependências aprimoradas, terminando com nove marcas verdes. Esta é uma migração ordenada, não uma orientação para excluir todos os registros antigos e esperar que o novo conjunto funcione.
Use o ID de domínio atual e os valores emitidos para decidir o que ainda é necessário. Uma planilha de migração deve distinguir registros retidos, alvos alterados e novos registros, com o proprietário da reversão e a confirmação do provedor de qualquer desativação. A referência promocional do guia à criptografia aprimorada não estabelece a confidencialidade do conteúdo da mensagem ou uma garantia TLS específica. Este artigo não faz nenhuma afirmação.
Valide cada registro sem declarar o sucesso da mensagem prematuramente
Após inserir os registros, o guia de configuração direciona o operador para Validar. Marcas verdes indicam entradas validadas com sucesso; um X vermelho exige o exame da configuração. Guarde o resultado de cada registro e o tempo de observação. Se um alias estiver faltando, uma verificação bem-sucedida de outro não fechará todo o requisito de nove registros. Um período de espera não substitui a correção de um proprietário, meta ou prioridade errada.
Uma ordem de diagnóstico proposta é comparar o registro solicitado, a publicação oficial e a observação do provedor antes de considerar um atraso transitório na resolução. A tolerância de tempo do guia legado não é uma promessa de que todas as falhas serão resolvidas automaticamente. Nenhum botão de validação ou consulta DNS foi executado para este artigo. O fluxo de trabalho documentado e a planilha em branco são uma preparação para uma implementação autorizada separadamente.
RFC 7208 , seções 3.2 e 4.6.4 forneça verificações adicionais SPF : evite políticas concorrentes no mesmo proprietário e revise os termos avaliados dependentes de DNS em todo o caminho. Uma proibição de macros específica do produto não substitui esses requisitos de protocolo. Da mesma forma, personalizado seletor o suporte não desculpa a publicação de um conjunto de registros DKIM incompleto ou a confusão de um seletor com o domínio de assinatura.
Estabeleça as identidades reais das mensagens após a configuração
Uma mensagem de aceitação inofensiva autorizada separadamente deve identificar o domínio visível do autor, a identidade do envelope, o domínio de assinatura DKIM e o seletor, juntamente com os resultados do receptor confiável. RFC 6376 , seção 3.5 define os campos de assinatura que conectam uma mensagem à sua pesquisa de chave. A existência DNS por si só não mostra que a rota utiliza a assinatura pretendida.
RFC 9989 , seção 4.4 explica alinhamento. Uma identidade de passagem deve ter o relacionamento necessário com o domínio De visível; qualquer identidade de provedor de passagem não é automaticamente suficiente. Mantenha DKIM , SPF , DMARC e observações de entrega do destinatário separadas. Nem nove verificações verdes DNS nem uma assinatura válida comprovam a segurança da solicitação comercial de uma mensagem ou garantem a colocação na caixa de entrada.
Diagnóstico fictício e planilha de aceitação em branco
Uma empresa fictícia de eventos, Cedar Arena, seleciona um subdomínio usado anteriormente para redirecionar um site. Seu operador DNS adiciona os aliases solicitados, mas mantém o comportamento do proxy existente. A revisão proposta identifica um conflito de propriedade e o requisito documentado apenas de DNS antes de autorizar qualquer alteração na produção. A equipe opta por resolver o uso do nome e a configuração específica do registro em vez de desabilitar proteções não relacionadas. Este é um exemplo de planejamento fictício, não uma validação real ou teste de rede com falha.
- Aplicabilidade de conta, assistente, rota e guia atual: ______
- Propriedade exclusiva de subdomínio e revisão de dependência existente: ______
- Nova configuração ou caminho de migração legado confirmado: ______
- Duas instruções TXT , três MX e quatro CNAME com proprietários exatos: ______
- Restrição macro SPF e condição conversica.com revisada: ______
- Modo somente DNS CNAME aplicável e escopo aprovado: ______
- Evidência de validação por registro e erros não resolvidos: ______
- Identidades reais das mensagens, alinhamento e portas de aceitação restantes: ______
Evidências originais de implementação, revisão humana, aplicabilidade atual, rotas de produção, acessibilidade visual e liberação do proprietário permanecem em aberto. Nenhum registro, configuração de proxy, controle de conta ou mensagem foi alterado ou criado.