A DMARC la politique doit refléter ce que fait un domaine et ce que l'organisation peut établir concernant son courrier. Un domaine de notification étroitement contrôlé, un domaine de correspondance du personnel et un domaine qui n'envoie rien peuvent nécessiter des décisions différentes.
Commencez par l'objectif du domaine et les itinéraires légitimes. Évaluez ensuite les conséquences de la politique demandée, les preuves disponibles pour la soutenir et les comportements du destinataire qui restent hors de votre contrôle.
Décrivez le domaine avant de choisir une politique
Références du protocole : RFC 5321 §5.1. Les listes de contrôle opérationnel et les décisions ci-dessous constituent des orientations éditoriales.
Enregistrez si le domaine envoie de la correspondance aux employés, des messages transactionnels, des campagnes ou aucun courrier autorisé. Incluez les sous-domaines, les systèmes acquis et les services achetés en dehors du service informatique central.
Un Enregistrement MX décrit un itinéraire de réception. Il n’inventore pas tous les systèmes pouvant utiliser le domaine dans From. De même, l'absence de boîtes aux lettres ne signifie pas qu'aucune application n'envoie de notifications.
Attribuez à chaque itinéraire matériel un objectif commercial et un propriétaire. Une source inconnue reste inconnue jusqu'à ce qu'une enquête soit menée. Un nom de fournisseur familier ou un grand réseau cloud ne constituent pas une preuve suffisante d’approbation.
Indiquez ce que signifie la politique demandée
Références du protocole : RFC 9989 §4.7, RFC 9989 §5.4. Les listes de contrôle opérationnel et les décisions ci-dessous constituent des orientations éditoriales.
La stratégie communique l'évaluation du propriétaire des messages qui échouent DMARC . Il ne configure pas l'authentification d'un expéditeur ni ne détermine l'action finale de chaque destinataire.
- Politique : aucune ; Contexte décisionnel : le propriétaire n'exprime aucune préférence de traitement en cas d'échec
- Politique : quarantaine ; Contexte décisionnel : une utilisation défaillante est considérée comme suspecte dans l'évaluation du propriétaire
- Politique : rejeter ; Contexte décisionnel : le propriétaire considère l'utilisation défaillante comme invalide
Un destinataire combine toujours l'authentification et la politique avec ses propres décisions de traitement. Une étiquette de tableau de bord ou une chaîne DNS publiée n'établit pas que chaque message ayant échoué a été rejeté ou que les messages transmis ont atteint la boîte de réception.
Avant un changement, séparez le choix politique de la réparation des expéditeurs défaillants légitimes. Mobile un enregistrement entre ces valeurs ne peut pas créer alignement pour une application utilisant une identité sans rapport.
Évaluer les itinéraires légitimes qui peuvent être perturbés
Références du protocole : RFC 9989 §7.4. Les listes de contrôle opérationnel et les décisions ci-dessous constituent des orientations éditoriales.
Testez les services critiques, y compris les événements à faible volume tels que la paie, les réinitialisations et les renouvellements de mots de passe. Utilisez les flux de travail d'application réels et inspectez les résultats reçus après les passerelles ou les intermédiaires.
La correspondance à usage général nécessite une attention particulière. Actuel RFC 9989 met en garde contre le rejet de tels domaines et explique les problèmes d'interopérabilité des listes de diffusion. Ses conseils pour les domaines dont les utilisateurs publient sur des listes incluent des considérations spécifiques d'observation, de comparaison et de politique des utilisateurs.
Lisez ces conseils pour le cas applicable. Ne le remplacez pas par une progression automatique sur sept ou trente jours appliquée à chaque domaine.
Comparez deux objectifs de domaine différents
Ceci est un exemple de planification synthétique.
Un domaine dédié aux reçus comporte une seule application approuvée, un DKIM configuration et aucune correspondance du personnel. Son opérateur peut tester des flux de travail de réception représentatifs, surveiller les échecs et définir un changement de portée.
Le domaine du personnel prend en charge les conversations, les adresses de rôle et les listes de diffusion Internet. Un test de courrier direct des employés ne couvre qu'une partie de cette activité. Son examen politique nécessite également des preuves sur les itinéraires indirects et l’impact sur les utilisateurs.
La différence n’est pas qu’une équipe accorde davantage d’importance à la sécurité. Les domaines ont des utilisations légitimes différentes et des conséquences différentes lorsqu'un destinataire agit en cas de défaillance.
Définir les preuves et les conditions de récupération
Préparez un dossier de décision contenant la portée du domaine, la politique prévue, les services légitimes testés, les itinéraires non résolus, les limitations de reporting pertinentes, l'approbateur et le plan de vérification.
Décidez de ce qui déclencherait une enquête ou le rétablissement de l’état précédemment approuvé. Conservez l’ancien enregistrement et l’historique des modifications à disposition. La restauration est une décision opérationnelle avec un propriétaire, et non une réaction improvisée au premier rapport inconnu.
Évitez un seuil de pourcentage qui masque la population. Un taux de réussite global élevé peut coexister avec un service critique complètement défaillant. Utilisez le procédure pas à pas du rapport agrégé pour conserver le dénominateur et le contexte d’attribution.
Enregistrez la raison et examinez-la lorsque le domaine change
Le résultat peut être un changement de politique, une correction de l'expéditeur, une observation plus approfondie, une séparation de domaine ou une décision de conserver la politique existante. Expliquez la raison et ses preuves.
Revoyez cette décision lorsqu'une nouvelle application, acquisition, passerelle ou utilisation professionnelle modifie la population de messagerie légitime. Le guide d'inventaire des expéditeurs fournit le dossier d'exploitation, tandis que quarantaine ou rejet examine de plus près le compromis en matière de manipulation.
Appliquer les preuves sans les exagérer
Pour le domaine des reçus fictifs, un paramètre DKIM maintenu à lui seul ne suffit pas : il faut exiger la preuve du message reçu d'une signature alignée et des autres contrôles de participation. Pour le domaine du personnel, conservez l’impact non résolu des listes de diffusion comme contrainte de décision explicite. Aucun des deux scénarios n’autorise un changement DNS ou ne revendique un test exécuté.