Publier un Enregistrement DMARC modifie la politique et les informations de rapport que les récepteurs participants peuvent découvrir pour un domaine. Il ne configure pas SPF, ajouter DKIM signatures, inventorier les expéditeurs légitimes ou forcer chaque destinataire à prendre la même décision de livraison.
Traitez le changement DNS comme une étape dans un programme contrôlé. Le changement sûr dépend des preuves des véritables routes d'envoi du domaine.
Séparer la publication de la préparation
Références du protocole : RFC 9989 §4.5, RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.8. Les listes de contrôle opérationnel et les décisions ci-dessous constituent des orientations éditoriales.
Un enregistrement DMARC est publié sous un nom DNS _dmarc applicable. Sa politique peut en demander aucune, mettre en quarantaine ou refuser le traitement des messages qui échouent. DMARC évaluation. L'enregistrement peut également demander des rapports et définir d'autres paramètres actifs.
La publication n’aligne pas l’expéditeur. SPF alignement dépend de l’identité de l’enveloppe authentifiée et du domaine From. L’alignement DKIM dépend du domaine d= d’une signature transmise et du domaine From. Au moins un chemin aligné passant peut satisfaire un résultat au niveau du message. La pleine participation nécessite à la fois SPF et DKIM alignés sous RFC 9989 §8; les domaines rejetés NE DOIVENT PAS s'appuyer uniquement sur SPF et DOIVENT appliquer des signatures DKIM valides sous RFC 9989 §7.4.
Un record qui demande le rejet avant que les routes légitimes ne soient prêtes peut exposer ces routes à l'action du récepteur. Un enregistrement qui ne demande aucune gestion spécifique à une stratégie peut prendre en charge la surveillance, mais il n'est pas garanti que les rapports couvrent chaque message ou récepteur.
Créer une matrice de préparation expéditeur par expéditeur
Ce qui suit est un modèle de fonctionnement illustratif et non une affirmation concernant un environnement réel :
- Expéditeur : courrier d'entreprise ; Propriétaire de l'entreprise : Informatique sur le lieu de travail ; Depuis le domaine : example.com ; SPF aligné observé : Oui ; DKIM aligné observé : Oui ; Test représentatif : Courant ; État de préparation à l'application de la loi : preuves disponibles ; sous réserve d'un examen complet de l'état de préparation
- Expéditeur : Plateforme de facturation ; Propriétaire de l'entreprise : Systèmes financiers ; Depuis le domaine : billing.example.com ; SPF aligné observé : Non ; DKIM aligné observé : Oui ; Test représentatif : Courant ; État de préparation à l'application : chemin aligné au niveau du message observé ; un examen plus large des besoins de préparation
- Expéditeur : alertes héritées ; Propriétaire de l'entreprise : Infrastructure ; Depuis le domaine : example.com ; SPF aligné observé : Non ; DKIM aligné observé : Non ; Test représentatif : Courant ; État de préparation à l’application de la loi : pas prêt
- Expéditeur : enquête saisonnière ; Propriétaire d'entreprise : Marketing ; Depuis le domaine : news.example.com ; SPF aligné observé : Inconnu ; DKIM aligné observé : Inconnu ; Test représentatif : Manquant ; État de préparation à l'application de la loi : détenir et enquêter
"Oui" doit provenir d'une preuve de message reçu, et non d'une affirmation du panneau de contrôle. « Inconnu » n'est pas la même chose que « Non ». Cela signifie que le propriétaire du changement ne dispose pas de suffisamment de preuves pour prendre la décision d’exécution.
Enregistrer la différence de politique
Capturez le nom exact du propriétaire DNS , la valeur antérieure, la valeur proposée, les observations du résolveur, le changement de propriétaire et l'approbation. Une simple différence fictive pourrait être :
- Champ : Propriétaire ; Avant : _dmarc.example.com ; Proposé : _dmarc.example.com
- Champ : Politique ; Avant: p=none; Proposé : p=quarantine
- Champ : Rapports agrégés ; Avant : destination autorisée existante ; Proposé : Inchangé
- Champ : Politique de sous-domaine ; Avant : hérité de p ; Proposé : Explicitement révisé
- Champ : indicateur de test ; Avant : Non présent ; Proposé : Non présent
Il ne s’agit pas de promouvoir une politique ciblée spécifique. Il s’agit de rendre visible tout changement sémantique. Si l'enregistrement modifie également les destinations de reporting, les modes d'alignement, le traitement des sous-domaines ou un indicateur de test, examinez ces décisions séparément.
Comprendre ce que demande la politique
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.
Une politique est l'évaluation demandée par le propriétaire du domaine pour le courrier qui échoue DMARC . Les séquestres conservent leur pouvoir discrétionnaire et peuvent utiliser la politique locale, des preuves supplémentaires et des exceptions. Un publié p=reject value ne garantit donc pas que chaque message défaillant sera rejeté, et une valeur p=none ne garantit pas la livraison.
Le récepteur détermine également s'il met en œuvre les comportements de spécification et de reporting pertinents. Surveillez les résultats réels au lieu de convertir une chaîne DNS en une promesse universelle.
RFC 9989 inclut l'indicateur de test t actif. Lorsque t=y est appliqué, son effet défini est une réduction d'un niveau de l'évaluation p, sp ou np déclarée : le rejet est traité comme une quarantaine et la quarantaine comme aucune. Il ne s’agit pas d’un déploiement en pourcentage arbitraire et cela ne modifie pas l’évaluation déclarée nulle. La mise en œuvre du récepteur est toujours importante.
Sachez quelle publication ne corrige pas
La publication DMARC ne :
- fusionner plusieurs politiques SPF ;
- ajouter un Signature DKIM à une candidature ;
- modifier l'enveloppe ou le domaine de signature d'un service ;
- prouver que chaque source observée est légitime ;
- protéger les noms d'affichage sur des domaines non liés ;
- réparer les transformations de transfert ou de liste de diffusion ;
- garantir la livraison du rapport ;
- établir le placement dans la boîte de réception ;
- autoriser une transaction commerciale.
Chaque espace a besoin de son propre propriétaire. L'enregistrement DMARC décrit une politique de domaine ; il ne s'agit pas d'une commande d'orchestration pour chaque application émettrice.
Approuver l’exécution à partir de preuves représentatives
Un enregistrement d'approbation utile nomme les domaines concernés, la version de l'inventaire de l'expéditeur, la date de la preuve, les exceptions non résolues, la politique cible, les critères de restauration et l'approbateur responsable. Incluez les expéditeurs à faible volume, programmés et d’urgence. Une semaine sans défaillance observée n’est pas suffisante si les systèmes trimestriels ou annuels n’ont jamais été exercés.
Utilisez un message représentatif reçu de chaque itinéraire. Enregistrez le domaine From, l’identité de l’enveloppe, les valeurs DKIM d=, les résultats fiables et l’alignement. Rapports agrégés peuvent aider à identifier des modèles, mais ils ne remplacent pas la confirmation du propriétaire ou les tests au niveau du message.
Les flux de courrier indirect méritent une attention particulière. Le transfert et la modification des messages peuvent affecter différemment SPF et DKIM . Ne résolvez pas une exception de transfert connue en affaiblissant l'authentification d'un expéditeur non lié sans preuve.
Vérifier après le changement DNS
Après publication :
- Recherchez le nom exact du propriétaire via des résolveurs indépendants.
- Confirmez qu’un enregistrement de stratégie DMARC cohérent est détectable.
- Autorisez la mise en cache DNS avant d’interpréter des observations mitigées.
- Envoyez des tests contrôlés via des itinéraires représentatifs.
- Vérifiez les résultats du récepteur, pas seulement les journaux d'applications sortants.
- Comparez les échecs avec l’inventaire des expéditeurs approuvés.
- Surveillez les canaux d'assistance aux entreprises pour connaître les itinéraires retardés ou intermittents.
La fenêtre d’observation doit couvrir des cycles économiques significatifs. Définissez des conditions d’arrêt explicites plutôt que d’attendre un nombre arbitraire de jours.
Définir la restauration avant l'application
Références du protocole : RFC 9990 §4. Les listes de contrôle opérationnel et les décisions ci-dessous constituent des orientations éditoriales.
La restauration est une modification DNS contrôlée, pas une suppression sans analyse. Enregistrez la valeur antérieure et la condition qui justifie une réduction de politique. Une restauration peut réduire la politique pendant que l'expéditeur concerné est réparé, mais elle doit préserver les preuves et éviter d'introduire plusieurs enregistrements.
Si les destinations de reporting sont externes au domaine de stratégie, assurez-vous que toute autorisation requise existe. Un échec de reporting doit faire l’objet d’une enquête, mais l’absence de rapports à elle seule ne prouve pas que la politique n’est pas évaluée.
Traitez la publication comme une décision gouvernée
Le propriétaire DNS exécute la modification. Les opérations de messagerie valident l'authentification. Les propriétaires d'applications confirment les itinéraires légitimes. La sécurité accepte les risques résiduels d’usurpation d’identité et de livraison. Les propriétaires d’entreprise approuvent l’effet sur les communications critiques.
Cette séparation empêche une seule édition TXT d'assumer silencieusement la responsabilité des applications qu'elle ne peut pas configurer et des décisions de réception qu'elle ne peut pas contrôler.
Appliquer les preuves sans les exagérer
Dans la matrice de préparation fictive, conservez les itinéraires hérités et saisonniers pour enquête. L'observation DKIM alignée de Billing démontre un chemin possible au niveau du message, et non une participation complète ou l'approbation du propriétaire. Enregistrez les preuves manquantes avant de choisir la politique. Aucune des modifications ou envois DNS illustrés n’a été effectué.