Escopo e pré-requisitos
Zoho Assist oferece suporte ao envio de domínios da empresa por meio de seu fluxo de verificação de domínio de e-mail. Este guia cobre esse produto DKIM configuração, nem todos os aplicativos Zoho . O administrador do Assist precisa de acesso à configuração de e-mail e de um proprietário DNS que possa publicar a chave pública gerada. A verificação de um domínio em outro serviço Zoho não deve ser tratada como conclusão aqui.
Configure a rota documentada
- Etapa 1. Abra Configurações, Geral, Configuração de e-mail no Zoho Assist. Selecione Verificação de domínio e Adicionar e verificar novo domínio.
- Etapa 2. Insira a parte do domínio do endereço do remetente da empresa pretendida e escolha Gerar chave. Salve o nome do host e o valor retornados na solicitação de alteração, verificando se o domínio é realmente usado para envio.
- Etapa 3. No gerenciador DNS autoritativo, crie um Registro TXT com esse nome de host e o valor completo fornecido. O exemplo de nome de host da documentação é uma ilustração, não uma seletor você deve reutilizar quando a conta fornecer uma diferente.
- Passo 4. Verifique como o provedor DNS trata um nome totalmente qualificado. Se adicionar automaticamente o nome da zona, insira apenas o rótulo relativo necessário para obter o nome do host final exato.
- Etapa 5. Retorne à tela Verificação de domínio e escolha Verificar agora. Assist diz que o tempo de verificação depende do TTL do registro e pode levar algumas horas. Um status positivo confirma que o serviço encontrou seu registro; não é uma garantia da caixa de entrada do destinatário.
- Etapa 6. Acione a notificação relevante do Assist do endereço da empresa pretendido para uma caixa de correio de teste externa aprovada. Colete a mensagem após todo o tratamento de saída e inspecione o domínio de assinatura DKIM .
- Etapa 7. Registre o tipo de notificação, o inquilino e a identidade do remetente. Repita para um domínio diferente, em vez de assumir que todos os técnicos e modelos compartilham a mesma identidade autenticada.
Riscos específicos do produto
Se a entrada TXT estiver presente, mas o Assist não puder verificá-la, compare o nome completo e a chave completa com os valores gerados atualmente. Vários registros TXT no mesmo seletor DKIM , duplicação acidental de domínio e alterações feitas em um host DNS inativo merecem atenção. O procedimento Assist citado especifica DKIM , não um Assist universal SPF incluir ou um personalizado Return-Path receita. Não adicione valores especulativos DNS para fazer uma lista de verificação parecer completa. A autenticação pode melhorar a confiança, mas não pode garantir o posicionamento na caixa de entrada.
Prove a rota na extremidade receptora
Use uma caixa de correio externa aprovada e salve a mensagem bruta completa com seu carimbo de data/hora e identificador de mensagem. Nenhum teste de inquilino ativo é reivindicado neste guia. A seguir está uma planilha de aceitação para ser preenchida durante a implementação, não um recorde dos resultados observados.
- Campo de evidência: Visível de; O que registrar: Endereço e domínio reais; Pergunta de aceitação: esta é a identidade do remetente pretendido?
- Campo de evidência: Envelope; O que registrar: Return-Path e domínio SPF relatado pelo receptor; Pergunta de aceitação: Qual domínio SPF realmente autenticou?
- Campo de evidência: SPF ; O que registrar: Resultado do receptor confiável e identidade avaliada; Pergunta de aceitação: foi aprovado e essa identidade está alinhada?
- Campo de prova: DKIM ; O que registrar: Todo d= domínio, s= resultado do seletor e do receptor; Pergunta de aceitação: pelo menos uma assinatura aprovada está alinhada?
- Campo de evidência: DMARC; O que registar: Resultado do receptor e política aplicável; Pergunta de aceitação: Existe um caminho de passagem alinhado?
- Campo de evidência: Rota; O que registrar: Produto, conta e tipo de mensagem; Pergunta de aceitação: O teste utilizou o caminho de produção?
DMARC precisa de pelo menos um caminho SPF ou DKIM alinhado e de passagem. Uma assinatura de passagem de um domínio de serviço não relacionado não é suficiente. Estrito alinhamento requer igualdade exata de domínio; o alinhamento relaxado usa o relacionamento de domínio organizacional aplicável. Verifique as configurações reais de alinhamento do domínio antes de declarar sucesso. Um subdomínio não é uma correspondência estrita automática. SPF usa a identidade SMTP , não o nome de exibição ou Responder para. Consulte o glossário de alinhamento ao registrar a decisão.
Usar Authentication-Results do sistema receptor em que você confia, não de um cabeçalho fornecido por um remetente arbitrário. Capture todas as assinaturas em vez de parar na primeira falha. Para correspondência encaminhada, compare um teste direto com uma cópia encaminhada: o encaminhamento pode alterar a avaliação SPF ou alterar o conteúdo assinado. Não diagnostique esses efeitos adicionando o endereço do remetente à autorização do seu provedor.
Diagnosticar falhas sem ampliar o acesso
Compare primeiro DNS autoritativo com os nomes de registro exatos configurados e, em seguida, verifique a visibilidade recursiva e a validação do serviço. Um nome errado, chave truncada ou conflito CNAME não é corrigido aguardando por caches. Mantenha apenas uma política SPF por proprietário e verifique o limite de dez prazos de pesquisa de DNS nas inclusões e redirecionamentos avaliados antes de mesclar outro remetente. Os seletores DKIM pertencem a configurações de assinatura individuais; não substitua o registro de outro aplicativo para forçar um resultado de validação.
Se a autenticação for aprovada, mas a entrega for ruim, inspecione a resposta do destinatário, a reputação, o conteúdo e as permissões de envio separadamente. O passe DMARC não promete aceitação ou colocação na caixa de entrada. Se nenhum dos caminhos estiver alinhado, interrompa a expansão e corrija a configuração real do remetente. Não enfraqueça a política DMARC de todo o domínio para esconder uma única falha do produto.
Transferência e recuperação
Salve a diferença DNS aprovada, os resultados da pesquisa pública, o status do serviço e a planilha de mensagens recebidas redigida com um proprietário nomeado. Mantenha credenciais e chaves privadas fora dos tickets. Em caso de falha, pause o trabalho de envio afetado ou use uma rota previamente testada sob o controle do proprietário do serviço. Restaure apenas os registros alterados que pertencem a esta integração; mantenha as chaves públicas necessárias para mensagens em trânsito. Teste novamente após reversão, rotação de chave, migração de domínio ou alteração na retransmissão de saída. Feche a mudança somente quando o proprietário do produto e o administrador de correio puderem explicar a cadeia de identidade observada.
Confirme o limite do provedor
A fonte pública não estabelece um seletor universal, um cronograma de sobreposição de rotação, um direito de endereço do remetente ou uma receita de envelope personalizado. Mantenha essas dúvidas com o Assist Support quando aplicável; não os infira de outro produto Zoho . Sua linguagem de posicionamento na caixa de entrada é uma simplificação excessiva: a assinatura válida não substitui as decisões de filtragem do destinatário.
Trabalhe em um caso de diagnóstico fictício
Somente caso escrito fictício: ZA-01 pressupõe que shop.example foi verificado em um aplicativo Zoho diferente, mas o Assist não verificou sua chave gerada para notificações de support@shop.example . Nenhuma assinatura assistida recebida ou resultado de envelope é conhecido. O proprietário do Assist deve concluir o fluxo de trabalho do domínio deste produto e coletar uma notificação controlada; o status verde do outro aplicativo não pode fechar a linha de evidências do Assist. Nenhum locatário, DNS , comando de servidor ou mensagem foi exercido neste caso.
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.