Un domaine ou un sous-domaine distinct peut faciliter l'exploitation d'un parc de messagerie lorsqu'il correspond à une réelle responsabilité commerciale. C'est moins utile lorsqu'il crée un autre nom non géré pendant que les mêmes applications inconnues continuent d'envoyer.
Commencez par ce que l'organisation doit séparer : la correspondance des employés, les notifications transactionnelles, les campagnes, l'administration de listes ou un domaine qui ne doit pas être envoyé. Choisissez ensuite les noms, les autorisations et les preuves qui rendent ces limites maintenables.
Écrivez le registre des objectifs avant de choisir les noms
Pour chaque identité proposée, enregistrez l'objectif commercial, le propriétaire, les comptes de service approuvés, les adresses d'expéditeur attendues, les chemins d'authentification et la nécessité de recevoir du courrier. Indiquez qui contrôle DNS et qui peut retirer l'identité.
Le registre suivant est synthétique. Les noms de domaine et les décisions d'exploitation sont indicatifs.
- Nom : example.com ; Objectif prévu et propriétaire : Correspondance des employés ; équipe de travail ; Décision d'envoi : itinéraires des employés approuvés et utilisation de la liste ; Décision de réception à vérifier : boîtes aux lettres du personnel et réponses opérationnelles
- Nom : receipts.example.com ; Objectif prévu et propriétaire : Reçus de transaction ; propriétaire de l'application ; Décision d'envoi : Demande de production et compte nommés ; Décision de réception à vérifier : si les réponses et le courrier opérationnel doivent arriver
- Nom : updates.example.com ; Objectif prévu et propriétaire : Campagnes clients ; propriétaire marketing ; Décision d'envoi : Comptes de campagne approuvés ; Décision de réception à vérifier : réponses, flux de travail de désinscription et routage du support
- Nom : retired.example.net ; Destination et propriétaire : Ancienne marque conservée ; propriétaires de marques et d’informatique ; Décision d'envoi : Pas d'envoi uniquement après examen des flux cachés ; Décision de réception à vérifier : dépendances de rétention et de récupération de réception évaluées séparément
Une partie locale « sans réponse » n'établit pas qu'un domaine n'a pas de fonction de réception. De même, l’absence de site Internet n’établit pas qu’un domaine n’envoie jamais. Inventoriez les dépendances réelles avant d’attribuer des enregistrements restrictifs.
Choisissez un sous-domaine lorsque la direction peut rester connectée
Un sous-domaine spécifique à un objectif peut faciliter le suivi de l'identité visible, de la propriété du service et de la configuration sous l'espace de noms établi. Par exemple, une application de reçus peut se voir attribuer son propre domaine De et une configuration de signature prise en charge.
Cette structure nécessite toujours que la relation entre les politiques parent et enfant soit vérifiée. Sous RFC 9989 §4.10.1, une politique directe au niveau du domaine d'auteur est pertinente pour la sélection de politique ; sinon, la découverte et les paramètres parents applicables peuvent avoir de l'importance. Utiliser vérification de la politique de sous-domaine plutôt que de supposer qu'un enregistrement enfant vide signifie qu'aucune politique ne s'applique.
Sous RFC 9989 §3.2.10.1 et RFC 9989 §4.10.2, détendu alignement peut connecter différents noms partageant le domaine organisationnel établi par l’algorithme de découverte applicable. Un sous-domaine ne constitue donc pas automatiquement une limite d'authentification stricte. Passez en revue le contrôle délégué, les paramètres d’alignement choisis et les identités que le service peut réellement utiliser. Alignement strict et détendu explique la distinction.
Choisissez un domaine distinct pour un espace de noms indépendant justifié
Un domaine enregistré distinct peut prendre en charge les besoins indépendants en matière de propriété, de marque ou de cycle de vie. Il crée également ses propres responsabilités en matière de renouvellement, DNS , de compte, de reporting et de récupération. Mettez ces responsabilités dans la décision opérationnelle, et non dans une future liste de nettoyage.
Le déplacement d'une application vers un autre domaine peut affecter ce que les destinataires reconnaissent, le routage des réponses et la configuration du service. Ne promettez pas qu'un nouveau nom améliore automatiquement la réputation, empêche toute usurpation d'identité ou est pris en charge par chaque fournisseur. Testez l’adresse d’expédition et l’itinéraire de livraison réellement prévus.
Un domaine distinct ne supprime pas la nécessité d'identifier les comptes approuvés ou de protéger l'accès administratif. Un compte d'envoi abandonné avec une authentification correcte reste un problème de propriété même si l'espace de noms semble parfaitement segmenté.
Configurer l'identité que le service enverra réellement
Pour chaque objectif sélectionné, utilisez les paramètres générés par le fournisseur pour le compte et l'itinéraire corrects. En utilisant RFC 9989 §4.4.1 et RFC 9989 §4.4.2, confirmer actif DKIM signature, l'identité évaluée par SPF et leurs relations avec le domaine visible From. La publication d’une nouvelle stratégie enfant n’oblige pas une application à continuer d’utiliser l’adresse De parent pour changer d’identité.
Envoyez un test autorisé à un représentant et conservez les résultats du récepteur de confiance. Vérifiez le comportement de réponse et d’échec ainsi que le message normal. Un échantillon marketing provenant d'une adresse de fournisseur par défaut ne démontre pas que l'identité de marque de production est prête.
Conservez l’ancienne identité à disposition pour enquête lors d’une transition approuvée lorsque les besoins de l’entreprise l’exigent. Enregistrez quels services ont été déplacés et lesquels dépendent toujours du nom précédent, plutôt que de déclarer la migration terminée après une modification DNS .
Décidez d’envoyer et de recevoir séparément
Un domaine qui ne devrait pas émettre de messages peut néanmoins avoir besoin de recevoir des réponses, des rapports, des mentions légales ou des courriers de récupération de compte. Traitez ces objectifs comme des décisions distinctes.
SPF, DKIM et DMARC concernent l'authentification et la politique d'envoi. Sous RFC 7505 §3, null MX déclare qu'un domaine n'accepte aucun courrier et ne doit pas être appliqué simplement parce que le courrier sortant a été retiré. RFC 7505 §4.2 met également en garde contre null MX sur les domaines utilisés dans COURRIER DE ou À partir des adresses. Passez en revue ces contraintes avant de l’utiliser sur une identité active.
Pour un domaine censé ne pas envoyer, utilisez l'évaluation du domaine non expéditeur et testez les applications cachées avant de restreindre l'autorisation. Une configuration restrictive qui désactive une route de récupération inconnue peut créer la prochaine panne.
Gardez la séparation utile après le déploiement
Regroupez les rapports et les incidents par identité d'entreprise et propriétaire, tout en conservant les domaines de messages réels. Une source inexpliquée sur l'identité d'une campagne devrait faire l'objet d'une enquête à cette fin, et non automatiquement un employé expéditeur approuvé.
Consultez le registre lorsque les fournisseurs, les marques ou la propriété des applications changent. Gardez l'accès au renouvellement et à la récupération à jour pour les domaines indépendants, ainsi que les preuves de délégation et de politique parent à jour pour les sous-domaines.
La séparation utile est celle qui facilite la vérification de la responsabilité et de l’authentification. Choisissez l'espace de noms qui correspond à l'objectif commercial, puis gérez les itinéraires approuvés, en envoyant la politique et en recevant les décisions derrière chaque nom.
Enregistrer la décision et ses limites
Pour receipts.example.com , conservez la production réelle, le domaine de signature, l'identité SPF évaluée et la stratégie découverte, puis testez la réponse et la gestion des échecs séparément. Conservez retired.example.net dans le registre jusqu'à ce que les dépendances d'envoi et les exigences de réception soient résolues. Le registre est fictif ; aucune migration d'identité, provisionnement de compte ou achat de domaine n'a été effectué.