E-mails de recrutement : vérifier leur authentification

Pour vérifier l’authentification des e-mails de recrutement, envoyez un message destiné à un candidat fictif depuis chaque service utilisé. Examinez les résultats SPF, DKIM et DMARC dans la messagerie de réception, vérifiez l’alignement des domaines et la destination des réponses. Un envoi réussi ne prouve ni l’arrivée dans la boîte de réception, ni la lecture du message, ni la réponse du candidat.

La discussion sur Hacker News consacrée au guide d’authentification de Mailfully rappelle un problème de configuration bien connu. La messagerie du fondateur, l’ATS et l’outil de planification peuvent tous afficher le nom de l’entreprise tout en utilisant des infrastructures différentes. Le bon fonctionnement de l’un renseigne peu sur les autres.

Préparez une fiche de validation pour chaque circuit d’envoi. Vous pouvez la constituer sans remplacer des entrées DNS qui fonctionnent et sans attribuer à un indicateur de configuration vert une garantie qu’il ne fournit pas.

Quels services envoient des e-mails de recrutement depuis votre domaine ?

Recensez les services qui écrivent aux candidats avant de modifier le DNS. Chaque circuit d’envoi doit être testé, même si tous les messages semblent provenir de [email protected].

Commencez par la messagerie habituelle du recruteur ou du fondateur. Ajoutez ensuite l’ATS, qui envoie les accusés de réception des candidatures et les réponses aux candidats, l’outil de planification des invitations aux entretiens, puis tout service distinct utilisé pour les offres ou les évaluations. Notez qui administre chaque service et quel domaine il doit utiliser.

Cette distinction découle du fonctionnement de l’authentification des e-mails. Les normes évaluent l’infrastructure d’envoi et les identités de domaine, qui peuvent différer derrière une même adresse From visible. Cela justifie de tester chaque circuit, sans démontrer que tous les ATS rencontrent des problèmes de réception.

Précisez suffisamment l’inventaire pour repérer une hypothèse erronée :

Utilisez des informations de candidature fictives et des boîtes e-mail que votre équipe maîtrise. Vous pouvez vérifier si la réponse rejoint la bonne candidature sans contacter un vrai candidat ni transmettre sa conversation à un service de diagnostic.

Distinguez ce test technique de l’engagement humain. Notre plan de réponse aux candidatures reçues sur Hacker News explique qui examine les candidatures et quand les candidats reçoivent une réponse. L’authentification peut faciliter ce processus ; elle ne peut ni désigner un évaluateur ni le faire répondre.

Que vérifient réellement SPF, DKIM et DMARC ?

SPF autorise une infrastructure d’envoi pour une identité d’enveloppe. DKIM vérifie une signature associée à un domaine signataire. DMARC vérifie qu’un résultat positif s’aligne sur le domaine de l’adresse From visible par le destinataire.

Ces identités se confondent facilement, car l’application de messagerie n’affiche généralement qu’une adresse. Le message en contient pourtant plusieurs :

La spécification SPF distingue l’identité d’enveloppe de l’en-tête From visible. La spécification DKIM décrit la signature de domaine. Ni un nom d’expéditeur familier ni une adresse Reply-To appropriée ne démontrent l’alignement DMARC.

Prenez ce message direct fictif :

From: Hiring Team <[email protected]>
Envelope sender: [email protected]
DKIM signing domain: example.com

Le résultat SPF du prestataire pourrait être positif pour vendor.example.net sans s’aligner sur example.com. Une signature DKIM valide pour example.com peut néanmoins fournir le résultat positif aligné nécessaire à DMARC. DMARC n’exige pas que les deux mécanismes réussissent et s’alignent : au moins un mécanisme dont le résultat est positif et aligné peut satisfaire son test d’authentification. La RFC 9989 explique cette règle.

L’alignement dépend aussi d’un mode. Le mode souple peut accepter des domaines partageant un domaine organisationnel ; le mode strict exige une correspondance exacte. Un sous-domaine d’envoi ne constitue donc pas automatiquement un échec. Notez les domaines et la politique réellement utilisés au lieu de considérer toute différence comme une anomalie.

Cette vérification porte sur l’usage du domaine, pas sur la légitimité d’une offre d’emploi ni sur les intentions de l’expéditeur. Pour cette autre question, consultez notre article sur l’usurpation de l’identité des recruteurs et la confiance des candidats.

Comment ajouter un expéditeur sans perturber les e-mails existants ?

Obtenez les instructions actuelles du nouveau service pour votre domaine, puis confrontez-les aux entrées déjà publiées. Les valeurs DNS données en exemple servent à expliquer la configuration, pas à configurer votre domaine.

Déterminez d’abord si vous configurez l’authentification des envois, l’acheminement des messages entrants ou les deux. Une entrée MX dirige les messages entrants. Sa modification peut rediriger les réponses des salariés ou des candidats vers un autre service ; elle n’autorise pas les envois. Si le domaine principal reçoit déjà les e-mails des salariés ailleurs, un sous-domaine réservé au recrutement peut dissocier cette décision d’acheminement.

Pour SPF, conservez les expéditeurs existants et légitimes. L’ajout d’un ATS ne doit pas supprimer discrètement l’autorisation nécessaire à la messagerie des salariés. Publier une seconde politique SPF n’est pas non plus une solution sûre pour éviter de modifier la première : la sélection des entrées SPF produit une erreur permanente si elle trouve plusieurs entrées pouvant être sélectionnées.

SPF limite également les mécanismes et modificateurs évalués qui entraînent des recherches DNS. La limite est de dix termes de ce type, y compris ceux provenant d’inclusions imbriquées. Elle ne correspond pas au nombre de requêtes DNS effectuées par le résolveur. Si votre politique cumule les prestataires, examinez son évaluation plutôt que de compter les mots de l’entrée TXT. Les détails figurent dans les limites d’évaluation de la RFC 7208.

Pour DKIM, publiez le sélecteur et la clé ou la délégation fournis par le prestataire d’envoi. Une entrée pour le sélecteur de la messagerie des salariés ne configure pas automatiquement l’ATS. Notez quel service possède chaque sélecteur, afin que le retrait ultérieur d’un prestataire ne supprime pas la signature fonctionnelle d’un autre.

Pour DMARC, examinez la politique existante avant de la remplacer par l’exemple d’un tutoriel. Quelqu’un collecte peut-être déjà des rapports ou applique une politique plus stricte. Soumettez au responsable du domaine l’intégralité de la modification proposée, y compris les expéditeurs conservés et la destination prévue des rapports, avant de l’appliquer.

Comment tester le circuit réel des e-mails aux candidats ?

Envoyez le message depuis le véritable processus, examinez les résultats du destinataire, puis répondez. Un test effectué depuis la messagerie d’un administrateur ne sollicite pas la configuration d’envoi de l’ATS.

Pour chaque ligne de l’inventaire, créez un objet de test reconnaissable et utilisez une boîte e-mail que vous maîtrisez chez le fournisseur de messagerie à examiner. Dans l’ATS, utilisez une candidature fictive et la même action de réponse qu’un recruteur. Dans l’outil de planification, déclenchez le véritable processus d’invitation au lieu de reproduire manuellement son texte.

Ouvrez les en-têtes complets du message reçu ou la vue du message original. Notez le From visible, le domaine d’enveloppe affiché après réception et le domaine signataire DKIM. Repérez ensuite les résultats d’authentification ajoutés par le service de réception. Utilisez les résultats fiables de ce service ; une ligne insérée dans le message par un expéditeur précédent ne constitue pas une preuve équivalente.

La fiche de validation peut rester simple :

Indiquez la date, la configuration d’envoi, le fournisseur de messagerie destinataire et le responsable. Notez séparément si le test est arrivé dans la boîte de réception ou dans les indésirables. Conservez assez d’éléments pour examiner un échec, sans publier d’en-têtes privés ni de contenu de candidature dans un ticket public.

Enfin, cliquez sur Répondre et envoyez une courte réponse. Vérifiez qu’elle rejoint la boîte ou la conversation du candidat prévue et que le bon membre de l’équipe peut la consulter. Un outil de planification peut volontairement diriger les réponses ailleurs ; documentez ce comportement au lieu de supposer que toute invitation ramène à l’ATS.

Une ligne validée apporte une preuve utile pour ce message, ce circuit, cette configuration et ce destinataire. Répétez le test auprès d’un autre fournisseur de messagerie important si nécessaire. Les messages transférés et les listes de diffusion modifient le comportement de l’authentification. Examinez-les séparément avant de voir dans un échec SPF la preuve d’un expéditeur non autorisé.

Qu’exigent Gmail et Yahoo pour votre domaine d’envoi ?

Les deux fournisseurs publient des exigences pour les expéditeurs, avec des obligations supplémentaires pour les envois en masse. Déterminez le fournisseur destinataire, le volume d’envoi et la finalité du message concernés avant d’en tirer une liste de contrôle.

Les consignes de Google pour les expéditeurs s’appliquent aux messages envoyés aux comptes Gmail personnels. Tous les expéditeurs doivent utiliser SPF ou DKIM, disposer d’entrées DNS directes et inverses valides, utiliser TLS, respecter le format des messages et maintenir un faible taux de signalement comme indésirable. Les expéditeurs en masse doivent utiliser SPF, DKIM, DMARC et l’alignement, entre autres exigences publiées.

La FAQ de Google pour les expéditeurs décrit la classification des expéditeurs en masse autour de 5 000 messages par jour à destination des comptes Gmail personnels. Elle regroupe les sous-domaines sous le domaine principal et précise que cette classification persiste une fois attribuée. Comptez tous les envois concernés du domaine, pas seulement les messages quotidiens du recruteur. Ces règles visent les comptes Gmail personnels destinataires, pas les comptes Google Workspace destinataires.

Les exigences de Yahoo demandent également SPF ou DKIM à tous les expéditeurs, et les deux mécanismes ainsi qu’un résultat DMARC positif aux expéditeurs en masse. Yahoo accepte au minimum une politique p=none et l’alignement souple. Sa FAQ ne donne volontairement aucun seuil numérique pour les envois en masse : le chiffre de Google n’est donc pas une règle de Yahoo.

Rattachez les exigences de désabonnement à la catégorie du message. Google exempte les messages transactionnels de son exigence de désabonnement en un clic. Cela ne rend pas transactionnel tout message envoyé par un recruteur. Une réponse à un candidat et une lettre d’information promotionnelle de recrutement n’ont pas la même finalité. Examinez le message réel et les consignes du fournisseur.

Pour les messages concernés, Gmail exige le mécanisme POST décrit par la RFC 8058 ; un lien mailto seul ne suffit pas. Yahoo accepte actuellement mailto tout en recommandant POST, et exige un désabonnement facile pour les messages marketing ou sur abonnement envoyés en masse. Ne supposez pas que les règles de mise en œuvre sont identiques parce que les deux fournisseurs parlent de « désabonnement en un clic ».

Pourquoi un e-mail de recrutement authentifié peut-il arriver dans les indésirables ?

L’authentification est l’un des éléments du filtrage. Un destinataire peut accepter un message authentifié et le placer malgré tout dans les indésirables en fonction de la réputation, des signalements, du contenu ou des préférences du destinataire.

Les consignes de Gmail et celles de Yahoo couvrent ces autres facteurs. Aucune ne fait d’un résultat d’authentification positif une garantie d’arrivée dans la boîte de réception. Si le test réussit l’authentification mais arrive dans les indésirables, examinez ce résultat de filtrage au lieu de remplacer sans cesse des entrées DNS correctes.

Distinguez les échecs selon l’étape où ils surviennent :

Une autre limite précède toutes ces observations côté destinataire. Une soumission SMTP réussie signifie que le serveur qui accepte le message en prend la responsabilité à cette étape, comme le décrit la RFC 5321. La remise du message par l’application au serveur d’envoi précède son placement dans la boîte de réception du destinataire.

Distinguez quatre événements dans le vocabulaire de l’équipe : remise au serveur SMTP, placement constaté chez le destinataire, lecture et réponse. Un horodatage « envoyé » ne démontre pas les trois derniers. De même, l’absence de réponse ne permet pas de diagnostiquer un échec d’authentification ; elle peut tenir à la décision du candidat ou au message.

Que vérifier après un changement de prestataire ?

Répétez les lignes de validation concernées après tout changement d’expéditeur, de domaine, de configuration de signature ou d’intégration de planification. Examinez la politique DMARC et les rapports avec le responsable du domaine.

DMARC p=none n’exprime aucune préférence pour la mise en quarantaine ou le rejet des messages qui échouent. La collecte des rapports agrégés se configure séparément, avec une destination dédiée. Sa seule publication ne bloque pas l’usurpation d’identité. Pour exploiter les rapports, configurez une destination opérationnelle, désignez une personne chargée de les examiner et vérifiez toute autorisation nécessaire pour une destination externe. Les règles de production des rapports DMARC couvrent cette autorisation externe.

Avant d’adopter une politique de quarantaine ou de rejet, identifiez les expéditeurs légitimes et examinez leurs échecs. Vérifiez que la messagerie des salariés, les réponses de l’ATS, la planification et les autres services conservés fonctionnent avec l’alignement prévu. Décidez du changement de politique avec le responsable du domaine, puis examinez ses effets après application. La RFC 9989 définit les politiques, mais les destinataires restent libres de décider du traitement.

Faites également du retrait d’un prestataire une modification explicite. Identifiez l’autorisation SPF et le sélecteur DKIM de l’ancien service, conservez les autres et décidez où doivent arriver les réponses aux anciens messages. Un candidat peut répondre à une invitation envoyée avant la migration ; le nouveau test d’envoi ne prouve pas que cet ancien acheminement entrant subsiste.

Comment Kit gère votre domaine de recrutement et les réponses des candidats

Un domaine de recrutement hébergé exige à la fois une identité d’envoi configurée et des échanges avec les candidats qui fonctionnent dans les deux sens. Vérifiez le message reçu même lorsque la page de configuration indique une réussite.

La configuration de Startupkit Email dans Kit présente les entrées MX, DKIM, SPF et DMARC du domaine configuré. Kit génère une paire de clés DKIM propre au domaine et configure la signature sur son serveur de messagerie. La politique DMARC proposée commence par p=none.

Les messages aux candidats qui remplissent les conditions peuvent utiliser la boîte de recrutement configurée comme From visible et comme expéditeur d’enveloppe. L’envoi sous cette identité exige une intégration active, des clés de signature, des entrées d’envoi vérifiées et une activation explicite. Les vérifications DNS et l’état de mise en service sont distincts : « Actif » signifie que le service est mis en service, pas que toutes les entrées DNS se sont propagées.

Ces vérifications ont un périmètre précis. Kit recherche le contenu de clé attendu, son marqueur d’autorisation SPF et un marqueur de version DMARC. Il utilise un état de vérification en cache, actualisé par des vérifications DNS asynchrones. Ces vérifications ne constituent pas une évaluation complète de la politique SPF, un tableau de bord d’analyse des rapports DMARC ou une nouvelle recherche DNS à chaque message.

Kit consigne également les réponses aux candidats dans la conversation de recrutement. L’horodatage d’envoi réussi correspond à la remise du message par l’application au transport SMTP ; il ne prouve ni l’arrivée dans la boîte de réception du destinataire ni la lecture. Votre test de réception permet de vérifier ce qui se passe après cette remise.

Commencez par une réponse à un candidat fictif : envoyez-la depuis le circuit Kit configuré, examinez les résultats d’authentification reçus et répondez pour faire revenir le message dans la candidature. Complétez ensuite les lignes pour la messagerie des salariés et l’outil de planification. Si vous évaluez Kit pour le recrutement, incluez ce test dans votre essai et désignez un responsable chargé de tenir les résultats à jour.