Un domaine peut ne comporter aucune boîte aux lettres d'employés et néanmoins envoyer des factures, des notifications de sites Web ou des messages de fournisseurs. Établir son utilisation réelle avant de le déclarer domaine non-expéditeur.
Une fois ces preuves disponibles, configurez les contrôles pour leurs objectifs distincts. SPF décrit l'envoi d'enveloppe autorisé, DMARC aborde l'utilisation alignée du domaine visible From, et un MX nul indique que le domaine n'accepte aucun courrier. Ce sont des décisions liées et non des dossiers interchangeables.
Vérifier l'utilisation légitime et dormante
Examinez les applications métier, les formulaires Web, les systèmes acquis, les campagnes externalisées et les notifications périodiques. Demandez si le domaine apparaît dans les adresses d'expéditeur visibles, les adresses de retour d'enveloppes, le traitement des réponses ou les destinations de reporting.
Vérifiez les sous-domaines séparément. Un domaine parent non expéditeur n'établit pas que chaque enfant a le même objectif, et un service expéditeur enfant peut avoir sa propre configuration.
Combinez les données observées avec la confirmation du propriétaire et les preuves de configuration. Une fenêtre de reporting discrète constitue un contexte utile mais ne peut pas prouver qu'un flux de travail annuel ou dormant n'existe pas.
Rendre explicite la déclaration d'envoi
Pour un domaine véritablement autorisé à n'envoyer aucun courrier, une politique SPF illustrative pour ce domaine est la suivante :
v=spf1 -allSous RFC 7208 §4.6.2 et RFC 7208 §5.1, cela ne donne aucune autorisation d'envoi pour l'identité SPF évaluée. Il ne s’agit pas d’une instruction visant à ajouter une deuxième politique SPF à côté d’une politique existante. Examinez et remplacez les autorisations obsolètes via une modification approuvée.
Contrôles SPF HELO et COURRIER DE identités telles que spécifiées dans RFC 7208 §2.3 et RFC 7208 §2.4. Cela n'empêche pas, à lui seul, un service indépendant de placer le domaine dans une adresse d'expéditeur visible. Considérez la politique DMARC applicable comme une partie distincte du plan.
Évaluer la politique DMARC pour ce domaine
Après avoir confirmé qu'il n'existe aucun flux légitime à partir du domaine que le changement pourrait perturber, un exemple de domaine non expéditeur sur _dmarc.example.com est :
v=DMARC1; p=rejectIl s'agit d'une politique illustrative dans le but déclaré, et non d'un modèle pour les domaines de correspondance du personnel. Confirmez le comportement de découverte et de sous-domaine applicable sous RFC 9989 §4.10.1 et RFC 9989 §4.7, et conservent la distinction d'interopérabilité à usage général.
Si des rapports sont demandés, utilisez une adresse de collecte qui reçoit réellement le courrier. On ne peut pas non plus supposer qu'un domaine configuré pour n'accepter aucun courrier reçoit sa propre boîte aux lettres de rapport. Sous RFC 9990 §4, une destination externe a besoin de l'autorisation de déclaration et des contrôles de recouvrement appropriés.
Décidez si le domaine n'accepte pas non plus de courrier
Un domaine non expéditeur peut toujours recevoir du courrier. Ne supprimez pas une route de réception légitime simplement parce qu’aucune utilisation sortante n’a été trouvée.
Lorsque la décision distincte est que le domaine n'accepte aucun courrier électronique, RFC 7505 §3 définit un MX nul. En notation DNS master-file, ses données d'échange sont :
0 .Ce doit être le seul Enregistrement MX pour ce domaine. Le dernier point représente l'échange nul, pas un nom d'hôte de serveur à inventer. Suivez le modèle de saisie de l'éditeur DNS et vérifiez la réponse publiée.
Sous RFC 7505 §4.2, les domaines NE DEVRAIENT PAS publier null MX lorsqu'ils sont utilisés dans des adresses SMTP MAIL FROM ou visibles From, car les destinataires peuvent rejeter leur courrier. Vérifiez ces utilisations avant de publier.
Travailler sur un exemple de service caché
Dans cet exemple synthétique, un domaine de marque parqué n'a pas de boîte aux lettres, mais une application de renouvellement externalisée l'utilise toujours dans From et attend des réponses sur le domaine.
La publication immédiate des contrôles de non-envoi pourrait perturber ce flux de travail. L'équipe identifie d'abord le propriétaire du service et décide s'il convient de migrer l'identité, de préserver une fonction de messagerie légitime ou de retirer l'application.
Ce n'est qu'alors qu'il peut prouver que l'ancien domaine n'a plus d'envoi autorisé et, le cas échéant, aucune exigence de réception. La preuve change la classification ; l’absence initiale de boîtes aux lettres n’a pas réglé le problème.
Vérifier l'état final et garder un propriétaire
Enregistrez les enregistrements précédents et la décision approuvée concernant l'objectif du domaine. Vérifiez indépendamment SPF faisant autorité, DMARC applicable et la configuration de réception. Enregistrez la portée des sous-domaines examinés et toutes les exceptions.
Continuez à vérifier les utilisations inattendues, les changements de propriété et les services nouvellement introduits. Une configuration pour un domaine inutilisé nécessite une personne chargée de remarquer quand il est utilisé.
Utiliser l'inventaire des expéditeurs établir des dépendances et sélection de politique pour les domaines avec une messagerie légitime active.
Enregistrer la décision et ses limites
Dans le scénario de renouvellement masqué, conservez à la fois la classification de non-envoi et la décision de non-réception jusqu'à ce que le propriétaire résolve l'identité From active et les réponses attendues. Après la migration, vérifiez l’itinéraire de remplacement avant de retirer l’ancien. Un MX nul ne publie pas de politique SPF ou DMARC ; une politique de rejet ne garantit pas que chaque destinataire rejette. Ces exemples n’autorisent aucun changement et ne prétendent aucune requête exécutée.