Un exemple d’enregistrement DMARC présente une politique DNS TXT demandant au destinataire comment traiter les messages lorsqu’aucun mécanisme SPF ou DKIM ne fournit de résultat valide et aligné sur From. Une mauvaise configuration peut laisser l’usurpation sans restrictions DMARC ou affecter des messages légitimes ; les autres filtres et exigences Gmail interviennent aussi. Pour configurer l’ensemble, consultez le guide du courrier professionnel et celui pour créer des e-mails avec votre domaine.
Publiez une seule politique DMARC valide sur _dmarc.yourdomain.com. Si tous les expéditeurs ne sont pas connus, commencez par observer, puis envisagez quarantaine ou rejet après validation des flux. Le guide des enregistrements DNS requis de TrekMail présente la base ; cet article explique quel exemple d’enregistrement DMARC choisir à chaque étape.
Ce que fait un enregistrement DMARC
Un exemple d’enregistrement DMARC peut indiquer la version, la politique demandée pour les messages en échec et une destination de rapports. DMARC repose sur SPF et DKIM, sans les remplacer ni les réparer. Il vérifie qu’au moins un mécanisme réussit avec alignement sur le domaine visible de From.
Cet enregistrement demande des rapports sans restrictions DMARC :
Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.comVoici ses composants :
v=DMARC1identifie l’enregistrement comme DMARC.p=nonene demande ni quarantaine ni rejet au titre de DMARC ; les filtres locaux restent possibles.rua=mailto:dmarc@example.comdemande des rapports agrégés XML aux destinataires participants, sans garantir leur envoi.
C’est la base. Les autres balises ajustent le comportement demandé.
DMARC est une politique, pas une preuve de l’innocuité du contenu. SPF et DKIM authentifient certains domaines ; DMARC vérifie qu’un résultat réussi est aligné sur le domaine visible dans From.
5 exemples de politiques DMARC
Un seul exemple d’enregistrement DMARC ne convient pas à tous les cas. Le choix dépend de l’observation, des restrictions prévues, des sous-domaines et d’un éventuel besoin d’alignement strict. Les enregistrements suivants sont des alternatives, pas des politiques à publier ensemble.
Surveillance seule. Utile pour examiner les fournisseurs et les transferts en confrontant les rapports partiels à l’inventaire.
v=DMARC1; p=none; rua=mailto:dmarc@example.comDemander la quarantaine. Une option restrictive à évaluer après validation des expéditeurs légitimes.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comDemander le rejet. Pour une configuration vérifiée et des risques évalués ; le destinataire peut appliquer des exceptions locales.
v=DMARC1; p=reject; rua=mailto:dmarc@example.comDéploiement progressif. Le pourcentage demande un échantillonnage des messages en échec, pas de tous les messages, selon l’application du destinataire.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comSous-domaines et alignement strict. La politique héritée s’applique depuis le domaine organisationnel aux sous-domaines sans politique propre. L’alignement strict exige une correspondance exacte et peut affecter des flux autorisés.
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com
| Politique | Usage possible | Avantage attendu | Risque principal |
|---|---|---|---|
p=none | Observation initiale | Ne demande pas de restrictions DMARC | Ne demande pas le blocage de l’usurpation et ne garantit pas l’absence d’incidents |
p=quarantine | Flux professionnels déjà validés | Demande un traitement restrictif | Peut affecter des applications non alignées ; ni dossier spam ni récupération garantis |
p=reject | Production vérifiée | Demande le rejet des échecs DMARC | Une mauvaise configuration peut faire refuser du courrier légitime |
pct=25 | Restrictions progressives | Demande une application partielle aux messages en échec | L’échantillonnage n’est pas universellement respecté et ne garantit pas un impact réduit |
adkim=s; aspf=s | Besoin confirmé de correspondance exacte | Exige un alignement exact des domaines | Peut faire échouer des messages autorisés de tiers |
Cet exemple d’enregistrement DMARC est une option de quarantaine à évaluer après les tests des flux légitimes, pas la politique initiale la plus sûre pour tous les domaines :
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comIl demande déjà des restrictions, sans demander le rejet direct. Son application et la récupération des messages dépendent du destinataire.
Publier un enregistrement DMARC dans le DNS
Pour publier un exemple d’enregistrement DMARC, créez une seule politique TXT sur _dmarc, adaptez la valeur et vérifiez la réponse DNS. Les erreurs courantes sont la publication à la racine au lieu de _dmarc et la création de plusieurs politiques DMARC.
Si vous avez retenu la quarantaine, voici le format de l’exemple ; le TTL ne garantit pas la fin de la propagation :
Host: _dmarc
Type: TXT
TTL: 3600
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comVérifiez la publication :
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comUne seule politique DMARC valide doit apparaître, commençant par v=DMARC1. Plusieurs chaînes TXT peuvent constituer un même enregistrement ; d’autres TXT ne sont pas nécessairement des politiques DMARC.
Selon RFC 7489, aucune politique valide n’est appliquée à cette recherche si aucune politique n’existe ou si plusieurs politiques DMARC sont trouvées. Vérifiez aussi le format de l’interface : certaines attendent seulement _dmarc, d’autres le nom complet. Le domaine peut être ajouté automatiquement.
Pour l’ensemble du DNS, la documentation TrekMail sur les enregistrements DNS requis couvre MX, SPF, DKIM et DMARC.
Les erreurs courantes des enregistrements DMARC
Un exemple d’enregistrement DMARC mal adapté peut échouer à cause du nom, de plusieurs politiques, d’une destination de rapports incorrecte ou d’un alignement strict non testé. Un échec SPF après transfert est aussi souvent confondu avec un échec DMARC. Examinez la configuration et les messages réels.
Vérifiez notamment ces points :
- Publier à la racine. Le nom de recherche est
_dmarc, pas@. - Créer plusieurs politiques DMARC TXT. Conservez une seule politique par nom de recherche.
- Utiliser
p=rejectsans valider l’inventaire. Un CRM ou un outil de facturation oublié peut voir ses messages refusés. - Attribuer tous les échecs de transfert à DMARC. SPF peut échouer ; DKIM permet à DMARC de réussir s’il reste valide et aligné et si les données signées sont préservées après canonicalisation. Consultez le transfert du courrier d’un domaine vers Gmail et le transfert avec des alias e-mail. ARC peut éclairer une exception locale, mais ne constitue pas à lui seul un résultat DMARC réussi.
- Ignorer l’alignement. SPF réussi ne suffit pas s’il n’est pas aligné et que DKIM ne fournit pas non plus de résultat valide et aligné. Si DKIM le fournit, DMARC réussit.
- Ne pas demander de rapports. Sans
rua, aucun rapport agrégé n’est demandé ; les autres diagnostics restent utiles. Surveillez accès, confidentialité et autorisation DNS de la destination externe si nécessaire.
Les consignes Google citées décrivent des exigences dont l’absence peut entraîner des restrictions vers Gmail, selon l’expéditeur et la règle applicable. Consultez la FAQ officielle des consignes d’envoi. Tous les critères ne s’appliquent pas de manière identique à tous les volumes.
Choisir un enregistrement DMARC pour TrekMail
Le bon exemple d’enregistrement DMARC dépend de votre envoi. Le SMTP géré d’un plan payant peut faciliter la configuration, mais exige les DNS indiqués et des tests réels. Avec votre propre SMTP, autorisez le fournisseur dans le SPF du domaine d’enveloppe utilisé, puis vérifiez DKIM et l’alignement.
Voici des options de coordination :
| Configuration | Gestion séparée | Gestion avec TrekMail |
|---|---|---|
| Envoi géré | Coordonner l’hébergement des boîtes et un autre fournisseur SMTP | Utiliser le SMTP géré du plan concerné, publier les DNS et vérifier l’alignement |
| SMTP externe | Choisir des enregistrements sans vérifier le service sortant | Séparer les boîtes et configurer précisément SPF et DKIM pour le fournisseur réel |
| Plusieurs domaines | Modifier chaque domaine sans suivi commun | Standardiser des configurations adaptées et examiner chaque domaine |
La documentation du SMTP géré TrekMail décrit l’envoi inclus dans les plans payants concernés. Publiez les enregistrements et testez l’authentification alignée. Avec votre propre SMTP, SPF autorise le fournisseur externe dans le domaine utilisé et DMARC peut dépendre de DKIM si SPF ne réussit pas avec alignement. Respectez le plafond SPF des mécanismes et modificateurs déclenchant des recherches DNS, évaluations imbriquées comprises.
L’hébergement des boîtes et l’envoi peuvent être distincts. Si votre application utilise SES, SendGrid ou Mailgun, un exemple d’enregistrement DMARC valide ne prévient pas l’échec si aucun mécanisme ne réussit avec alignement chez ce fournisseur.
Pour les utilisateurs de TrekMail :
- Évaluez le SMTP géré d’un plan payant s’il convient à vos besoins, puis vérifiez sa configuration.
- Avec un SMTP externe, coordonnez SPF, DKIM et DMARC dans un même changement.
- Avec de nombreux domaines, organisez les destinations des rapports et adaptez les étapes à chacun.
L’offre décrite présente Starter à partir de $3.50 par mois, un essai gratuit de 14 jours sur les plans payants soumis à conditions et Nano sans frais ni carte selon l’offre actuelle. Vérifiez les tarifs, exigences et fonctionnalités sur la page des tarifs TrekMail. Le stockage mutualisé et la migration IMAP dépendent du plan ; copier les messages ne remplace pas le changement des MX et ne migre pas toutes les applications.
Déploiement progressif de DMARC en 2026
Le déploiement d’un exemple d’enregistrement DMARC en 2026 doit suivre les expéditeurs réels et les risques. Commencez par observer, validez les services, puis évaluez les restrictions. Passer directement au rejet peut révéler des systèmes oubliés alors que le courrier de production est déjà affecté.
- Publiez d’abord une politique de surveillance.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - Examinez les rapports pendant 7 à 14 jours comme première observation, pas comme garantie de préparation. Confrontez facturation, CRM, assistance et transferts aux inventaires, journaux et tests ; les flux trimestriels ou exceptionnels peuvent demander plus de temps.
- Corrigez SPF, DKIM et au moins un résultat valide et aligné par expéditeur. Si un fournisseur ne permet pas l’alignement, envisagez son remplacement ou la séparation de ses envois avec une configuration planifiée.
- Envisagez la quarantaine après les tests.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - Envisagez le rejet lorsque rapports, tests et évaluation des risques le justifient.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Pour les agences et les portefeuilles clients, un processus progressif peut faciliter la coordination. TrekMail propose gestion multidomaine, tarifs par plan, stockage mutualisé et copie IMAP selon l’offre ; cela ne remplace pas la validation individuelle et ne garantit pas une migration sans incident.
Le meilleur exemple d’enregistrement DMARC correspond à vos expéditeurs et aux restrictions que vous pouvez appliquer. Examinez les rapports partiels, testez l’authentification alignée, puis évaluez quarantaine ou rejet. Cela peut réduire l’usurpation directe, sans garantir le blocage de toute fraude ni la remise en boîte de réception.
TrekMail peut réunir boîtes, conseils DNS, SMTP géré ou externe et gestion multidomaine selon le plan. Consultez trekmail.net et comparez limites et coûts : centraliser ne garantit pas d’économies face à une facturation par utilisateur et ne supprime pas le travail d’exploitation.
