Définir la route emBlue avant de changer DNS
Un emBlue Sender, une clé publiée et un message reçu sont trois éléments de preuve différents. Traitez-les séparément. Ce guide concerne l'interface de la campagne emBlue documentée dans son centre d'aide, et non tous les services portant une marque similaire ou chaque intégration connectée à un compte. Les instructions publiques retenues ont été revues le 9 novembre 2026 ; ils n'établissent pas les paramètres actuels, les droits d'abonnement ou les identités sortantes d'un locataire particulier.
Démarrez un enregistrement de modification avec le propriétaire du compte, destiné à l'adresse d'expédition, au flux de travail professionnel et à la boîte aux lettres de test de réception. Enregistrez qui contrôle DNS et qui peut approuver les modifications apportées à la politique à l’échelle du domaine. Un aperçu de campagne, un message déclenché par l'intégration et un e-mail de vérification peuvent suivre des chemins différents. Choisissez le flux de travail qui nécessite une authentification et conservez les autres itinéraires en dehors de la demande d'acceptation jusqu'à ce qu'ils soient inspectés séparément.
Séparer l'approbation de l'expéditeur de l'authentification du message
Le fonctionnaire Instructions de l'expéditeur décrivez Remitentes y dominios, Agregar remitente, les adresses d'envoi et de réponse de l'entreprise, un choix d'expéditeur par défaut et une étape de vérification des e-mails. Capturez l'expéditeur sélectionné sans supposer que son nom d'affichage, son adresse de réponse ou son badge de vérification établissent DMARC alignement. Un administrateur autorisé doit effectuer toute configuration réelle ; aucune n’a été réalisée pour ce guide.
La distinction du protocole est importante. SPF évalue normalement le SMTP COURRIER DE identité, tandis que DKIM identifie un domaine signataire via sa balise d=. DMARC associe un domaine authentifié de passage au domaine dans le champ visible De. Une destination de réponse sert un autre objectif. Sous RFC 9989 , article 4, un chemin SPF de passage aligné ou un chemin DKIM de passage aligné peut satisfaire l'authentification. Les deux ne sont pas universellement requis pour un pass DMARC .
Traitez la configuration publiée comme point de départ
Le Page de configuration d'emBlue nomme un SPF inclus, un rebond CNAME, un épexo sélecteur et un enregistrement de stratégie _domainkey hérité distinct. Il contient également un libellé qui associe l'alias de rebond à l'alignement DKIM . Il s'agit d'affirmations documentées et non de preuves d'identité émises par un compte courant. Obtenez la configuration prise en charge du compte avant de préparer une modification DNS exécutable.
Ne reproduisez pas sa clé publiée en tant que clé de locataire nouvellement émise. La vérification DKIM récupère une clé publique à l'aide du sélecteur de signature et du domaine de signature ; la clé de signature privée n’est pas quelque chose dont les destinataires ont besoin. L’ancien enregistrement de stratégie ne peut à lui seul fournir cette recherche de sélecteur. Appliquer RFC 6376 , sections 3.5 et 3.6 pour distinguer la signature et l'enregistrement de clé. Demandez au fournisseur de résoudre toute divergence entre sa page, le compte et la signature réelle.
Préparer un changement DNS limité
Inventoriez les enregistrements existants avant d’ajouter quoi que ce soit. Pour une proposition SPF , identifiez le domaine réellement autorisé, conservez d'autres expéditeurs légitimes et évaluez le coût d'évaluation de la politique combinée. La publication d'une deuxième stratégie SPF sous le même nom de propriétaire n'est pas une fusion sûre. La limite de termes de requête DNS dans RFC 7208 , section 4.6.4 s'applique pendant l'évaluation, y compris le traitement imbriqué pertinent ; compter les mots visibles et inclure à lui seul est inadéquat.
Gardez toute demande de domaine d'enveloppe distincte de DKIM . Un nom contenant « bounce » n'établit pas l'identité SMTP utilisée sur le fil, la propriété de sa politique SPF ou le mode d'alignement qui s'appliquera. Demandez ces faits dans le dossier de modification proposé. Laissez la fonctionnalité d’enveloppe personnalisée en suspens lorsque la documentation et les preuves du locataire ne l’établissent pas. N'inventez pas un enregistrement de secours pour donner à un tableau de bord un aspect complet.
Pour DMARC , conservez la stratégie de domaine existante à moins que son propriétaire n'approuve une révision spécifique après avoir pris en compte tous les expéditeurs. Ne remplacez pas l’application par un exemple de politique de surveillance pour s’adapter à une seule campagne. Les destinations des rapports nécessitent un destinataire responsable et une autorisation appropriée. Un exemple de configuration publique n’autorise pas la divulgation des données de rapport ni n’établit qu’une boîte aux lettres est surveillée.
Vérification de la conception autour des identités
Préparez un tableau de preuves vide avec le flux de travail, l'horodatage, le domaine d'origine, le domaine d'enveloppe observé par le récepteur, chaque paire DKIM d= et s=, les résultats d'authentification, la conclusion d'alignement et l'emplacement des preuves. Étiquetez chaque cellule non collectée « non observée ». Un message hypothétique de notices@orchard.example avec une signature de passage d' orchard.example illustre un chemin DKIM aligné ; il s'agit d'un cas pédagogique fictif, pas d'un test emBlue ou d'un comportement de compte promis.
Après une mise en œuvre approuvée, envoyez un message contrôlé via le workflow choisi vers une boîte aux lettres autorisée. Conservez ses en-têtes d’origine et identifiez le système récepteur qui a fourni l’évaluation d’authentification. Un expéditeur en amont peut insérer un Authentication-Results champ; comptez sur l'évaluation produite dans les limites de traitement approuvées du destinataire, et non sur le seul nom du champ. RFC 8601 , section 7.1 explique pourquoi la limite de confiance est importante. Expurgez les informations sur le destinataire dans les copies de révision sans détruire les preuves nécessaires pour comprendre l’itinéraire.
Si la vérification n'est pas d'accord avec un tableau de bord, isolez le désaccord : publication d'enregistrement, activation de signature, observation obsolète, mauvais expéditeur ou chemin d'application différent. La répétition d’un envoi groupé ne constitue pas un raccourci de diagnostic. Conservez la restauration proposée, y compris la configuration et les dépendances précédentes, mais évitez de supprimer un sélecteur alors que le courrier légitime en file d'attente peut encore avoir besoin de sa clé publique.
L'acceptation reste ouverte
Les exigences exactes du catalogue sont les suivantes : une preuve de configuration propriétaire emBlue actuelle et une table d'identité des messages reçus provenant du produit et de l'itinéraire exacts.
La partie documentaire est appuyée, avec des réserves importantes ; la table des messages reçus est absente. La propriété actuelle des clés, la prise en charge des enveloppes personnalisées et l’applicabilité des locataires restent également en suspens. Un examinateur technique doit rapprocher les instructions existantes avant qu'une procédure de production ne soit approuvée. Ce manuscrit ne certifie pas une configuration fonctionnelle ni ne garantit le placement dans la boîte de réception, et la publication nécessite toujours l'acceptation du propriétaire, de la source, du visuel et du site.