/
Générateur DNS Email (SPF DKIM DMARC)

Générateur DNS Email (SPF DKIM DMARC)

Générez des enregistrements DNS complets : SPF, DKIM, DMARC, MX et BIMI. Exportez vos fichiers de zone BIND, bloquez l'usurpation et garantissez une délivrabilité optimale.

✨ Préréglages :

Pipeline d'authentification et de distribution des emails

Posture DMARC active :p=none
MTA expéditeuracme-corp.comPasserelle SPF~all (1/10 requêtes)RFC 7208Vérification DKIMgoogle (RSA-2048)RFC 6376Alignement DMARCp=none (100%)RFC 7489Livré en boîte de réceptionSurveillance seuleSpam / QuarantaineContournéRejet 550 / DropInactif
Domaine et architecture de messagerieacme-corp.com
Paramètres d'enregistrement SPF (RFC 7208)1/10 requêtes
Paramètres d'enregistrement DKIM (RFC 6376)
Moteur de politique DMARC (RFC 7489)_dmarc.acme-corp.com
Pourcentage d'application (pct=)100%
Routage de messagerie MX (RFC 5321)1 serveurs
1smtp.google.com.
Indicateur de marque BIMI (BIMI v1)
Domaine : acme-corp.comRequêtes SPF : 1/10
Tableau récapitulatif de tous les enregistrements DNS synthétisés. Copiez chaque valeur individuellement ou exportez le fichier de zone complet.4 enregistrements
TypeHôte / NomPriorité / TTLContenu de l'enregistrementAction
MX@1 (TTL 3600)smtp.google.com.
TXT@3600v=spf1 include:_spf.google.com ~all
TXTgoogle._domainkey3600v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w9Z8fGk3wIDAQAB
TXT_dmarc3600v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Total des enregistrements : 4Posture : B (65/100)
Quota de requêtes RFC 7208
1 / 10Zéro PermError
Sécurité cryptographique des clés
RSA-2048Chaîne unique
Politique anti-usurpation
p=none100% Déploiement

Traitement côté client

Calcul haute performance exécuté intégralement dans la mémoire du navigateur.

Confidentialité et zéro téléversement

Toutes les données restent strictement locales, sans aucune communication externe.

Export prêt pour la production

Formats de sortie optimisés et propres, prêts pour un déploiement immédiat.

Référence technique et guide d'architecture

Générateur DNS Email (SPF DKIM DMARC) — Guide de référence

Générez des enregistrements DNS de messagerie complets (SPF, DKIM, DMARC, MX et BIMI). Exportez des fichiers de zone BIND, éliminez l'usurpation et garantissez 100 % de délivrabilité.

Générateur DNS Email (SPF DKIM DMARC) — Guide de référence — Architecture en mémoire côté client et flux de données
Générateur DNS Email (SPF DKIM DMARC) — Guide de référence — Architecture en mémoire côté client et flux de données

Paramètres clés et contrôles

v=spf1 (Version Sender Policy Framework)Chaîne ("v=spf1")

Désigne l'enregistrement TXT comme une politique SPF version 1 (RFC 7208). Doit impérativement constituer le tout premier préfixe de la chaîne ; tout caractère antérieur ou variante en minuscules entraîne le rejet par les MTA récepteurs avec l'erreur PermError.

Par défaut : v=spf1
include (Délégation de domaines autorisés SPF)Liste de domaines ("include:domaine.com")

Délègue l'autorisation SPF à l'enregistrement SPF d'un service d'expédition tiers. Chaque directive include déclenche une requête DNS récursive comptabilisée dans la limite obligatoire de 10 résolutions de la RFC 7208.

Par défaut : _spf.google.com
all (Qualificateur de repli SPF)Enum ("-all" | "~all" | "?all" | "+all")

Définit le traitement appliqué aux courriels émis depuis des adresses IP non autorisées. -all impose un rejet strict (hard fail) ; ~all applique un échec partiel (soft fail, accepté mais suspect) ; ?all indique une disposition neutre.

Par défaut : ~all
k & p (Algorithme et clé publique DKIM)Enum ("rsa" | "ed25519") & Clé Base64

Publié dans l'enregistrement TXT sous <selecteur>._domainkey.<domaine>. Définit l'algorithme cryptographique k et la clé publique codée en base64 p exploitée par les MTA récepteurs pour valider les en-têtes DKIM-Signature selon les RFC 6376 et RFC 8463.

Par défaut : k=rsa; p=...
p & sp (Politique DMARC et politique de sous-domaine)Enum ("none" | "quarantine" | "reject")

Détermine la façon dont les serveurs de messagerie récepteurs traitent les messages en échec d'alignement DMARC selon la RFC 7489. none recueille la télémétrie sans filtrer ; quarantine isole en dossier spam ; reject bloque intégralement la remise.

Par défaut : none
rua & ruf (URI de rapports télémétriques DMARC)Liste d'URI (mailto:[email protected])

rua reçoit quotidiennement les rapports XML agrégés récapitulant les volumes et taux d'authentification ; ruf collecte en temps quasi réel les notifications forensiques individuelles d'échec au format AFRF (RFC 6591).

Par défaut : mailto:[email protected]
aspf & adkim (Modes d'alignement d'identifiants DMARC)Enum ("r" | "s")

r (souple / relaxed) autorise l'alignement des sous-domaines avec le domaine organisationnel racine ; s (strict) requiert une correspondance exacte au caractère près entre le domaine From (RFC 5322) et le Return-Path SPF ou domaine DKIM d=.

Par défaut : r
BIMI Emplacement et autorité (balises l= et a=)Chaîne URI HTTPS

Publié sous default._bimi.<domaine>. La balise l= pointe vers un logo de marque au format SVG Tiny Portable/Secure carré ; la balise a= lie optionnellement un certificat de marque vérifiée (VMC) au format PEM.

Par défaut : None

Conseils de pro et bonnes pratiques

Éviter le piège fatal de la limite de 10 résolutions DNS en SPF

La RFC 7208 limite strictement l'évaluation SPF à 10 requêtes DNS cumulées pour les mécanismes include, a, mx, ptr et redirect. Dépasser 10 requêtes génère une erreur définitive PermError, incitant les principaux fournisseurs (Gmail, Yahoo, Outlook) à classer vos messages en spam ou à les rejeter. Privilégiez les blocs CIDR IP plutôt que les directives a ou mx, et aplanissez régulièrement les chaînes d'include de vos prestataires tiers.

Fractionner les clés DKIM 2048 bits pour BIND et Cloudflare

Les enregistrements DNS TXT imposent une longueur maximale de 255 octets par chaîne unitaire (RFC 1035). Une clé RSA standard de 2048 bits génère environ 400 caractères en base64. Ne tronquez jamais la clé : encapsulez plutôt la charge utile dans des guillemets concaténés : ("v=DKIM1; k=rsa; p=PREMIERS_200_CARACTÈRES" "CARACTÈRES_RESTANTS"). Cloudflare segmente automatiquement cette chaîne en interface web, mais les fichiers de zone BIND bruts exigent une concaténation explicite entre parenthèses.

Déployer DMARC en 3 phases progressives

Ne basculez jamais directement sur p=reject en production. Commencez par p=none; rua=mailto:... pendant 2 à 4 semaines pour cartographier l'ensemble des flux légitimes (CRM, outils de billetterie, paie). Passez ensuite à p=quarantine; pct=25 en augmentant progressivement jusqu'à pct=100, puis verrouillez définitivement avec p=reject; sp=reject dès que tous les flux légitimes valident l'alignement SPF et DKIM.

Bloquer l'usurpation des sous-domaines fantômes avec sp=reject

Les cyberattaquants ciblent fréquemment des sous-domaines inactifs (ex. : factures.votredomaine.fr). Si votre domaine racine opère sous p=none durant votre phase d'audit, ajoutez explicitement sp=reject pour bloquer sur-le-champ l'exploitation malveillante des sous-domaines orphelins, tout en maintenant inchangé le trafic de votre domaine principal.

Pièges courants et dépannage

⚠️DMARC échoue à l'alignement alors que SPF et DKIM sont tous deux notés PASS

La réussite technique ne suffit pas : DMARC exige un alignement d'identifiant strict ou assoupli. Vérifiez si le domaine affiché dans l'en-tête From: (RFC 5322) concorde avec le Return-Path (Mail From, RFC 5321) pour SPF ou avec la balise d= pour DKIM. En cas d'envoi via un tiers (ex. : SendGrid, Mailchimp ou Zendesk), configurez des clés DKIM personnalisées et un CNAME de Return-Path dédié pour que les en-têtes soient signés par votre propre domaine d'entreprise et non par le domaine mutualisé du fournisseur.

⚠️Gmail et Yahoo rejettent les courriels avec l'erreur 550-5.7.26 (échec d'authentification)

Depuis février 2024, Google et Yahoo imposent obligatoirement SPF, DKIM et DMARC à tous les expéditeurs de messages en masse (>5 000 envois/jour). Assurez-vous que votre domaine dispose d'un enregistrement DMARC valide (au minimum p=none), d'un rDNS/PTR pointant vers le nom d'hôte de votre serveur MTA émetteur et d'en-têtes de désinscription en un clic (RFC 8058). Vérifiez également que votre enregistrement SPF ne dépasse pas le plafond des 10 requêtes DNS.

⚠️Le fournisseur DNS signale « Chaîne supérieure à 255 caractères » ou une syntaxe TXT invalide

Cette anomalie survient lors du collage d'une clé DKIM 2048 ou 4096 bits dans un panneau de gestion DNS ne prenant pas en charge le fractionnement automatique. Activez l'option de découpage sécurisé 255 octets de cet outil pour exporter l'enregistrement sous forme de sous-chaînes délimitées par des guillemets, ou générez une clé cryptographique moderne Ed25519 si votre agent de transfert de courrier (MTA) la prend en charge.

Foire aux questions (FAQ)

Comment la limite des 10 requêtes DNS de SPF affecte-t-elle la délivrabilité des emails ?▼

La RFC 7208 impose que l'évaluation d'un enregistrement SPF n'excède jamais 10 requêtes DNS directes ou imbriquées réparties entre les directives include:, a, mx, ptr, exists: et redirect. Si un message entrant engendre une 11e requête, le MTA récepteur interrompt instantanément l'analyse en renvoyant une erreur permanente PermError. La majorité des messageries modernes (Google Workspace, Microsoft 365, Orange, Yahoo) interprètent ce PermError comme un échec critique d'authentification, entraînant le placement direct en boîte de courriers indésirables ou un rejet pur et simple au niveau SMTP. Pour demeurer sous ce seuil critique, supprimez les mécanismes superflus a et mx, consolidez vos plages d'adresses réseau au format CIDR dans des directives ip4: et ip6:, et évitez d'empiler plusieurs services SaaS sur votre domaine principal.

Pourquoi les emails échouent-ils à l'alignement DMARC malgré des tests SPF et DKIM réussis ?▼

L'authentification DMARC requiert non seulement la validation technique de SPF ou de DKIM, mais exige également que le domaine validé corresponde fidèlement au domaine affiché dans l'en-tête From: (RFC 5322) vu par le destinataire. Lorsque vous envoyez des courriels par le biais de plateformes SaaS comme SendGrid, Salesforce ou Shopify sans configuration de domaine personnalisé, le contrôle SPF réussit pour le domaine de l'hébergeur (ex. : sendgrid.net dans le Return-Path) et DKIM peut être validé avec la signature partagée du prestataire, mais aucun ne correspond à votre propre domaine. En raison de cette divergence d'identifiants, l'alignement DMARC échoue. Pour remédier à cela, vous devez configurer un sous-domaine de Return-Path personnalisé pour SPF et déployer des enregistrements CNAME DKIM dédiés afin de signer cryptographiquement les messages au nom de votre propre nom de domaine.

Comment fractionner les clés publiques DKIM 2048 bits dépassant 255 caractères dans un enregistrement TXT ?▼

D'après la RFC 1035, une chaîne de texte unitaire au sein d'un enregistrement DNS TXT ne peut pas dépasser 255 octets. Une clé publique RSA 2048 bits encodée en base64 atteignant environ 400 caractères, elle impose un partitionnement en plusieurs segments. Dans les fichiers de zone BIND et sur PowerDNS, cette opération s'effectue en enveloppant la valeur dans des parenthèses et en entourant chaque tronçon de guillemets doubles : ( "v=DKIM1; k=rsa; p=PARTIE_1" "PARTIE_2" ). Lors de la résolution DNS, les résolveurs récursifs concatènent automatiquement ces segments contigus sans ajouter d'espace blanc. Les interfaces modernes comme Cloudflare, AWS Route 53 et Google Cloud DNS gèrent ce découpage de manière transparente en tâche de fond, tandis que les consoles d'hébergement traditionnelles (cPanel ou certains bureaux d'enregistrement) exigent un découpage manuel conforme.

Quelle est la différence entre les politiques DMARC p=none, p=quarantine et p=reject ?▼

La balise p= dicte la mesure de protection que les MTA récepteurs doivent appliquer lorsqu'un courriel prétendant émaner de votre domaine échoue simultanément aux alignements SPF et DKIM. La politique p=none correspond à une surveillance passive : les messages sont remis sans altération tandis que des rapports télémétriques XML agrégés sont expédiés à votre adresse rua=. La politique p=quarantine ordonne aux serveurs de reléguer les courriels suspects dans le dossier des spams ou en quarantaine administrative, évitant ainsi l'hameçonnage direct tout en autorisant une analyse humaine. Enfin, la politique p=reject correspond au niveau de protection maximal : elle commande au serveur de rejeter le message dès la transaction SMTP (rejet HTTP 550 SMTP), empêchant purement et simplement le message frauduleux d'atteindre l'infrastructure du destinataire.

Comment configurer les enregistrements BIMI avec un certificat de marque vérifiée (VMC) pour Gmail et Apple Mail ?▼

La norme BIMI (Brand Indicators for Message Identification) permet d'afficher le logo certifié d'une organisation directement à côté des messages dans les clients de messagerie compatibles tels que Gmail, Apple Mail et Yahoo. Pour implémenter BIMI : 1) Assurez-vous que votre domaine applique une politique DMARC stricte configurée sur p=quarantine (avec pct=100) ou p=reject ; 2) Créez un logo vectoriel conforme aux spécifications rigoureuses du profil SVG Tiny Portable/Secure (ratio 1:1 parfaitement carré, sans script externe ni animation, balisage XML strict) ; 3) Obtenez un certificat de marque vérifiée (VMC) auprès d'une autorité de certification habilitée (comme DigiCert ou Entrust) attestant du dépôt légal de votre marque ; 4) Publiez un enregistrement TXT à l'adresse default._bimi.votredomaine.fr avec la valeur v=BIMI1; l=https://votredomaine.fr/bimi-logo.svg; a=https://votredomaine.fr/vmc-cert.pem. Bien que Yahoo prenne en charge l'affichage sans VMC, Google et Apple requièrent impérativement un certificat VMC valide pour afficher le logo.

Outils et utilitaires connexes

Tous les outils →
Décodeur JWT (Décodage & Vérification)Sécurité

Déboguez vos jetons JWT en ligne en toute sécurité. Décodez l'en-tête et le payload, vérifiez les signatures HS256, RS256 et ES256, et inspectez l'expiration en local.

Ouvrir l'outil→
Générateur Content Security Policy (CSP)Sécurité

Générez des en-têtes Content Security Policy (CSP) sécurisés en un clic. Configurez script-src, style-src, nonces et empreintes SHA-256 pour bloquer les attaques XSS et éliminer les erreurs CSP.

Ouvrir l'outil→
Générateur de Hachage Bcrypt et Vérificateur de Mots de PasseSécurité

Générez des hachages de mots de passe Eksblowfish avec rounds de salt réglables (4-16) et vérifiez les candidats localement dans le navigateur.

Ouvrir l'outil→
Générateur et Vérificateur de Signature HMACSécurité

Calculez et vérifiez les codes d'authentification de message RFC 2104 (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, HMAC-MD5) avec comparaison en temps constant (Timing-Safe) dans votre navigateur.

Ouvrir l'outil→
Chiffreur et Déchiffreur AES-GCM / CBC Côté ClientSécurité

Chiffrement authentifié matériel AES-256 exécuté directement dans votre navigateur via l'API Web Crypto. Zéro transmission serveur.

Ouvrir l'outil→
Générateur de Paires de Clés RSA (Publique & Privée)Sécurité

Générez des paires de clés RSA hautement sécurisées (2048 et 4096 bits) au format PEM PKCS#8 directement dans votre navigateur via l'API Web Crypto.

Ouvrir l'outil→