01À quoi servent ces enregistrements ?
SPF liste les serveurs autorisés à envoyer des emails au nom de votre domaine ; DMARC dit aux messageries quoi faire des messages qui échouent la vérification (rien, spam, rejet) et où envoyer les rapports. Sans eux, vos emails finissent en spam et n'importe qui peut usurper votre domaine — Gmail et Yahoo les exigent depuis 2024.
Ce générateur construit des enregistrements corrects par construction : un seul SPF, un seul all final, syntaxe DMARC valide. Une fois publiés dans votre zone DNS, vérifiez le résultat avec notre test email — il analyse aussi DKIM, la troisième brique, dont la clé est fournie par votre prestataire d'envoi.
02Comprendre chaque champ
- include:
- Délègue à la liste SPF de votre fournisseur : elle suit automatiquement ses changements d'infrastructure. Chaque include compte dans la limite des 10 requêtes DNS.
- ip4: / ip6:
- Autorise une adresse fixe (votre serveur d'envoi dédié). Ne compte pas dans la limite des 10 requêtes : à privilégier quand l'IP est stable.
- ~all / -all
- Le sort des serveurs non listés : ~all les marque suspects (softfail), -all les rejette. Commencez en ~all, passez en -all quand tout est aligné.
- p=
- La politique DMARC : none (observer), quarantine (spam), reject (rejet). La protection réelle commence à quarantine.
- rua=
- L'adresse qui reçoit les rapports agrégés quotidiens des messageries : indispensable pour savoir qui envoie en votre nom avant de durcir la politique.
- pct= / sp=
- pct applique la politique à un pourcentage des messages (montée progressive) ; sp définit une politique distincte pour les sous-domaines.
03Comment publier ces enregistrements ?
Dans l'interface DNS de votre registrar ou hébergeur (OVH, Gandi, Cloudflare…), créez deux enregistrements TXT : le premier sur l'hôte @ (la racine du domaine) avec la valeur SPF, le second sur l'hôte _dmarc avec la valeur DMARC. Si un SPF existe déjà, remplacez-le — deux enregistrements SPF rendent la configuration invalide.
La prise en compte suit le TTL de votre zone (voyez notre test de propagation). Publiez d'abord DMARC en p=none avec une adresse rua, analysez les rapports quelques semaines, alignez tous vos expéditeurs légitimes, puis durcissez vers quarantine et reject.
04Questions fréquentes
J'ai déjà un enregistrement SPF : puis-je en ajouter un deuxième ?
Non : la RFC 7208 impose un seul enregistrement SPF par domaine, sinon les serveurs peuvent tous les rejeter (permerror). Fusionnez les mécanismes dans un seul enregistrement : reprenez vos include existants, cochez-les ici avec vos nouveaux fournisseurs, et remplacez l'ancien enregistrement par le résultat.
Quelle adresse mettre dans rua ?
Une boîte que vous consultez ou, mieux, un service d'analyse DMARC (les rapports sont des XML quotidiens difficiles à lire à la main). L'adresse peut être sur un autre domaine — les messageries vérifient alors que ce domaine accepte les rapports pour le vôtre via un enregistrement d'autorisation.
Et DKIM, ce générateur ne le produit pas ?
Non, volontairement : la clé DKIM est une paire cryptographique générée par votre prestataire d'envoi (Google Workspace, Microsoft 365, Brevo…). Activez DKIM dans son interface, il vous fournira l'enregistrement exact (sélecteur + clé publique) à publier. Vérifiez-le ensuite avec notre test email.
Combien de temps rester en p=none ?
Le temps d'analyser les rapports rua : deux à six semaines suffisent généralement pour repérer tous vos flux d'envoi légitimes (CRM, facturation, newsletters…) et les aligner. Rester en p=none indéfiniment est l'erreur la plus courante : c'est une politique d'observation, pas de protection.
Le générateur garantit-il que mes emails arriveront ?
Il garantit des enregistrements syntaxiquement corrects, pas la délivrabilité : celle-ci dépend aussi de DKIM, de l'alignement des domaines, de la réputation de vos IP et du contenu de vos messages. SPF et DMARC sont le prérequis — le socle sans lequel le reste ne compte pas.