Générateur d'enregistrement DMARC
Construisez un enregistrement DMARC TXT correct avec presets de policy, plan de déploiement progressif et avertissements qui attrapent les erreurs avant le DNS.
Ce générateur d'enregistrement DMARC construit la valeur TXT exacte que vous publiez, directement dans votre navigateur, donc rien de ce que vous saisissez ne quitte la page. Choisissez une policy expliquée simplement (p=none, quarantine ou reject), réglez l'adresse de rapport, et il écrit la valeur v=DMARC1 avec le host où la publier, qui est _dmarc.votredomaine.com et pas la racine, l'erreur que les gens font en permanence. Il suit la syntaxe des tags de la RFC 7489 pour sp, pct, adkim, aspf, rua, ruf et fo, et n'invente rien. Les presets de déploiement progressif vous mènent de la surveillance à la mise en application, et des avertissements en direct signalent les combinaisons dangereuses, comme reject sans aucun rapport ou un pct sans effet sous p=none, avant que vous ne colliez l'enregistrement dans un panneau DNS.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur d'enregistrement DMARC avec presets de policy et plan de déploiement progressif
Le tout premier enregistrement DMARC que j'ai publié avait une coquille dans l'adresse rua. Je suis resté deux semaines à me demander pourquoi aucun rapport n'arrivait. Du coup, ce générateur fait les vérifs barbantes à ma place maintenant. Choisissez votre policy, saisissez l'adresse qui recevra les rapports, et il écrit l'enregistrement TXT exact plus le host où le publier (c'est _dmarc.votredomaine.com, pas la racine, et oui, les gens se trompent là-dessus en permanence). Il s'en tient à la syntaxe des tags de la RFC 7489 et n'invente rien. Tout tourne dans votre navigateur. Une fois l'enregistrement en ligne, collez votre domaine dans un vérificateur d'enregistrement DMARC pour confirmer que le DNS sert vraiment ce que vous avez écrit.
Vous pouvez lister plusieurs adresses séparées par des virgules. Petite mise en garde sur ruf : la plupart des gros fournisseurs de boîtes mail n'envoient tout simplement plus de failure reports (raisons de vie privée), donc ne comptez pas trop sur ce canal.
v=DMARC1; p=none
Ce que DMARC apporte vraiment par-dessus SPF et DKIM
Ce générateur d'enregistrement DMARC écrit la valeur TXT exacte que vous publiez, mais d'abord, pourquoi DMARC. SPF dit quels serveurs ont le droit d'envoyer pour votre domaine. DKIM signe le message pour que toute altération se voie. Utile, les deux. Mais voilà le trou dont personne ne vous parle : aucun des deux ne vérifie l'adresse From que votre destinataire voit réellement. Un phisheur peut passer SPF sur son propre domaine tout en affichant le vôtre dans l'en-tête From, et pas mal de filtres laissent passer.
DMARC comble ce trou avec l'alignment. Il exige que le domaine de l'en-tête From visible corresponde au domaine qui a passé SPF ou DKIM. Pas de correspondance, pas de pass. Et ensuite, c'est la partie que je préfère, il vous laisse dire aux serveurs destinataires quoi faire des échecs, et il leur demande de vous envoyer des rapports. D'un coup, vous voyez qui envoie au nom de votre domaine. Une partie, ce sera vous (un outil de newsletter oublié, le CRM, cette fameuse plateforme marketing). Une autre, non.
Lire les niveaux de policy honnêtement
La version marketing, c'est « none, quarantine, reject, prenez reject pour une sécurité maximale ». La version honnête est plus nuancée.
p=none ne bloque rien. C'est purement un robinet à rapports, et c'est exactement pour ça que c'est précieux. Vous le laissez tourner quelques semaines et vous découvrez tous les systèmes qui envoient du mail au nom de votre domaine, y compris les trois que vous aviez oubliés. Honnêtement, je n'ai jamais vu un domaine où la première fournée de rapports ne réservait aucune surprise.
p=quarantine demande aux destinataires de traiter les échecs comme suspects, ce qui en pratique veut dire le dossier spam. C'est le juste milieu récupérable. Un expéditeur légitime que vous avez raté atterrit en spam au lieu de disparaître, et quelqu'un finira bien par vous le signaler.
p=reject refuse le mail en échec dès la porte. C'est le bon état final pour la plupart des domaines, et c'est aussi là que les factures de votre système de facturation cessent d'arriver en silence si vous êtes allé trop vite. Reject n'est pas plus courageux que quarantine. Juste moins indulgent.
Le déploiement progressif que je recommande
C'est la même séquence que celle des boutons preset au-dessus, et je dirais que le calendrier compte plus que les tags.
- Semaines 1 à 4 : p=none avec rua renseigné. Collectez les rapports. Corrigez SPF et DKIM pour chaque source légitime que vous trouvez. Ne touchez pas à la policy tant que les rapports ne sont pas devenus ennuyeux.
- Semaines 5 à 8 : p=quarantine avec pct=25. Seul un quart du mail en échec part en quarantaine, donc une erreur pique au lieu de saigner. Montez pct par paliers (50, puis 100) tant que les rapports restent propres.
- Ensuite : p=reject. Gardez rua dans l'enregistrement pour toujours. De nouveaux outils SaaS qui envoient du mail au nom de votre domaine vont apparaître, en général sans que personne ne prévienne l'IT.
Franchement, la fenêtre de surveillance de quatre semaines, c'est un plancher, pas un objectif. Une grosse boîte avec des décennies de shadow IT ? Comptez plutôt trois mois. Je suis peut-être trop prudent là-dessus, mais je n'ai jamais regretté un déploiement DMARC lent, et j'ai vu un déploiement rapide avaler une semaine de notifications de paie.
Les erreurs classiques que je continue de voir
Publier l'enregistrement à la racine du domaine au lieu du sous-domaine _dmarc. L'enregistrement lui-même est parfait, le DNS le sert juste sous le mauvais nom, et tous les destinataires l'ignorent.
Zapper rua complètement. Une policy sans rapports, ça revient à appliquer des règles à un trafic que vous ne voyez pas. Quand quelque chose de légitime se met à échouer, votre premier indice est un coup de fil énervé.
Sauter directement à p=reject parce qu'une checklist de conformité l'a dit. La checklist ne se trompe pas sur la destination, juste sur la vitesse.
Deux autres, plus rapides : oublier que des adresses rua sur un autre domaine exigent un enregistrement de vérification côté réception avant que les rapports circulent (la RFC 7489 appelle ça external destination verification), et activer l'alignment strict dès le premier jour. L'alignment relaxed laisse passer le mail des sous-domaines comme mail.example.com ; le strict non, et la plupart des configs en dépendent sans le savoir.
Questions fréquentes
Où exactement publier l'enregistrement DMARC ?
Dans un enregistrement TXT à _dmarc.votredomaine.com, avec l'underscore. Pas à la racine, pas sur www. Dans la plupart des panneaux DNS, vous saisissez juste _dmarc comme nom et le panneau ajoute votre domaine automatiquement.
Est-ce que p=none sert à quelque chose ?
Il ne bloque rien, et c'est justement le but. Il active les rapports pour que vous puissiez cartographier chaque système qui envoie au nom de votre domaine avant la moindre mise en application. Le sauter, c'est comme ça que du mail légitime finit rejeté plus tard.
Que contrôle pct au juste ?
Il demande aux destinataires d'appliquer votre policy à seulement ce pourcentage des messages en échec. pct=25 avec quarantine, ça veut dire qu'environ un quart des échecs part en quarantaine et que le reste passe. Ça ne compte qu'avec quarantine ou reject ; combiné à p=none, il n'y a rien à doser.
Ai-je besoin de rua et de ruf ?
Il vous faut rua. Les rapports agrégés, c'est toute la boucle de retour. ruf est optionnel et franchement peu fiable, vu que la plupart des grands fournisseurs ont arrêté d'envoyer des failure reports pour des questions de vie privée. Mettez-le si vous voulez, mais ne bâtissez pas votre process dessus.
Quelle différence entre alignment relaxed et strict ?
Relaxed accepte une correspondance au niveau du domaine organisationnel, donc un mail signé par mail.example.com s'aligne avec un From en example.com. Strict exige une correspondance exacte. Relaxed est le défaut et le bon choix pour presque tout le monde ; strict casse les expéditeurs en sous-domaine que vous aviez oubliés.
Combien de temps avant mes premiers rapports agrégés ?
En général sous 24 à 48 heures, puisque la plupart des destinataires envoient un rapport par jour et par domaine. Si rien n'arrive au bout de trois jours, vérifiez l'enregistrement avec un outil de lookup DMARC et relisez l'adresse rua à la recherche d'une coquille. Vécu.