Générateur d'Enregistrements DMARC DNS et Validateur de Syntaxe

Générateur d'Enregistrements DMARC DNS et Validateur de Syntaxe

Générez et validez des enregistrements DNS TXT DMARC conformes à la RFC 7489 avec politiques de traitement (none/quarantine/reject), rapports agrégés rua/ruf et balises d'alignement.

Préréglages :
Enforcement Percentage (pct=)100%
Domain: example.comPolicy: rejectPct: 100%
Security Health ScoreNiveau de sécurité A+ (100/100)

Maximum defense against spoofing, BEC attacks, and phishing impersonation.

100/100
DMARC DNS TXT Value
v=DMARC1; p=reject; rua=mailto:[email protected]!10m
BIND 9 / RFC 1035 Master Zone Syntax
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]!10m"
DNS Management Table
Host / Name_dmarc(or _dmarc.example.com)
Record TypeTXT
TTL3600 (or Auto)
Length: 60 charsUDP DNS: < 255 B (Single String)
RFC 7489 Valid
État de la politiquep=reject (100%)
Flux de rapports1 RUA / 0 RUF
Modes d'alignementDKIM: Relaxed | SPF: Relaxed

Syntaxe conforme à la RFC 7489

Formate instantanément des balises v=DMARC1 valides avec un ordre strict et une validation rigoureuse.

Générateur dans le navigateur sans transmission

Tous les calculs de politique et l'analyse s'exécutent côté client sans aucune télémétrie.

Moteur d'exportation multiplateforme

Générez des enregistrements de zone BIND, configurations Cloudflare/Route53, commandes dig CLI et autorisations RFC 7489 Section 7.1.

Référence technique et guide d'architecture

Générateur d'Enregistrements DMARC DNS et Validateur de Syntaxe - Guide Développeur — Guide de référence

Générez et validez des enregistrements DNS TXT DMARC conformes à la RFC 7489 avec politiques de traitement (none/quarantine/reject), rapports agrégés rua/ruf et balises d'alignement.

Paramètres clés et contrôles

v (Version du protocole)Enum ("DMARC1")

Identifie l'enregistrement DNS comme une politique DMARC. Doit impérativement être la première balise de la chaîne TXT, en majuscules, suivie d'un point-virgule.

Par défaut : DMARC1
p (Politique appliquée par le récepteur)Enum ("none" | "quarantine" | "reject")

Politique de sécurité appliquée par les serveurs de messagerie récepteurs en cas d'échec conjoint de SPF et DKIM. 'none' surveille le flux sans blocage ; 'quarantine' déplace en boîte de courriers indésirables ; 'reject' refuse la distribution dès la transaction SMTP.

Par défaut : none
sp (Politique des sous-domaines)Enum ("none" | "quarantine" | "reject")

Remplace la politique 'p' spécifiquement pour l'ensemble des sous-domaines. Configurer 'sp=reject' immunise immédiatement les sous-domaines inactifs contre toute usurpation d'identité.

Par défaut : Héritée (identique à p)
rua (URIs pour les rapports agrégés)Liste d'URIs (mailto:address)

Liste séparée par des virgules d'URIs mailto: recevant les rapports télémétriques XML quotidiens récapitulant les résultats d'authentification, les adresses IP d'origine et les volumes de distribution.

Par défaut : Aucun
ruf (URIs pour les rapports médico-légaux/d'échec)Liste d'URIs (mailto:address)

Liste d'URIs mailto: destinées à la réception en temps réel d'incidents détaillés au format RFC 6591 AFRF lors d'échecs de conformité.

Par défaut : Aucun
pct (Pourcentage d'application de la politique)Integer (0 - 100)

Pourcentage de messages non conformes auxquels la politique 'p' ou 'sp' est appliquée. Permet un déploiement progressif sécurisé (ex. 25% -> 50% -> 100%) avant d'activer le rejet absolu.

Par défaut : 100
adkim / aspf (Modes d'alignement)Enum ("r" | "s")

Définit la rigueur de correspondance de domaine pour DKIM et SPF. 'r' (assoupli) valide la correspondance au niveau du domaine organisationnel racine (subdomain.example.com avec example.com) ; 's' (strict) impose une égalité FQDN exacte.

Par défaut : r (assoupli)

Conseils de pro et bonnes practices

Débutez impérativement avec 'p=none'

Débutez impérativement avec 'p=none' pendant 2 à 4 semaines afin d'analyser les rapports XML agrégés (rua) et d'identifier vos prestataires tiers légitimes (SendGrid, Microsoft 365, Mailjet). Dès que plus de 99 % de vos flux légitimes sont alignés en SPF et DKIM, passez à 'p=quarantine; pct=25', montez à 100 %, puis verrouillez définitivement sur 'p=reject'.

Si votre domaine est 'example.com' et

Si votre domaine est 'example.com' et que votre 'rua' pointe vers 'mailto:[email protected]', la RFC 7489 Section 7.1 exige que le domaine tiers publie un enregistrement TXT à l'adresse 'example.com._report._dmarc.thirdparty.com' contenant 'v=DMARC1;'. Sans cette validation mutuelle, les serveurs récepteurs bloquent l'envoi des rapports par mesure anti-DDoS.

Les cyberattaquants usurpent

Les cyberattaquants usurpent fréquemment des sous-domaines inventés (ex. facturation.example.com). En configurant 'v=DMARC1; p=none; sp=reject; rua=mailto:...', vous ne perturbez aucunement la délivrabilité de votre domaine principal tout en neutralisant instantanément l'usurpation de vos sous-domaines.

Lorsqu'un message transite par une

Lorsqu'un message transite par une liste de diffusion ou un relais de transfert automatique, l'adresse IP de l'expéditeur d'enveloppe change, provoquant l'échec inévitable du SPF. En revanche, les signatures cryptographiques DKIM restent valides tout au long du transit, évitant ainsi les faux positifs sous DMARC.

Pièges courants et dépannage

Aucun rapport agrégé rua n'est reçu de la part des grands fournisseurs (Google, Microsoft, Yahoo)

Vérifiez que la balise rua comporte bien le préfixe obligatoire 'mailto:' (ex. 'mailto:[email protected]'). Si vous utilisez un domaine externe pour collecter vos rapports, assurez-vous que l'enregistrement d'autorisation externe est publié dans le DNS tiers et que la boîte de réception ne sature pas.

Vos e-mails marketing ou CRM légitimes sont classés en spam ou rejetés après passage en quarantine/reject

Consultez les fichiers XML pour diagnostiquer les défauts d'alignement. Vérifiez que la plateforme d'envoi externe applique une signature DKIM personnalisée dont le domaine correspond exactement à l'en-tête 'From:' visible (RFC 5322), et configurez les enregistrements CNAME de Return-Path pour le SPF.

Les outils d'analyse DNS indiquent 'Enregistrement DMARC introuvable' ou 'Enregistrements DMARC multiples'

L'enregistrement DMARC doit impérativement être publié sous forme d'enregistrement TXT sur le sous-domaine '_dmarc.mon-domaine.fr' (et non sur la racine '@'). De plus, il ne doit exister qu'un seul enregistrement commençant par 'v=DMARC1' ; la présence de doublons entraîne l'invalidation totale de la politique selon la RFC 7489.

Foire aux questions (FAQ)

Quelle est l'articulation technique entre SPF, DKIM et DMARC ?▼

SPF (RFC 7208) valide l'adresse IP du serveur émetteur par rapport à l'enveloppe de retour (MAIL FROM). DKIM (RFC 6376) signe cryptographiquement les en-têtes et le corps pour certifier l'intégrité du message. DMARC (RFC 7489) relie ces deux mécanismes à l'adresse visible dans l'en-tête 'From:' (RFC 5322), impose l'alignement de domaine, dicte la conduite à tenir en cas d'échec et assure la remontée de rapports.

Faut-il valider à la fois SPF et DKIM pour que DMARC soit validé ?▼

Non. Selon les spécifications de la RFC 7489, un message réussit le test DMARC si l'alignement SPF OU l'alignement DKIM est conforme. La réussite d'un seul des deux protocoles suffit, bien que la mise en œuvre simultanée des deux soit fortement recommandée pour parer aux ruptures de transfert.

Quelle est la différence entre les modes d'alignement assoupli ('r') et strict ('s') ?▼

En mode assoupli ('r', valeur par défaut), le domaine du Return-Path (SPF) ou de la signature DKIM doit simplement partager le même domaine organisationnel racine que l'en-tête From: (ex. contact.example.com et example.com). En mode strict ('s'), les noms d'hôtes complets (FQDN) doivent être strictement identiques.

Pourquoi les listes de diffusion et les transferts automatiques provoquent-ils des échecs DMARC ?▼

Les serveurs de transfert modifient l'adresse IP de l'expéditeur de l'enveloppe, ce qui invalide le SPF. De plus, les listes de diffusion ajoutent souvent un préfixe dans le sujet ou un pied de page, rompant ainsi la somme de contrôle DKIM. Pour remédier à ce phénomène, les acteurs du secteur déploient le protocole ARC (Authenticated Received Chain, RFC 8617) afin de préserver l'historique d'authentification.

Quelles sont les différences majeures entre les rapports agrégés rua et les rapports d'échec ruf ?▼

Les rapports rua fournissent des récapitulatifs XML quotidiens sur les volumes d'envoi, les adresses IP d'origine et les taux de conformité, sans inclure le contenu des courriels. Les rapports ruf envoient des alertes médico-légales individuelles en temps réel avec des extraits d'en-têtes et de corps de messages. Pour des motifs de protection de la vie privée et de conformité RGPD, la plupart des grands fournisseurs de messagerie ont désactivé l'envoi de rapports ruf.

Outils et utilitaires connexes

Tous les outils →
Guide Développeur du Générateur d'Enregistrements DNS CAA (Certification Authority Authorization)Sécurité

Générez des enregistrements DNS CAA conformes à la RFC 8659 pour restreindre l'émission de certificats SSL/TLS aux seules autorités de certification de confiance (Let's Encrypt, DigiCert, Sectigo).

Ouvrir l'outil→
Guide Développeur : Générateur d'Enregistrements DNS DKIM TXT & SélecteursSécurité

Générez des enregistrements DNS DKIM TXT conformes à la RFC 6376 avec sélecteur, formatage de clé publique (v=DKIM1; k=rsa; p=...), découpage à 255 caractères et validation.

Ouvrir l'outil→
Guide Développeur : Générateur de Stratégies MTA-STS et Enregistrements DNS TLS-RPTSécurité

Guide de référence technique et bonnes pratiques pour générer les fichiers de stratégie RFC 8461 MTA-STS, les enregistrements DNS TXT _mta-sts et les rapports d'incidents RFC 8460 TLS-RPT.

Ouvrir l'outil→
Décodeur de Jeton JWT & Inspecteur de SécuritéSécurité

Utilitaire pour développeurs permettant de décoder les JSON Web Tokens côté client, d'inspecter les claims RFC 7519 et OIDC, d'auditer les expirations et de vérifier les signatures HMAC localement.

Ouvrir l'outil→
Générateur Criptographique de Mots de Passe & PassphrasesSécurité

Générez des mots de passe robustes à haute entropie, des passphrases mémorisables (Diceware), des codes PIN et des jetons d'API avec l'API Web Crypto CSPRNG conforme à la norme NIST SP 800-63B.

Ouvrir l'outil→
Générateur de Hachage Cryptographique et Contrôle d'IntégritéSécurité

Calculez instantanément les empreintes SHA-256, SHA-512, MD5, SHA-1, SHA-3, Keccak et CRC32 localement dans votre navigateur avec l'API Web Crypto 100% sécurisée.

Ouvrir l'outil→