Mapper les comptes sur le domaine d'envoi
L'authentification Emma combine DNS au niveau du domaine avec une étape de vérification spécifique au compte. Commencez par répertorier chaque compte ou sous-compte qui enverra à partir du domaine, son propriétaire et l'e-mail de l'expéditeur par défaut prévu. Le même domaine apparaissant dans deux comptes de campagne ne rend pas leurs tokens de vérification interchangeables.
Le fournisseur Guide de configuration DKIM demande aux utilisateurs de faire en sorte que l'adresse e-mail de l'expéditeur par défaut corresponde au domaine en cours d'authentification. Confirmez ce paramètre avant que DNS ne fonctionne. Sinon, l'administrateur peut configurer un domaine avec succès tandis que le propriétaire de la campagne continue d'envoyer avec une autre identité.
Publier les enregistrements de domaine et la preuve de compte
Emma documente trois DKIM CNAME enregistrements, en utilisant les sélecteurs e2ma-k1, e2ma-k2 et e2ma-k3 sous _domainkey et les cibles correspondantes sous dkim.e2ma.net . Récupérez les valeurs actuelles des instructions du fournisseur lors de la mise en œuvre et utilisez la syntaxe de nom de propriétaire correcte de l'hôte DNS . Ce guide ne fournit pas de configuration de compte privé et n'affirme pas que les enregistrements existants ont été testés.
Le flux de travail nécessite également une valeur TXT commençant par e2ma-verification= par le propre hachage de validation du compte. Recherchez ce hachage dans Compte > Délivrabilité pour le contexte de compte correct. Emma déclare que chaque compte ou sous-compte possède un hachage unique et que les comptes à plusieurs niveaux nécessitent des enregistrements de vérification TXT distincts pour les sous-comptes concernés. Ne remplacez pas l'enregistrement de vérification d'un autre compte actif simplement parce qu'il partage le domaine.
Contrairement à SPF, lorsque plusieurs stratégies candidates chez un propriétaire provoquent une erreur, des valeurs TXT de vérification de domaine sans rapport peuvent coexister. Gardez le but de chacun Enregistrement TXT explicite afin qu'une opération de nettoyage ne supprime pas la preuve nécessaire à un autre compte de campagne. Ne déduisez jamais qu'une valeur TXT commençant par le jeton d'un autre service est obsolète Enregistrement SPF.
Vérifiez les noms sans endommager les sélecteurs existants
Avant la publication, inspectez le service DNS faisant autorité et les propriétaires d’enregistrements existants. Une connexion au bureau d'enregistrement peut ne pas contrôler la zone en direct. A chaque sélecteur, comparez le type d'enregistrement existant et sa destination avec la modification approuvée. Un CNAME ne peut pas être combiné avec des données concurrentes ordinaires chez ce même propriétaire, donc résolvez une collision plutôt que de forcer deux fournisseurs à utiliser un seul nom de sélecteur.
Après l'enregistrement, vérifiez le propriétaire public complet et la cible. Les éditeurs d'étiquettes relatives et les formats d'entrée pleinement qualifiés diffèrent ; un suffixe de domaine dupliqué peut rendre inutile un enregistrement visuellement plausible. Complétez la validation finale d'Emma dans le bon compte et conservez le statut de chaque sous-compte séparément. La source décrit le flux de travail, mais elle n'établit pas que votre propre DNS ou compte l'a transmis.
Exercer l'identité réelle de la campagne
Feuille de travail de vérification originale : une ligne par compte/sous-compte, avec le domaine de l'expéditeur par défaut, le propriétaire du jeton, les réponses du sélecteur, le statut de validation final et la preuve de message contrôlé. Envoyez une campagne inoffensive vers une boîte aux lettres contrôlée via chaque chemin de compte sensiblement différent. Évitez les adresses des clients et les audiences de production pendant les tests.
Capturez le résultat DKIM du destinataire, le domaine de signature et le sélecteur à côté du domaine From visible et expéditeur d'enveloppe. Une signature valide prouve la vérification sous son domaine de signature ; DMARC nécessite en outre alignement avec From pour ce chemin d’authentification. Le jeton de propriété TXT n'est pas la clé utilisée pour vérifier la signature du message, et sa vérification à elle seule ne peut pas garantir l'alignement.
Scénario illustratif : un compte parent est validé avec succès, tandis qu'un sous-compte a toujours le hachage du parent saisi comme sa propre preuve de vérification. La prochaine étape correcte consiste à récupérer la valeur distincte du sous-compte et à valider ce compte, et non à régénérer les trois CNAME de domaine sans preuve d'un défaut DNS .
Conserver un inventaire de compte récupérable
Enregistrez les paramètres et les enregistrements avant modification. Si la validation échoue, suspendez la campagne concernée et identifiez si l'expéditeur par défaut, le jeton de compte ou le sélecteur public est erroné. Restaurez uniquement la configuration affectée après avoir vérifié les dépendances. Conservez intacts les jetons et sélecteurs valides des autres comptes.
Revérifiez lors de l'ajout d'un sous-compte, de la modification de l'expéditeur par défaut ou de la migration DNS . La documentation a été examinée le 8 novembre 2026. La feuille de travail et le scénario sont des exemples originaux ; aucun compte Emma, dossier public ou campagne diffusée n'a été testé ici.
Utiliser un grand livre d'achèvement à deux comptes
Le cas écrit EM-01 suppose que Parent et Events ont tous deux l'intention de From news@example.com . Le parent possède son propre jeton de vérification et a effectué la validation finale. Les événements font référence par erreur au jeton du parent ; son propre jeton et sa validation finale restent manquants. Les trois CNAME de domaine sont stipulés corrects dans cet exemple, non interrogés. Conservez le jeton fonctionnel du parent, récupérez la valeur spécifique au compte des événements et terminez la validation dans les événements. Ne régénérez pas les sélecteurs partagés pour réparer une preuve de compte manquante. L'authentification des messages pour les événements reste inconnue jusqu'à ce qu'une campagne contrôlée soit inspectée. Aucun token n'a été collecté ou publié et aucune campagne n'a été envoyée.
Le guide actuel du fournisseur limite chaque compte ou sous-compte à un domaine authentifié. Si Events a plutôt besoin news@other.example , enregistrez ce choix d'identité et de compte distinct avant de remplacer une configuration fonctionnelle. Le succès du domaine d'un compte parent ne supprime pas cette limite de produit.
Préserver la limite d’application
RFC 9989 La section 7.4 nécessite DKIM valide, et non SPF seul, pour la publication de domaines. p=reject, et met en garde contre l'interopérabilité du courrier indirect et des listes de diffusion. Un seul test réussi de message direct ne prouve pas que chaque voie légitime est prête à faire l’objet d’une politique plus forte. Conserver la protection approuvée existante tout en diagnostiquant l’écart réel ; tout changement de politique nécessite sa propre décision.