Les enregistrements DMARC (Domain-based Message Authentication, Reporting and Conformance) servent de politiques basées sur DNS qui indiquent aux serveurs de messagerie destinataires comment traiter les e-mails provenant de votre domaine. Comprendre la syntaxe précise des enregistrements DMARC est crucial pour les organisations mettant en œuvre des protocoles d’authentification e-mail robustes en 2026.

Un enregistrement DMARC se compose de paires balise-valeur séparées par des points-virgules, publié comme enregistrement TXT à l’emplacement DNS spécifique _dmarc.votredomaine.com. Chaque composant remplit une fonction distincte dans la chaîne d’authentification, de l’application des politiques à la configuration des rapports forensiques.

I. Vue d’ensemble de la structure des enregistrements DNS DMARC

Processus en cinq étapes pour créer des enregistrements DMARC, de la balise de version à la publication DNS.

Format de syntaxe de base

Les enregistrements DMARC suivent un format standardisé balise=valeur avec des exigences d’ordre spécifiques :

v=DMARC1; p=politique; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=politique_sous_domaine; pct=pourcentage; adkim=alignement; aspf=alignement; rf=format; ri=intervalle; fo=options

Balises obligatoires vs optionnelles

Balises obligatoires :

  • v (version)
  • p (politique)

Balises optionnelles :

  • rua (rapports agrégés)
  • ruf (rapports forensiques)
  • sp (politique sous-domaine)
  • pct (pourcentage)
  • adkim (alignement DKIM)
  • aspf (alignement SPF)
  • rf (format de rapport)
  • ri (intervalle de rapport)
  • fo (options d’échec)

II. Balise de version (v)

Syntaxe

v=DMARC1

La balise de version doit toujours être le premier composant de tout enregistrement DMARC et ne prend actuellement en charge qu’une seule valeur : DMARC1. Cela identifie l’enregistrement comme une politique DMARC pour les serveurs de messagerie destinataires.

Exemples

v=DMARC1; p=none
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Cas particuliers

  • L’absence de balise de version rend l’ensemble de l’enregistrement invalide
  • La balise de version apparaissant ailleurs qu’en première position provoque des échecs d’analyse
  • Toute valeur autre que DMARC1 entraîne le rejet de l’enregistrement

III. Balise de politique (p)

Syntaxe

p=none|quarantine|reject

La balise de politique définit comment les serveurs destinataires doivent traiter les e-mails qui échouent aux vérifications d’authentification DMARC.

Valeurs de politique expliquées

none : Mode surveillance – aucune action prise sur les messages échoués

v=DMARC1; p=none; rua=mailto:[email protected]

quarantine : Messages échoués livrés dans les dossiers spam/courrier indésirable

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

reject : Messages échoués entièrement bloqués au niveau SMTP

v=DMARC1; p=reject; rua=mailto:[email protected]

Cas particuliers

  • L’application de la politique dépend de l’implémentation du destinataire
  • Certains destinataires peuvent traiter la quarantaine comme un rejet pour des raisons de réputation
  • L’escalade de politique devrait suivre des modèles de déploiement graduel (none → quarantine → reject)

IV. URI des rapports agrégés (rua)

Syntaxe

rua=mailto:[email protected],mailto:[email protected]

Spécifie les adresses e-mail pour recevoir les rapports agrégés XML contenant les statistiques d’authentification.

Exemples de configuration

Destinataire unique :

rua=mailto:[email protected]

Destinataires multiples :

rua=mailto:[email protected],mailto:[email protected]

Rapport de domaine externe :

rua=mailto:[email protected]

Cas particuliers

  • Les destinataires de domaine externe nécessitent des enregistrements d’autorisation DNS
  • Rapports générés quotidiennement par la plupart des destinataires (cycles de 24 heures)
  • L’absence de balise rua élimine la visibilité sur les performances DMARC
  • Certains destinataires imposent des limites de taille sur les destinations de rapport

V. URI des rapports forensiques (ruf)

Syntaxe

ruf=mailto:[email protected]

Définit les destinataires pour les rapports forensiques détaillés d’échecs d’authentification individuels.

Exemples

ruf=mailto:[email protected]
v=DMARC1; p=quarantine; ruf=mailto:[email protected],mailto:[email protected]

Cas particuliers

  • De nombreux destinataires n’envoient plus de rapports forensiques pour des raisons de confidentialité
  • Les rapports forensiques contiennent des en-têtes de message complets et des données potentiellement sensibles
  • Les destinataires de domaine externe nécessitent une autorisation DNS explicite
  • Le volume peut être accablant pour les domaines avec un trafic e-mail élevé

VI. Politique de sous-domaine (sp)

Syntaxe

sp=none|quarantine|reject

Établit l’héritage de politique pour les sous-domaines lorsqu’aucun enregistrement DMARC explicite n’existe au niveau du sous-domaine.

Exemples de configuration

Politique de sous-domaine plus stricte :

v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]

Politiques correspondantes :

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Cas particuliers

  • Les enregistrements DMARC spécifiques au sous-domaine remplacent les paramètres sp
  • Le comportement par défaut applique la politique du domaine parent aux sous-domaines lorsque sp est absent
  • Les sous-domaines organisationnels peuvent nécessiter différentes approches de politique

VII. Balise de pourcentage (pct)

Déploiement DMARC en trois phases, de la surveillance à l’application complète avec des tests par pourcentage.

Syntaxe

pct=1-100

Contrôle le pourcentage de messages échoués soumis à l’application de la politique DMARC.

Exemples

Déploiement graduel :

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

Application complète (par défaut) :

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

Cas particuliers

  • La valeur par défaut est 100 lorsque la balise pct est omise
  • Utile pour le déploiement et les tests de politique graduelle
  • L’échantillonnage aléatoire peut créer des expériences utilisateur incohérentes
  • Tous les destinataires n’honorent pas les spécifications de pourcentage

VIII. Mode d’alignement DKIM (adkim)

Syntaxe

adkim=r|s

Définit les exigences d’alignement entre le domaine de signature DKIM et le domaine d’en-tête From.

Modes d’alignement

Relaxed (r) – Par défaut :

v=DMARC1; p=quarantine; adkim=r; rua=mailto:[email protected]
  • Permet l’alignement de domaine organisationnel (sousdomaine.exemple.com s’aligne avec exemple.com)

Strict (s) :

v=DMARC1; p=quarantine; adkim=s; rua=mailto:[email protected]
  • Nécessite une correspondance exacte du domaine

Cas particuliers

  • L’alignement relaxed accommode les services e-mail légitimes de sous-domaine
  • L’alignement strict empêche l’usurpation de sous-domaine mais peut rompre les flux e-mail légitimes
  • Plusieurs signatures DKIM évaluées indépendamment pour l’alignement

IX. Mode d’alignement SPF (aspf)

Syntaxe

aspf=r|s

Spécifie les exigences d’alignement entre le domaine Return-Path SPF et le domaine d’en-tête From.

Exemples

Alignement SPF relaxed :

v=DMARC1; p=none; aspf=r; adkim=s; rua=mailto:[email protected]

Alignement SPF strict :

v=DMARC1; p=quarantine; aspf=s; rua=mailto:[email protected]

Cas particuliers

  • Les scénarios de transfert cassent souvent l’alignement SPF indépendamment du mode
  • Les services e-mail tiers nécessitent une configuration Return-Path soigneuse
  • Le mode relaxed accommode les structures de domaine organisationnel

X. Format de rapport (rf)

Syntaxe

rf=afrf|iodef

Spécifie la préférence de format pour les rapports forensiques.

Options de format

Authentication Failure Report Format (afrf) – Par défaut :

v=DMARC1; p=none; rf=afrf; ruf=mailto:[email protected]

Incident Object Description Exchange Format (iodef) :

v=DMARC1; p=none; rf=iodef; ruf=mailto:[email protected]

Cas particuliers

  • La plupart des destinataires utilisent par défaut afrf indépendamment de la spécification rf
  • Le format iodef est rarement implémenté en pratique
  • La préférence de format peut être ignorée par les systèmes de rapport

XI. Intervalle de rapport (ri)

Syntaxe

ri=secondes

Demande un intervalle spécifique pour la génération de rapports agrégés.

Exemples

Rapports quotidiens (86400 secondes) :

v=DMARC1; p=none; ri=86400; rua=mailto:[email protected]

Rapports hebdomadaires (604800 secondes) :

v=DMARC1; p=none; ri=604800; rua=mailto:[email protected]

Cas particuliers

  • La plupart des destinataires génèrent des rapports selon leurs propres horaires indépendamment de la valeur ri
  • La pratique standard est la génération quotidienne de rapports
  • Les intervalles plus courts sont rarement honorés par les principaux fournisseurs d’e-mail

XII. Options d’échec (fo)

Syntaxe

fo=0|1|d|s

Contrôle les conditions déclenchant la génération de rapports forensiques.

Options d’échec expliquées

fo=0 (Par défaut) : Rapports générés lorsque SPF et DKIM échouent tous les deux

v=DMARC1; p=none; fo=0; ruf=mailto:[email protected]

fo=1 : Rapports générés lorsque SPF ou DKIM échoue

v=DMARC1; p=none; fo=1; ruf=mailto:[email protected]

fo=d : Rapports générés lorsque DKIM échoue

v=DMARC1; p=none; fo=d; ruf=mailto:[email protected]

fo=s : Rapports générés lorsque SPF échoue

v=DMARC1; p=none; fo=s; ruf=mailto:[email protected]

Cas particuliers

  • Plusieurs valeurs peuvent être combinées : fo=1:d:s
  • Les rapports forensiques sont de plus en plus désactivés par les destinataires
  • Les domaines à fort volume devraient utiliser fo=0 pour minimiser le volume de rapports

XIII. Exemples de configuration avancée

Déploiement d’entreprise

v=DMARC1; p=reject; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1; rf=afrf; ri=86400

Implémentation graduelle

v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Politique axée sur les sous-domaines

v=DMARC1; p=none; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]

XIV. Exigences de publication DNS

Les enregistrements DMARC doivent être publiés comme enregistrements TXT à _dmarc.votredomaine.com avec une configuration DNS appropriée :

Considérations TTL

  • TTL recommandé : 300-3600 secondes pour les changements de politique
  • Les valeurs TTL plus basses permettent des mises à jour de politique plus rapides
  • Les valeurs TTL plus élevées réduisent la charge de requête DNS

Limites d’enregistrement

  • Un seul enregistrement DMARC par domaine (plusieurs enregistrements causent des échecs)
  • La longueur maximale d’enregistrement varie selon le fournisseur DNS
  • Les enregistrements longs peuvent nécessiter une division d’enregistrement TXT

XV. Erreurs de syntaxe courantes

Problèmes d’espacement

# Incorrect - espaces dans les noms de balise
v = DMARC1; p = none

# Correct
v=DMARC1; p=none

Sensibilité à la casse

# Incorrect - la casse compte pour les valeurs
v=dmarc1; p=NONE

# Correct
v=DMARC1; p=none

Problèmes de délimiteur

# Incorrect - virgule au lieu de point-virgule
v=DMARC1, p=none

# Correct
v=DMARC1; p=none

Les organisations implémentant des politiques DMARC bénéficient de l’utilisation de Skysnag Protect pour surveiller les performances DMARC, valider la syntaxe des enregistrements et recevoir des rapports d’authentification détaillés. La plateforme fournit une visibilité en temps réel sur le statut d’authentification des e-mails et aide à identifier les problèmes de configuration avant qu’ils n’impactent la délivrance des e-mails.

XVI. Points clés à retenir

La syntaxe des enregistrements DMARC nécessite un formatage précis avec des balises de version et de politique obligatoires, tandis que les balises optionnelles fournissent un contrôle de rapport et d’alignement. Une implémentation réussie exige la compréhension de la fonction de chaque composant, une publication DNS appropriée et une escalade graduelle de politique. La surveillance régulière par des rapports agrégés assure l’efficacité de l’authentification tandis que les rapports forensiques aident à identifier des modèles d’échec spécifiques.

Une configuration DMARC appropriée protège les domaines contre les attaques d’usurpation tout en maintenant la délivrance d’e-mails légitimes lorsque les règles de syntaxe sont correctement suivies. Les organisations devraient commencer par des politiques de surveillance, valider minutieusement la syntaxe et implémenter l’autorisation de rapport externe lors de l’utilisation de services DMARC tiers.