BrowserTools
Accueil / Générateurs / Générateur SPF et DMARC

Générateur SPF et DMARC

Créez les enregistrements DNS qui empêchent d'autres personnes d'envoyer des e-mails en votre nom, ou vérifiez celui que vous avez déjà.

Maintenu par BrowserTools · Dernière mise à jour 2026-09-29

Chargement de Générateur SPF et DMARC… Si rien ne se passe, activez JavaScript.

N'importe qui peut mettre votre adresse dans le champ De d'un e-mail. SPF et DMARC sont les deux enregistrements DNS qui permettent aux serveurs de messagerie de distinguer le vrai courrier des contrefaçons. SPF (Sender Policy Framework) est un enregistrement TXT sur votre domaine qui liste les serveurs autorisés à envoyer pour lui : votre fournisseur de messagerie, votre service de newsletters, votre propre serveur. DMARC s'appuie dessus, sur _dmarc.votredomaine, et indique aux destinataires quoi faire du courrier qui échoue aux vérifications (le distribuer, le classer en spam ou le rejeter) et où envoyer des rapports à ce sujet. Gmail, Yahoo et Microsoft exigent désormais les deux des expéditeurs en masse, et sans eux votre courrier légitime a plus de chances de finir en spam tandis que le courrier usurpé passe.

Questions fréquentes

Où ajouter ces enregistrements ?
Dans les paramètres DNS de la société qui héberge le DNS de votre domaine, en général votre registraire ou un service comme Cloudflare. Créez un enregistrement TXT. Pour SPF, l'hôte est le domaine lui-même, souvent noté @. Pour DMARC, l'hôte est _dmarc, que certains panneaux demandent sous la forme _dmarc.exemple.com et d'autres simplement _dmarc, car ils ajoutent le domaine eux-mêmes. Les changements prennent généralement effet en quelques minutes à quelques heures, selon le TTL.
Quelle est la différence entre ~all et -all ?
Les deux ferment la liste des expéditeurs autorisés. Avec ~all (échec léger), le courrier des serveurs non listés est accepté mais traité comme suspect, ce qui signifie le plus souvent le dossier spam. Avec -all (échec strict), les destinataires peuvent le rejeter directement. ~all est le départ le plus sûr tant que vous découvrez encore tous les services qui envoient pour vous. Une fois DKIM et DMARC en place, -all est un bon choix, et Microsoft le recommande pour les domaines Microsoft 365. ?all n'offre aucune protection et +all autorise tout Internet : évitez les deux.
Pourquoi SPF est-il limité à 10 requêtes DNS ?
Vérifier un enregistrement SPF peut obliger le destinataire à interroger le DNS encore et encore, c'est pourquoi le RFC 7208 plafonne à 10 par vérification les mécanismes qui nécessitent une requête (include, a, mx, ptr, exists et redirect), en comptant aussi tout ce qui se trouve dans les include imbriqués. Dépasser la limite est une erreur permanente et SPF échoue pour tout votre courrier. Cet outil compte les requêtes écrites directement dans votre enregistrement. Il ne peut pas voir l'intérieur des enregistrements inclus sans requêtes DNS réelles, et certains en utilisent plusieurs à eux seuls, alors gardez de la marge. Si vous manquez de place, déplacez un service vers un sous-domaine ou remplacez un include par ses plages d'adresses IP publiées.
Puis-je avoir deux enregistrements SPF ?
Non. Un domaine ou sous-domaine doit publier exactement un enregistrement TXT commençant par v=spf1. S'il y en a deux, les destinataires renvoient une erreur permanente et SPF échoue pour tout, une erreur fréquente après l'ajout d'un nouveau service. Fusionnez-les : gardez un seul v=spf1 au début, placez tous les termes ip4, ip6 et include au milieu et terminez par un seul all.
Et DKIM ?
DKIM ajoute une signature cryptographique à chaque message sortant, et la clé publique correspondante est publiée dans le DNS sous un sélecteur, par exemple selector1._domainkey.exemple.com. La paire de clés est créée par celui qui signe votre courrier : vous ne pouvez donc pas générer seul un enregistrement DKIM utile. Activez DKIM dans la console d'administration de votre fournisseur (Google Workspace, Microsoft 365, SendGrid et autres) et publiez les enregistrements TXT ou CNAME qu'il vous donne. DKIM compte parce qu'il résiste au transfert, où SPF échoue souvent, et DMARC réussit si l'un des deux est aligné avec votre domaine De.
Par quelle politique DMARC commencer ?
Commencez par p=none avec une adresse rua. Rien ne change pour votre courrier, mais les destinataires commencent à envoyer des rapports agrégés quotidiens listant chaque serveur qui envoie au nom de votre domaine et le résultat des vérifications. Au bout de deux à quatre semaines, corrigez SPF ou DKIM pour tout expéditeur légitime en échec, puis passez à p=quarantine, et plus tard à p=reject. Rester indéfiniment en p=none ne protège pas : cela ne fait qu'observer.
Qu'est-ce qui a changé avec le RFC 9989 ?
En mai 2026, l'IETF a publié le RFC 9989, qui remplace le RFC 7489 comme norme DMARC, accompagné des RFC 9990 et 9991 pour les rapports. Il supprime les balises pct, ri et rf, ajoute t=y comme mode test simple et np pour les sous-domaines inexistants, et intègre la balise psd utilisée par les opérateurs de suffixes publics. Les enregistrements existants continuent de fonctionner et de nombreux destinataires respectent encore pct, c'est pourquoi cet outil garde pct et ri comme réglages anciens facultatifs.
Pourquoi les rapports envoyés vers un autre domaine exigent-ils un enregistrement supplémentaire ?
Pour empêcher quiconque de diriger des rapports DMARC vers une boîte qui ne lui appartient pas, les destinataires vérifient que la destination accepte de les recevoir. Si votre enregistrement pour exemple.com envoie les rapports à reports@dmarc-service.net, ce service doit publier un enregistrement TXT sur exemple.com._report._dmarc.dmarc-service.net contenant v=DMARC1. Les services de rapports s'en chargent quand vous ajoutez votre domaine, mais une boîte sur un autre domaine qui vous appartient en a aussi besoin.
Cet outil interroge-t-il mon domaine ?
Non. Les enregistrements sont créés et vérifiés entièrement dans votre navigateur, et rien de ce que vous saisissez n'est envoyé. Cela signifie aussi qu'il ne peut pas voir ce qui est publié actuellement ni résoudre les include imbriqués. Utilisez l'outil DNS Lookup pour récupérer les enregistrements TXT réels de votre domaine et de _dmarc.votredomaine, puis collez-les dans le vérificateur.

À propos de Générateur SPF et DMARC

Le générateur SPF vous laisse cocher les services que vous utilisez (Google Workspace, Microsoft 365, Zoho Mail, Amazon SES, SendGrid, Mailgun et Mailchimp Transactional, avec les valeurs include reprises de la documentation de chaque fournisseur), ajouter vos propres adresses IPv4 et IPv6 et choisir la sévérité du all final. Il compte les requêtes DNS au fur et à mesure, car SPF cesse de fonctionner au-delà de 10, et découpe la valeur en chaînes de 255 caractères quand un long enregistrement l'exige. Le vérificateur prend un enregistrement existant et explique chaque terme en langage clair. Il signale les erreurs de syntaxe comme include= au lieu de include:, un espace après les deux-points ou ipv4: au lieu de ip4:, et il avertit en cas de second enregistrement SPF sur le même domaine, de mécanisme ptr obsolète, de +all dangereux, de termes placés après all et d'enregistrements assez longs pour poser problème en UDP.

Le générateur DMARC suit le déploiement progressif qui évite de perdre du courrier : commencez par p=none avec une adresse de rapports, lisez les rapports pendant quelques semaines pour repérer tous les services qui envoient en votre nom, puis passez à quarantine et enfin à reject. Il couvre les politiques pour les sous-domaines et les sous-domaines inexistants, l'alignement strict ou souple, les options de rapports d'échec et le mode test du RFC 9989, la norme DMARC mise à jour publiée en mai 2026, et conserve les anciennes balises pct et ri pour les destinataires qui les utilisent encore. Les deux onglets affichent le nom d'hôte exact et la valeur TXT avec des boutons de copie. Tout est calculé dans votre navigateur et aucune requête DNS n'est effectuée : pour comparer avec ce qu'un domaine publie aujourd'hui, récupérez ses enregistrements TXT avec l'outil DNS Lookup et collez-les dans le vérificateur.

SPF est né pour arrêter les rebonds de spam

Au début des années 2000, les spammeurs falsifiaient couramment l'expéditeur d'enveloppe de leurs messages, et les rebonds de millions de spams non distribuables atterrissaient dans les boîtes de propriétaires de domaines innocents. Plusieurs propositions ont tenté d'y remédier, dont Reverse MX et Designated Mailers Protocol, et en 2003 Meng Weng Wong a réuni leurs idées dans Sender Permitted From, rapidement rebaptisé Sender Policy Framework. Microsoft a poussé un concurrent appelé Sender ID, et les deux ont été publiés côte à côte à titre expérimental en 2006. SPF l'a emporté : il est devenu norme proposée avec le RFC 7208 en 2014, tandis que Sender ID et ses enregistrements spf2.0 sont tombés dans l'oubli.

Seul, SPF avait une faille, car il vérifie l'adresse d'enveloppe cachée et non le champ De que les gens voient réellement. En 2012, un groupe comprenant PayPal, Google, Microsoft et Yahoo a publié DMARC, qui relie les résultats SPF et DKIM au domaine De visible et ajoute les rapports. PayPal avait de bonnes raisons : c'était l'une des marques les plus visées par l'hameçonnage. DMARC est resté des années un document informatif, le RFC 7489, avant que le RFC 9989 ne le place sur la voie des normes de l'IETF en 2026.

Outils associés

Recherche DNS

Voyez les enregistrements DNS de n'importe quel domaine, comme son adresse IP, ses serveurs mail et ses enregistrements TXT.

Recherche WHOIS

Voyez qui a enregistré un domaine, quand il expire et quel registraire il utilise.

Analyseur d'URL

Découpez une adresse web en ses parties : domaine, chemin, paramètres de requête et plus.

Générateur d'UUID

Créez des identifiants uniques (UUID), un par un ou en masse.
Soutenir