Estabeleça o escopo limitado de configuração do eRecruiter
Este guia cobre o provedor-servidor de e-mail SPF rota descrita no documento oficial do eRecruiter Artigo Registro SPF. A fonte distingue a entrega do provedor de servidores de correio operados pelo cliente e instalações locais. Sua verificação de rota documentada em duas partes usa Administração → Diversos: Mandatorsettings → SMTP & EMail-Settings, onde o inquilino SMTP-Host está vazio, e Administração (em todo o sistema) → Configurações estáticas atuais, onde SmtpHost é mostrado como “epunkt-smtp...” ou “er-mail...”. Estes são os padrões exibidos herdados da fonte, não uma nova regra executável de correspondência de nome de host. Confirme o console atual, os valores completos de configuração e a aplicabilidade da rota com o administrador autorizado. Especifica a:er-mail.erecruiter.net, expressamente não incluído. A entrega cliente-servidor não requer autorização desse provedor.
O âmbito de implementação apoiado é, portanto, limitado: identificar a rota documentada, rever a autorização apropriada SPF e planear a verificação. Este artigo não estabelece um eRecruiter atual DKIM fluxo de trabalho, emitido seletor, chave de assinatura ou implantação completa pronta para DMARC. Mantenha esse escopo mais amplo sem solução, em vez de preenchê-lo com uma receita genérica. O título do catálogo é mantido, mas o seu requisito de implementação total ainda necessita de evidências operacionais e de produtos atuais adicionais.
Antes de qualquer alteração, obtenha a configuração real da conta com um administrador autorizado. Registre o ambiente, a propriedade do servidor de e-mail e as categorias de mensagens sem expor as informações do candidato. A correspondência de recrutamento pode conter currículos, detalhes de entrevistas e dados de contato pessoal; nada disso é necessário para decidir qual sistema é responsável pelo caminho do correio de saída. Use referências de configuração e conteúdo de teste inofensivo em vez de copiar uma conversa real de contratação em uma planilha de diagnóstico.
Trate a identificação da rota como uma porta de evidências
Um aplicativo pode gerar uma mensagem enquanto um sistema diferente executa a entrega SMTP final. A questão relevante não é simplesmente se o usuário clicou em Enviar dentro do eRecruiter. É qual serviço transmite a mensagem, qual identidade de envelope é utilizada e quem controla a autorização do remetente. Registre a configuração real do transporte e sua data de observação antes de escolher uma alteração SPF . Um plano de migração anterior ou um cenário lembrado não constituem provas atuais.
Para uma rota controlada pelo cliente, atribua a responsabilidade ao operador desse serviço de correio em vez de assumir que a autorização do fornecedor do aplicativo pertence a cada política de domínio. Para uma rota controlada pelo provedor, estabeleça o domínio e a configuração exatos aos quais a instrução documentada se aplica. Se as informações contábeis disponíveis não distinguirem essas rotas, pare nessa incerteza. Adicionar autorização “por precaução” expande a política sem provar que ela é necessária.
Um inventário de rota deve distinguir produção, teste e quaisquer unidades organizacionais gerenciadas separadamente. Não copie automaticamente DNS de produção para um ambiente de teste nem trate o comportamento de uma conta de teste como evidência de produção. Registre qualquer exceção que use um servidor de email diferente. Estas são etapas de revisão propostas e não alegações de que o produto atual expõe controles adicionais específicos ou que tais exceções existem em uma conta real.
Entenda o mecanismo antes de editar a política
RFC 7208 , seção 5.3 define o mecanismo a. Ele testa o IP de envio em relação aos registros de endereço do domínio do mecanismo, com a família de endereços relevante e quaisquer regras de prefixo especificadas. Não é intercambiável com include, que avalia outra política SPF e aplica seu próprio mapeamento de resultados na seção 5.2. Alterar o tipo de mecanismo porque as inclusões parecem mais familiares pode alterar fundamentalmente a autorização que está sendo avaliada.
O nome do host do provedor é uma dependência, não um endereço IP literal copiado permanentemente na política. Registre por que o mecanismo está presente e qual rota de aplicação precisa dele. Não coloque-o em uma lista de endereços sem um plano de manutenção revisado separadamente. Uma observação de endereço atual por si só não estabelece como essa dependência será mantida quando o serviço mudar de infraestrutura. Este manuscrito não resolveu ou mediu o nome do host e não fornece endereços IP observados.
O exemplo antigo do provedor inclui formulários de registro de recursos TXT e SPF dedicados. A publicação SPF atual usa TXT : RFC 7208 , seção 3.1 descontinua o tipo SPF RR dedicado. Corrija explicitamente essa instrução herdada, em vez de duplicar tipos de registro obsoletos para imitar o exemplo. A correção do protocolo não confirma, por si só, que o nome de host específico da implantação do provedor permanece apropriado para uma conta corrente; essa aplicabilidade permanece uma porta separada.
Preservar a política de autorização completa e o orçamento de avaliação
Um domínio existente pode autorizar correspondências de funcionários, avisos de sites e outras aplicações. Revise a autorização pretendida do eRecruiter dentro desse inventário completo, em vez de substituir a política por um exemplo de serviço único. RFC 7208 , seção 3.2 proíbe múltiplos Registros SPF que seria selecionado para o mesmo proprietário. Mantenha uma política coerente e documente o efeito de cada mudança proposta.
Um mecanismo a é um dos termos dependentes do DNS contados em RFC 7208 , seção 4.6.4. O limite relevante é baseado em termos avaliados, incluindo trabalho aninhado quando aplicável, e não simplesmente em uma contagem de pacotes de rede ou perdas de cache. Revise os caminhos de avaliação plausíveis em toda a política. Adicionar um mecanismo aparentemente pequeno ainda pode ser importante se o caminho existente já estiver próximo do limite.
Mantenha separados os erros de sintaxe, o orçamento de avaliação excessivo, os dados DNS ausentes e um resultado de remetente válido e não correspondente. Eles exigem remédios diferentes. Não remova arbitrariamente autorizações legítimas para fazer com que um verificador fique verde e não enfraqueça o qualificador de terminal como um substituto para identificar o remetente real. Uma aprovação SPF é um resultado de autorização para a identidade avaliada, não uma garantia de entrega ou um julgamento sobre o conteúdo da mensagem de um candidato.
Verifique a identidade do envelope e guarde a retenção do DKIM
RFC 7208 , seção 2.4 identifica CORREIO DE como uma identidade SPF . Compare o domínio do envelope real com o domínio onde a política proposta é publicada. O endereço visível do autor por si só não estabelece essa relação. Uma política pode ser sintaticamente válida e incluir o mecanismo pretendido, mas ser irrelevante para uma mensagem avaliada sob uma identidade de envelope diferente.
Um exercício de aceitação autorizado separadamente deve registrar a rota selecionada, enviando a identidade e o resultado do receptor confiável usando conteúdo de teste inofensivo no estilo de recrutamento. Não deve envolver currículo, agendamento de entrevista ou dados pessoais de um candidato real. Evite enviar mensagens para um verificador externo, a menos que a decisão de compartilhamento de dados seja autorizada. Nenhuma consulta DNS , mensagem de teste ou upload externo foi realizada para este guia.
RFC 9989 , seção 4.4 explica o adicional alinhamento relacionamento necessário para DMARC. Um resultado SPF aprovado para um domínio não relacionado não estabelece alinhamento com o autor visível. Este guia não possui evidências específicas do produto que estabeleçam a configuração DKIM da conta, portanto, não pode encerrar essa parte da aceitação da autenticação. Obtenha instruções atuais do provedor e evidências reais de mensagens permitidas antes de afirmar a prontidão completa do remetente.
Diagnóstico fictício e planilha de aceitação em branco
Uma equipe de recrutamento fictícia, Ash Grove Careers, copia uma autorização de provedor em sua política de domínio depois de ver o nome do aplicativo em uma mensagem. Posteriormente, seu administrador descobre que a rota configurada usa o serviço de correio da própria organização. O mecanismo adicionado não era, portanto, evidência da configuração real do remetente. A correção proposta é mapear a rota, revisar qual autorização é realmente necessária e obter uma amostra inofensiva do receptor antes de marcar o pedido como pronto. Nenhuma conta real, requerente ou observação DNS é representada por este exemplo.
- Ambiente e propriedade observada do servidor de e-mail: ______
- Evidência de rota e aplicabilidade atual do produto: ______
- Tenant SMTP-Host vazio e padrão legado SmtpHost em todo o sistema, com locais de console e confirmação atual: ______
- Domínio real do envelope e domínio visível do autor: ______
- Política TXT SPF completa e alteração justificada do mecanismo: ______
- Orçamento do prazo avaliado e revisão do estado de erro: ______
- Correção de registro SPF dedicado legado, se relevante: ______
- Evidência de receptor confiável de um teste inofensivo autorizado: ______
- Fluxo de trabalho DKIM não resolvido e evidências de autenticação mais amplas: ______
- Alterar proprietário, plano de reversão e decisão de liberação: ______
Evidências originais de implementação, revisão de assuntos humanos, aplicabilidade atual, rotas de produção, acessibilidade visual e liberação do proprietário permanecem em aberto. Este é um guia documental com escopo de rota SPF, não uma implementação completa de autenticação do eRecruiter. Nenhuma alteração de conta, DNS ou sistema de e-mail foi feita.