Os sistemas de RH podem enviar mensagens que parecem correspondência interna, mas originadas de plataformas de recrutamento, fornecedores de folha de pagamento e aplicativos de serviço de funcionários. A primeira tarefa é identificar a conta e o proprietário reais da organização para cada rota. Uma marca de fornecedor reconhecível não é evidência de que um determinado e-mail de candidato ou aviso de folha de pagamento tenha sido autorizado pelo empregador.
Divida a propriedade antes de mudar a política
Atribua notificações de recrutamento ao proprietário das operações de recrutamento, avisos de folha de pagamento ao proprietário do serviço de folha de pagamento e atualizações de funcionários ao proprietário das operações de pessoal. Registrar locatário do fornecedor, finalidade, identidade, domínio do envelope, DKIM assinatura de domínio e seletor, roteamento de resposta e contato de suporte aprovado. Se um provedor atende diversas subsidiárias, registre qual entidade legal e domínio cada conta deve usar, em vez de tratar o grupo como um remetente indiferenciado.
O inventário deve conter metadados operacionais, e não currículos de candidatos, detalhes salariais ou identificadores de funcionários. Armazene quaisquer evidências restritas necessárias sob controles apropriados de acesso e retenção. A depuração de autenticação não é uma permissão para copiar dados pessoais em um tíquete de solução de problemas de correio geral.
Entenda o que o resultado significa
RFC 9989 avalia o uso de domínio autenticado. Não prova que uma oferta seja válida, que um ajuste na folha de pagamento esteja correto ou que um recrutador esteja autorizado a assumir um compromisso. Mantenha as decisões de emprego e alterações de dados bancários sob seus próprios processos de verificação. Uma conta aprovada comprometida ainda pode enviar conteúdo enganoso autenticado.
Use resultados e cabeçalhos de sistemas de recebimento confiáveis para comparar a identidade De visível com a identidade autenticada. Não confie em uma captura de tela contendo o logotipo do fornecedor ou um cabeçalho não confiável inserido pelo remetente. Solicite ao fornecedor o procedimento atual de domínio personalizado específico da conta e retenha evidências de configuração sem expor credenciais.
Verifique o aviso do funcionário sem pedir emprestado comprovante da folha de pagamento
Suponha que os avisos de candidato e de folha de pagamento usem domínios de assinatura correspondentes aos seus respectivos domínios De, enquanto employees.hr.example aparece no De de um aviso de funcionário e provider.example.net é seu domínio DKIM d=. Mesmo supondo que a assinatura seja verificada, ela falha DKIM estrito alinhamento. Estas são identidades hipotéticas, não amostras assinadas ou verificações criptográficas reais. Um resultado da folha de pagamento não pode fechar uma incompatibilidade separada entre funcionário e aviso.
RFC 9989 Seções 4.4 e 5.3.5 exigir a consideração de outros caminhos alinhados relevantes para uma completa DMARC resultado. Para p=reject implantação, as Seções 7.4 e 8 exigem DKIM válido em vez de SPF sozinho. Separadamente, a resposta de um candidato pode chegar à fila de recrutamento errada, apesar de uma mensagem de saída ser transmitida. Verifique o destino da resposta aprovada com registros fictícios e contas controladas, e não com candidatos reais ou detalhes pessoais.
Teste as jornadas reais dos funcionários e candidatos
Use um candidato fictício aprovado e uma conta de funcionário em um ambiente de teste compatível. Acione uma confirmação de inscrição, uma notificação inofensiva da folha de pagamento e uma atualização do funcionário por meio de fluxos de trabalho reais de aplicativos. Confirme o recebimento controlado, a autenticação e o roteamento de resposta. Verifique se a resposta de um candidato chega à fila de recrutamento esperada sem expor os detalhes de outro candidato. Trate o acesso aos documentos e a correção do conteúdo como critérios de aceitação separados.
Se o fornecedor oferecer apenas a sua própria identidade De, o proprietário da empresa deverá decidir se um endereço suportado claramente apresentado atende às necessidades do fluxo de trabalho. Não forje a identidade do empregador por meio de uma configuração não suportada nem adicione regras de desvio amplas apenas para fazer um teste parecer bem-sucedido. Teste novamente as alterações suportadas e documente qualquer limitação restante.
Mantenha o offboarding conectado à governança do remetente
Revise as autorizações quando um contrato de agência terminar, um provedor de folha de pagamento mudar ou um administrador de RH sair. Confirme o fluxo de trabalho sucessor antes de retirar chaves ou dependências DNS . Preserve um proprietário de recuperação nomeado para mensagens urgentes de candidatos e de folha de pagamento. Marcar a rota como aceita somente quando o proprietário do serviço aprovar a evidência de teste atual; nem um registro DNS nem um passe de autenticação são uma certificação de emprego, privacidade ou conformidade regulatória.