Escopo da identidade de recrutamento antes da configuração
Documentos Zoho Recruit Configuração > Geral > Configurações de email > Autenticação de email > Adicionar domínio. O endereço inserido recebe um código de verificação, descrito como válido por 15 dias. Após a verificação, Validar expõe SPF e DKIM detalhes para publicação como Registros TXT. Autenticação de e-mail de recrutamento
O escopo proposto deve identificar a organização recrutadora, a conta, a edição, a região, o domínio do remetente pretendido e as categorias da mensagem. Uma agência de recrutamento pode comunicar-se sob várias marcas legítimas, enquanto uma equipe de recrutamento interno pode usar um subdomínio dedicado. Nenhum dos arranjos justifica assumir que cada remetente configurado pertence ao mesmo proprietário de domínio.
Identifique a pessoa responsável pela identidade do candidato e o administrador responsável pelo DNS . Não solicite acesso aos registros de candidatos apenas para revisar a configuração de autenticação. O requisito de implementação do catálogo permanece em aberto: este manuscrito não acessou um inquilino do Recruit, solicitou uma mensagem de verificação ou inspecionou uma comunicação real do candidato.
Mantenha a verificação de endereço separada da autorização DNS
O guia DNS orienta os administradores a copiar os detalhes do registro expostos pelo Validate. Ele discute a combinação da autorização SPF existente em uma política e alerta sobre editores DNS que anexam o sufixo de domínio. Seu SPF exibido e seletor os valores são exemplos e não prova das configurações atuais de uma conta específica. Recrutar configurações DNS
Um código de verificação recebido confirma um ponto de verificação no fluxo de trabalho do aplicativo, mas não é o registro da chave pública em si. Retenha o fato e o horário da verificação sem armazenar o código em um arquivo de projeto permanente. Guarde separadamente a solicitação DNS gerada e a aprovação do proprietário do domínio para aplicá-la.
Se um consultor de recrutamento usar o domínio de um cliente, não deduza a permissão de um nome de empresa conhecido ou de uma troca de e-mail. Estabeleça quem está autorizado a configurar esse domínio e qual identidade de remetente o cliente aprovou. A transferência proposta deve tornar explícita esta relação de propriedade antes que uma nova dependência de envio seja criada.
Revise a política SPF completa sem copiar exemplos
SPF identifica caminhos de envio permitidos para suas identidades SMTP especificadas. Revise a identidade real do envelope da rota antes de decidir a que lugar pertence uma mudança de política proposta. O endereço visível do recrutador por si só não é suficiente para determinar o domínio avaliado, e um valor lembrado Zoho Mail não é uma resposta universal para todos os aplicativos Zoho .
Em um nome de proprietário relevante, vários selecionados Registros SPF causar um erro. A fusão de uma política existente requer, portanto, uma revisão completa, em vez de adicionar um segundo registro para a nova aplicação. Preservar outros remetentes legítimos, ordenação de mecanismos e comportamento de encerramento. Revise também os termos dependentes de DNS aninhados em relação ao limite de avaliação; uma política de curta duração ainda pode depender de uma cadeia mais longa.
Uma revisão política não é um recorde de um resultado de mensagem. A evidência proposta deverá distinguir instruções geradas, publicação aprovada e avaliação real do receptor. Não rotule um domínio como autenticado apenas porque uma sequência de amostra é sintaticamente plausível. RFC 7208 , seção 2.4; RFC 7208 , seção 3.2; RFC 7208 , seção 4.6.4
Verifique o nome do seletor e preencha os dados principais
A Assinatura DKIM fornece um seletor e um domínio de assinatura, que juntos identificam a pesquisa de chave. Mantenha o nome exato do proprietário gerado pela conta e o valor público. Não reutilize o seletor de amostra em um artigo de ajuda nem substitua uma chave existente sem identificar suas dependências ativas.
O comportamento do sufixo do editor DNS é importante. Algumas interfaces acrescentam a zona automaticamente, enquanto outras aceitam um nome totalmente qualificado. Compare o nome de pesquisa final pretendido com a semântica real do editor; remover o sufixo cegamente não é mais seguro do que incluí-lo sempre. Na notação de arquivo mestre, @ independente significa a origem atual, não todos os subdomínios.
Os dados da chave TXT podem ser representados como diversas cadeias de caracteres dentro de um registro. Preserve o valor lógico completo e evite confundir essa representação com vários registros separados. Nenhuma chave de assinatura privada é necessária para uma revisão normal de publicação. Trate as solicitações de credenciais ou de chave privada como uma ação diferente sensível à segurança, e não como um anexo esperado na planilha DNS . RFC 6376 , seção 3.5; RFC 6376 , seção 3.6.2.2; RFC 1035 , seção 5.1; RFC 1035 , seção 3.3.14
Aplique a semântica DMARC em vez de uma abreviação ampla do produto
DMARC avalia o relacionamento entre o domínio do autor e uma identidade de autenticação de passagem. Um caminho SPF alinhado de passagem ou um caminho DKIM alinhado de passagem pode satisfazer o requisito de autenticação; não é um requisito universal que ambos os mecanismos sejam aprovados. Além disso, uma assinatura DKIM não é criptografia de mensagem e não estabelece a confidencialidade da inscrição de um candidato.
A revisão proposta da mensagem recebida registra o domínio From visível, o domínio de assinatura, o seletor, a identidade do envelope relevante e os resultados do receptor confiável. Confirme a rota e o horário da amostra para que provas de outra conta, marca ou transporte não possam ser substituídas acidentalmente. Um ponto de verificação de configuração de domínio bem-sucedido permanece distinto dessas observações de mensagens.
A autenticação não estabelece que uma oferta de emprego seja genuína, que um recrutador esteja autorizado a solicitar um pagamento ou que um destinatário deva divulgar documentos de identidade. Essas decisões de negócios exigem verificação separada. Evite transformar uma declaração de aceitação técnica numa garantia sobre a legitimidade do recrutamento ou conformidade legal. RFC 9989 , seção 4.4; RFC 6376 , seção 1
Planilha de aceitação para operações de recrutamento
Use esta planilha proposta original para preservar a propriedade do domínio e a privacidade do candidato durante todo o projeto.
- Escopo da organização: Conta de recrutamento, edição, região, marca e categorias de mensagem incluídas na aceitação.
- Propriedade do remetente: domínio do autor pretendido, equipe de recrutamento responsável e qualquer limite de autorização do domínio do cliente.
- Ponto de verificação de verificação: evidência de conclusão e carimbo de data/hora sem salvar o código único.
- Registros gerados: nomes exatos, tipos e valores públicos vinculados à conta que os emitiu.
- Dependências existentes: política SPF afetada, seletores já em uso e proprietário da alteração aprovado.
- Aceitação de mensagens: rota representativa, evidência de cabeçalho minimizada, resultados confiáveis e alinhamento interpretação.
- Controles de privacidade: evite anexos de candidatos, respostas de candidaturas e identificadores pessoais desnecessários em material de diagnóstico.
- Decisão de liberação: revisor nomeado, questões de conta corrente não resolvidas e plano de continuidade para comunicações de recrutamento agendadas.
Esta planilha não é uma auditoria concluída. Nenhum dado de candidato foi coletado, nenhum registro DNS foi consultado ou alterado e nenhuma mensagem de recrutamento foi enviada para este manuscrito.
Diagnóstico fictício: uma amostra de outra marca de recrutamento
Uma empresa fictícia de recrutamento autentica um domínio para sua marca principal e posteriormente introduz um endereço de recrutamento específico do cliente. Durante a revisão, um administrador apresenta uma mensagem passageira da marca principal como prova de que a rota voltada para o cliente está pronta. As duas mensagens têm domínios de autor e relações de propriedade diferentes, portanto a conclusão não é suportada.
A correção proposta começa com o inventário do remetente aprovado e a configuração exata gerada pela conta. A equipe solicita evidências apropriadas para o caminho direcionado ao cliente, sem copiar inscrições de candidatos ou encaminhar anexos confidenciais. Também analisa se o proprietário do domínio aprovou a relação de envio proposta.
O relatório final indica qual rota tem evidências e qual permanece não verificada. Ele não infere falsificação de identidade ou falha do provedor apenas com base na falta de evidências. Este cenário é fictício e não descreve uma conta real do Recruit, um teste de mensagem executado ou um incidente verificado.