Identifiez le produit Bullhorn et l'itinéraire du courrier
Bullhorn publie différentes instructions par courrier électronique pour différents produits. Ce guide utilise sa documentation ATS pour SPF et courrier de masse DKIM, et non le workflow de domaine Bullhorn Automation distinct. Le Article SPF couvre explicitement ATS et Back Office ; le Article DKIM décrit ATS et l'activation DKIM sur les courriers de masse. Ne présumez pas qu’une configuration couvre chaque produit de marque Bullhorn ou chaque intégration de messagerie.
Commencez par un inventaire de l'application, du compte, du domaine d'envoi et de la catégorie de message réels. Séparez le courrier de masse généré via l'itinéraire documenté des messages envoyés via une boîte aux lettres connectée ou un autre produit. Enregistrez qui possède le domaine et qui peut confirmer la configuration de l'application. Une équipe de recrutement peut utiliser plusieurs outils d'envoi sous une même marque, le nom du produit seul ne suffit donc pas à sélectionner les instructions DNS .
Les articles publics retenus ont été révisés le 9 novembre 2026, mais leur corps de texte ne fournit pas de date de révision fiable. Confirmer l’applicabilité du compte courant avant la mise en œuvre. Le site contient également un avis général sur d'éventuelles limitations de fonctionnalités ; ce manuscrit ne transforme pas cet avis en une affirmation selon laquelle un locataire particulier est affecté. Aucun état du compte ou incident de service actuel n’a fait l’objet d’une enquête ici.
Utilisez l'inclusion SPF documentée plutôt que les adresses IP devinées
Le guide SPF de Bullhorn spécifie include:_spf.bullhornmail.com plutôt que de fournir une liste d'adresses IP d'envoi fixe. Elle explique que cette approche évite aux clients d'avoir à mettre à jour les adresses individuelles à chaque fois que son infrastructure change. Utilisez cette dépendance documentée uniquement pour la route prise en charge prévue. Ne dérivez pas d’autorisation sortante d’une adresse de site Web, d’un échangeur de courrier entrant ou d’une liste tierce d’infrastructures historiques. Instructions SPF Bullhorn
Avant de modifier, conservez la politique complète existante et identifiez les autres expéditeurs légitimes. Le fournisseur distingue une politique TXT existante d'un domaine qui n'a pas de politique SPF . Son échantillon pour un enregistrement existant contient un espace réservé pour les autorisations précédentes. Cet espace réservé est un texte explicatif, pas quelque chose à publier littéralement. Fusionnez l'inclusion approuvée dans la politique réelle sans insérer un autre marqueur de version ni perdre les autres mécanismes requis.
L’échec logiciel de l’échantillon ne constitue pas une autorisation d’affaiblir une politique existante sans examen. Enregistrez si la modification proposée préserve le qualificatif de terminal actuel et ce qui arrive aux expéditeurs qui ne correspondent pas. Un ticket de modification doit expliquer l’ajout prévu, et pas simplement joindre un échantillon générique. Le propriétaire de la police de l'organisation demeure responsable de l'autorisation complète qui en résulte.
Évaluer la politique SPF complète et son identité
RFC 7208 , section 3.2 interdit plusieurs enregistrements qui entraîneraient la sélection de plusieurs stratégies SPF . Publier une deuxième politique parallèlement à la première n’est pas un moyen de préserver les expéditeurs existants. La section 3.3 autorise plusieurs chaînes de caractères au sein d'une seule. Enregistrement TXT, ce qui est un concept différent de plusieurs politiques concurrentes. L'inclusion compacte d'un fournisseur ne supprime pas toutes les contraintes possibles de taille d'enregistrement ou d'évaluation.
La section 4.6.4 limite les termes évalués dépendant du DNS, y compris l'évaluation imbriquée. Examinez le chemin complet qu'un récepteur peut suivre, et pas seulement le nombre d'inclusions visibles ou de paquets DNS . Une réponse mise en cache ne fait pas disparaître un terme évalué du budget du protocole. Séparez les erreurs de limite de recherche, les erreurs de syntaxe et un résultat valide ne correspondant pas, car ils nécessitent des actions correctives différentes.
SPF utilise les identités SMTP décrites par la spécification. RFC 7208 , section 2.4 explique COURRIER DE, y compris la gestion des chemins inverses vides. L'adresse affichée par l'éditeur ATS n'établit pas à elle seule l'identité utilisée pour l'évaluation SPF . Un examen autorisé ultérieur des messages doit comparer le domaine d'enveloppe réel avec le propriétaire chez lequel la stratégie a été publiée.
Préparer l'alias DKIM de messagerie de masse ATS
Le guide DKIM indique d'utiliser la configuration SPF de Bullhorn avant d'activer DKIM sur les courriers de masse. Il précise un CNAME sous bh. _domainkey sur le domaine du client, pointant vers bh._domainkey.bullhornmail.com . Conservez-le comme condition préalable et alias du fournisseur documenté, et non comme une clé TXT copiée à partir d’un produit non lié. Confirmez le propriétaire exact du domaine approuvé et l'itinéraire actuel du compte avant la publication. Instructions Bullhorn DKIM et DMARC
Les panneaux DNS diffèrent dans la manière dont ils ajoutent le suffixe de domaine. Un panel attend un parent bh. L'étiquette _domainkey peut créer un nom dupliqué incorrect si un nom d'hôte complet est saisi sans vérifier ses règles. À l’inverse, supprimer le domaine d’une interface qui nécessite un propriétaire complet peut publier un mauvais enregistrement. Enregistrez le propriétaire pleinement qualifié prévu et comparez-le avec le dossier public résultant via un processus autorisé.
Examinez les données existantes sur l’alias proposé avant de le remplacer. Le sélecteur Le nom peut déjà être utilisé par une configuration antérieure et une modification non coordonnée peut affecter le courrier actif. Conservez la cible CNAME exacte dans la modification approuvée plutôt que d'inventer une adresse IP ou d'aplatir l'alias. Aucune clé privée ne doit être obtenue auprès de Bullhorn pour cette étape documentée côté client.
Séparer l'activation du support de la publication DNS
Après avoir enregistré le CNAME , le guide demande au client de contacter le support Bullhorn et de demander l'activation DKIM pour les e-mails de masse. Bullhorn termine le processus côté fournisseur. Un enregistrement DNS représente donc une préparation à la signature, et non une preuve que le compte a commencé à signer. N'inventez pas de contrôle d'activation côté administrateur et ne fermez pas la tâche simplement parce que l'alias existe. Instructions pour le Bullhorn DKIM
Une proposition de transfert de support doit indiquer le compte, le domaine et la portée du courrier de masse, avec des références aux preuves de publication approuvées. Il n'a pas besoin de curriculum vitae des candidats, de correspondance client ou de secrets d'authentification. Aucun message de support n'a été envoyé pour ce manuscrit. Conservez la confirmation d'achèvement réelle lorsqu'un opérateur autorisé exécute le processus et gardez visibles toutes les restrictions de compte non résolues.
RFC 6376 , section 3.5 définit le domaine de signature et le sélecteur portés dans la signature du message. Un échantillon inoffensif autorisé séparément doit établir ces champs et le résultat de la vérification d'un destinataire fiable. L'alias correct ne peut pas à lui seul montrer qu'un message particulier a été signé par le domaine prévu ou qu'une route Bullhorn sans rapport utilise la même configuration.
Révisez DMARC sans remplacer aveuglément la politique organisationnelle
Offres du guide Bullhorn p=none quand non Enregistrement DMARC existe et indique qu'aucun changement de configuration supplémentaire n'est nécessaire lorsqu'il en existe déjà un. Considérez cela comme un guide de configuration du fournisseur et non comme une preuve que chaque politique existante est valide ou compatible avec le flux de messagerie prévu. Examinez la politique actuelle et l’inventaire des expéditeurs légitimes avant d’effectuer une modification à l’échelle du domaine. Ne remplacez pas une politique d’application efficace simplement pour correspondre à l’exemple.
RFC 9989 , section 4.4 explique alignement entre le domaine d'auteur visible et une identité d'authentification de passage. Un résultat SPF aligné avec succès ou un résultat DKIM aligné avec succès peut satisfaire la condition d'authentification. Cette règle de protocole ne dispense pas la condition préalable SPF documentée de Bullhorn pour son flux de travail DKIM de courrier électronique en masse. L'authentification ne garantit pas non plus l'acceptation, le placement dans la boîte de réception ou la sécurité d'un message de recrutement.
Diagnostic fictif et feuille de travail d'acceptation vierge
Une société de recrutement fictive, Juniper Talent, publie l'alias DKIM documenté mais ne demande jamais d'assistance pour permettre la signature de courriers électroniques en masse. Son équipe marque DNS comme étant complet et suppose à tort que tous les messages de chaque produit Bullhorn sont couverts. La révision proposée sépare la route de messagerie de masse ATS d'un autre produit d'automatisation, demande l'achèvement du fournisseur autorisé et laisse ouverte l'acceptation des messages reçus. Il s’agit d’un scénario fictif sans action réelle du locataire, sans ticket d’assistance ou résultat de requête.
- Produit, compte, catégorie de message et applicabilité actuelle : ______
- Domaine d'auteur prévu et identité réelle de l'enveloppe : ______
- SPF existant préservé et documenté comprend la révision : ______
- Syntaxe complète de la politique, chaînes de caractères et budget d'évaluation : ______
- Propriétaire DKIM CNAME exact, examen de la cible et des conflits : ______
- Portée de la demande d'assistance et confirmation de l'activation du fournisseur : ______
- Signature autorisée, preuve d'alignement et de réception : ______
- DMARC titulaire du contrat, exceptions restantes et décision de libération : ______
Les preuves originales de mise en œuvre, l'examen humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire restent ouverts. Aucune action de compte, DNS , support ou envoi n'a été effectuée.