Les systèmes RH peuvent envoyer des messages qui ressemblent à du courrier interne mais proviennent de plateformes de recrutement, de fournisseurs de paie et d'applications de services aux employés. La première tâche consiste à identifier le compte réel et le propriétaire de l'organisation pour chaque itinéraire. Une marque de fournisseur reconnaissable ne constitue pas une preuve qu'un e-mail ou un avis de paie particulier d'un candidat a été autorisé par l'employeur.
Diviser la propriété avant de changer de politique
Attribuez les notifications de recrutement au propriétaire des opérations de recrutement, les avis de paie au propriétaire du service de paie et les mises à jour des employés au propriétaire des opérations humaines. Enregistrer le locataire du fournisseur, le but, l'identité, le domaine de l'enveloppe, DKIM domaine de signature et sélecteur, routage des réponses et contact d'assistance approuvé. Si un fournisseur dessert plusieurs filiales, enregistrez l'entité juridique et le domaine que chaque compte est censé utiliser plutôt que de traiter le groupe comme un seul expéditeur indifférencié.
L'inventaire doit contenir des métadonnées opérationnelles, et non des CV de candidats, des détails sur les salaires ou des identifiants d'employés. Conservez toutes les preuves restreintes nécessaires sous des contrôles d’accès et de conservation appropriés. Le débogage de l'authentification n'autorise pas à copier les données du personnel dans un ticket de dépannage général par courrier.
Comprendre ce que signifie le résultat
RFC 9989 évalue l'utilisation du domaine authentifié. Il ne prouve pas qu'une offre est valable, qu'un ajustement de paie est correct ou qu'un recruteur est autorisé à s'engager. Conservez les décisions d'emploi et les modifications des coordonnées bancaires sous leurs propres processus de vérification. Un compte approuvé compromis peut toujours envoyer du contenu trompeur authentifié.
Utilisez les résultats et les en-têtes du système de réception approuvé pour comparer l’identité visible De avec l’identité authentifiée. Ne vous fiez pas à une capture d'écran contenant un logo de fournisseur ou un en-tête non fiable inséré par l'expéditeur. Demandez au fournisseur sa procédure de domaine personnalisé actuelle spécifique au compte et conservez les preuves de configuration sans exposer les informations d'identification.
Vérifiez l'avis du salarié sans emprunter de justificatif de paie
Supposons que les avis de candidat et de paie utilisent des domaines de signature correspondant à leurs domaines From respectifs, tandis que employees.hr.example apparaît dans le From d'un avis d'employé et provider.example.net est son domaine DKIM d=. Même en supposant que la signature soit vérifiée, elle échoue DKIM strict alignement. Il s’agit d’identités hypothétiques, et non de spécimens signés ou de véritables contrôles cryptographiques. Un résultat de paie ne peut pas combler une inadéquation distincte entre les avis des employés.
RFC 9989 sections 4.4 et 5.3.5 nécessitent de considérer les autres chemins alignés pertinents pour une DMARC résultat. Pour p=reject déploiement, les sections 7.4 et 8 exigent DKIM valide plutôt que SPF seul. Par ailleurs, une réponse d'un candidat peut atteindre la mauvaise file d'attente de recrutement malgré la transmission d'un message sortant. Vérifiez la destination de la réponse approuvée avec des enregistrements fictifs et des comptes contrôlés, et non avec de vrais candidats ou des détails sur le personnel.
Testez les parcours réels des employés et des candidats
Utilisez un compte de candidat et d'employé fictif approuvé dans un environnement de test pris en charge. Déclenchez un accusé de réception de candidature, une notification de paie inoffensive et une mise à jour des employés via leurs flux de travail de candidature réels. Confirmez la réception contrôlée, l’authentification et l’acheminement des réponses. Vérifiez qu'une réponse d'un candidat atteint la file d'attente de recrutement attendue sans exposer les détails d'un autre candidat. Traitez l’accès aux documents et l’exactitude du contenu comme des critères d’acceptation distincts.
Si le fournisseur propose uniquement sa propre identité De, le propriétaire de l'entreprise doit décider si une adresse prise en charge clairement présentée répond aux besoins du flux de travail. Ne falsifiez pas l'identité de l'employeur au moyen d'une configuration non prise en charge et n'ajoutez pas de règles de contournement générales juste pour donner l'impression qu'un test est réussi. Testez à nouveau les modifications prises en charge et documentez toute limitation restante.
Gardez l'offboarding connecté à la gouvernance des expéditeurs
Examinez les autorisations lorsqu'un contrat d'agence prend fin, qu'un prestataire de paie change ou qu'un administrateur RH quitte. Confirmez le workflow successeur avant de retirer les clés ou les dépendances DNS . Conservez un propriétaire de récupération nommé pour les messages de candidats et de paie urgents. Marquez l'itinéraire accepté uniquement lorsque le propriétaire du service approuve les preuves de test actuelles ; ni un enregistrement DNS ni un mot d'authentification ne constituent une certification en matière d'emploi, de confidentialité ou de conformité réglementaire.