Étendez l'identité de recrutement avant la configuration
Documents Zoho Recruit Configuration > Général > Paramètres de messagerie > Authentification par e-mail > Ajouter un domaine. L'adresse saisie reçoit un code de vérification, décrit comme valable 15 jours. Après vérification, Valider expose SPF et DKIM détails pour publication sous forme Enregistrements TXT. Authentification des e-mails de recrutement
La portée proposée doit identifier l'organisation de recrutement, le compte, l'édition, la région, le domaine de l'expéditeur prévu et les catégories de messages. Une agence de recrutement peut communiquer sous plusieurs marques légitimes, tandis qu'une équipe de recrutement interne peut utiliser un sous-domaine dédié. Aucun des deux arrangements ne justifie de supposer que chaque expéditeur configuré appartient au même propriétaire de domaine.
Identifiez la personne responsable de l’identité du candidat et l’administrateur responsable du DNS . Ne demandez pas l’accès aux dossiers des candidats simplement pour examiner la configuration de l’authentification. L'exigence de mise en œuvre du catalogue reste ouverte : ce manuscrit n'a pas accédé à un locataire Recruit, demandé un message de vérification ou inspecté une véritable communication de candidat.
Séparer la vérification de l'adresse de l'autorisation DNS
Le guide DNS demande aux administrateurs de copier les détails de l'enregistrement exposés par Validate. Il discute de la combinaison de l'autorisation SPF existante en une seule politique et met en garde contre les éditeurs DNS ajoutant le suffixe de domaine. Son SPF affiché et sélecteur les valeurs sont des exemples et non une preuve des paramètres actuels d'un compte particulier. Paramètres DNS de recrutement
Un code de vérification reçu confirme un point de contrôle dans le flux de travail de l'application, mais il ne s'agit pas de l'enregistrement de clé publique lui-même. Conservez le fait et l'heure de la vérification sans stocker le code dans un fichier de projet permanent. Conservez séparément la requête DNS générée et l'approbation du propriétaire du domaine pour l'appliquer.
Si un consultant en recrutement utilise le domaine d'un client, ne déduisez pas l'autorisation d'un nom d'entreprise familier ou d'un échange de courriers électroniques. Déterminez qui est autorisé à configurer ce domaine et quelle identité d'expéditeur le client a approuvée. Le transfert proposé devrait rendre explicite cette relation de propriété avant qu'une nouvelle dépendance d'envoi ne soit créée.
Consultez la politique SPF complète sans copier d’exemples
SPF identifie les chemins d'envoi autorisés pour ses identités SMTP spécifiées. Examinez l’identité réelle de l’enveloppe de l’itinéraire avant de décider à quoi appartient un changement de politique proposé. L'adresse visible du recruteur ne suffit pas à elle seule à déterminer le domaine évalué, et une valeur Zoho Mail mémorisée n'est pas une réponse universelle pour chaque application Zoho .
Au nom d'un propriétaire pertinent, plusieurs sélectionnés Enregistrements SPF provoquer une erreur. La fusion d'une politique existante nécessite donc une révision complète plutôt que l'ajout d'un deuxième enregistrement pour la nouvelle application. Préservez les autres expéditeurs légitimes, le classement des mécanismes et le comportement de terminaison. Examinez également les termes imbriqués dépendant du DNS par rapport à la limite d'évaluation ; une politique à court terme peut encore dépendre d’une chaîne plus longue.
Un examen des politiques n'est pas un enregistrement du résultat d'un message. Les preuves proposées doivent distinguer les instructions générées, la publication approuvée et l'évaluation réelle du destinataire. N'étiquetez pas un domaine authentifié simplement parce qu'un exemple de chaîne est syntaxiquement plausible. RFC 7208 , section 2.4; RFC 7208 , section 3.2; RFC 7208 , section 4.6.4
Vérifiez le nom du sélecteur et complétez les données clés
A Signature DKIM fournit un sélecteur et un domaine de signature, qui identifient ensemble la recherche de clé. Conservez le nom exact du propriétaire généré par le compte et sa valeur publique. Ne réutilisez pas l'exemple de sélecteur dans un article d'aide et ne remplacez pas une clé existante sans identifier ses dépendances actives.
Le comportement du suffixe de l'éditeur DNS est important. Certaines interfaces ajoutent automatiquement la zone, tandis que d'autres acceptent un nom complet. Comparez le nom de recherche final prévu avec la sémantique réelle de l'éditeur ; supprimer aveuglément le suffixe n’est pas plus sûr que de toujours l’inclure. En notation de fichier maître, @ autonome signifie l'origine actuelle, pas tous les sous-domaines.
Les données de clé TXT peuvent être représentées sous forme de plusieurs chaînes de caractères dans un seul enregistrement. Conservez la valeur logique complète et évitez de confondre cette représentation avec plusieurs enregistrements distincts. Aucune clé de signature privée n'est requise pour une révision de publication ordinaire. Traitez les demandes d’informations d’identification ou de clé privée comme une action différente sensible à la sécurité, et non comme une pièce jointe attendue à la feuille de calcul DNS . RFC 6376 , section 3.5; RFC 6376 , section 3.6.2.2; RFC 1035 , section 5.1; RFC 1035 , section 3.3.14
Appliquer la sémantique DMARC plutôt que le raccourci général du produit
DMARC évalue la relation entre le domaine de l'auteur et une identité d'authentification de passage. Un chemin SPF aligné de passage ou un chemin DKIM aligné de passage peut satisfaire à l'exigence d'authentification ; la réussite des deux mécanismes n'est pas une exigence universelle. De plus, une signature DKIM ne constitue pas un cryptage de message et n'établit pas la confidentialité de la candidature d'un candidat.
L'examen des messages reçus proposé enregistre le domaine d'origine visible, le domaine de signature, le sélecteur, l'identité de l'enveloppe pertinente et les résultats du destinataire de confiance. Confirmez l'itinéraire et l'heure du prélèvement afin que les preuves provenant d'un autre compte, d'une autre marque ou d'un autre moyen de transport ne puissent pas être remplacées accidentellement. Un point de contrôle de configuration de domaine réussi reste distinct de ces observations de messages.
L'authentification n'établit pas qu'une offre d'emploi est authentique, qu'un recruteur est autorisé à demander un paiement ou qu'un destinataire doit divulguer des pièces d'identité. Ces décisions commerciales nécessitent une vérification distincte. Évitez de transformer une déclaration d’acceptation technique en une garantie quant à la légitimité du recrutement ou à la conformité légale. RFC 9989 , section 4.4; RFC 6376 , article 1
Feuille de travail d'acceptation pour les opérations de recrutement
Utilisez cette feuille de travail originale proposée pour préserver la propriété du domaine et la confidentialité des candidats tout au long du projet.
- Portée de l'organisation : compte de recrutement, édition, région, marque et catégories de messages incluses dans l'acceptation.
- Propriété de l'expéditeur : domaine d'auteur prévu, équipe de recrutement responsable et toute limite d'autorisation du domaine client.
- Point de contrôle de vérification : preuve d'achèvement et horodatage sans enregistrer le code à usage unique.
- Enregistrements générés : noms exacts, types et valeurs publiques liés au compte qui les a émis.
- Dépendances existantes : stratégie SPF affectée, sélecteurs déjà utilisés et propriétaire du changement approuvé.
- Acceptation du message : itinéraire représentatif, preuves d'en-tête minimisées, résultats fiables et alignement interprétation.
- Contrôles de confidentialité : évitez les pièces jointes des candidats, les réponses aux candidatures et les identifiants personnels inutiles dans le matériel de diagnostic.
- Décision de libération : réviseur nommé, questions de compte courant non résolues et plan de continuité des communications de recrutement programmées.
Cette feuille de travail ne constitue pas un audit terminé. Aucune donnée sur les candidats n'a été collectée, aucun enregistrement DNS n'a été interrogé ou modifié et aucun message de recrutement n'a été envoyé pour ce manuscrit.
Diagnostic fictif : un échantillon d'une autre marque de recrutement
Une entreprise de recrutement fictive authentifie un domaine pour sa marque principale et introduit ensuite une adresse de recrutement spécifique au client. Lors de l'examen, un administrateur présente un message de la marque principale comme preuve que l'itinéraire destiné au client est prêt. Les deux messages ont des domaines d'auteur et des relations de propriété différents, la conclusion n'est donc pas étayée.
La correction proposée commence par l'inventaire des expéditeurs approuvés et la configuration exacte générée par le compte. L'équipe demande des preuves appropriées pour le parcours client sans copier les candidatures ni transmettre de pièces jointes confidentielles. Il vérifie également si le propriétaire du domaine a approuvé la relation d'envoi proposée.
Le rapport final indique quel itinéraire comporte des preuves et lequel reste non vérifié. Cela ne permet pas de déduire une usurpation d’identité ou une défaillance du prestataire à partir des seules preuves manquantes. Ce scénario est fictif et ne décrit pas un véritable compte Recruit, un test de message exécuté ou un incident vérifié.