Politique DMARC : choisir none, quarantine ou reject

Une politique DMARC indique au destinataire le traitement demandé pour les messages utilisant votre domaine qui échouent à DMARC. Elle peut aider contre l'usurpation, mais le destinataire conserve ses règles locales. Une application prématurée risque aussi d'affecter factures, réponses du support ou transferts légitimes. Pour les bases de l'installation, commencez par la messagerie professionnelle.

Le problème vient souvent d'un inventaire incomplet : conserver p=none sans analyser les rapports, ou passer à p=reject avant de vérifier l'authentification et l'alignement de chaque service. Des messages valides peuvent alors être affectés.

Une démarche courante utilise p=none pour observer les expéditeurs, envisage p=quarantine après correction de l'authentification alignée, puis p=reject après analyse des échecs restants. Un échec n'est pas forcément une usurpation et aucun calendrier ne convient à tous les domaines.

Qu'est-ce qu'une politique DMARC ?

La politique demande une action pour les messages utilisant votre domaine qui échouent à DMARC. Les options sont none, quarantine et reject. Le choix dépend notamment de l'authentification valide et alignée des expéditeurs légitimes.

Le destinataire contrôle SPF, DKIM et leur alignement sur le From visible. Pour réussir DMARC, au moins l'un doit réussir son authentification et être aligné.

Si SPF réussit et est aligné, DMARC réussit.

Si DKIM réussit et est aligné, DMARC réussit.

Si aucun ne fournit une authentification valide et alignée, la politique demandée est évaluée.

Quelle politique DMARC choisir au départ ?

Commencez par p=none si vous n'avez pas vérifié l'authentification alignée de tous les expéditeurs. Le trafic réel aide à mesurer les risques avant de demander un traitement plus restrictif.

Voici un enregistrement initial de surveillance :

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Ce mode ne demande pas de blocage contre l'usurpation et ne garantit pas la remise. Il peut apporter de la visibilité lorsque les destinataires participants envoient des rapports, sans forcément couvrir tout le trafic.

Expéditeurs souvent oubliés :

1. Logiciels comptables envoyant des factures.
2. Outils RH et de recrutement.
3. Plateformes CRM et marketing.
4. Outils de support répondant avec le domaine principal.
5. Règles personnelles de transfert affectant SPF au prochain relais.

Sans observer ces parcours, une politique restrictive peut toucher de vrais processus métier. Un TXT publié ne signifie pas que tous les expéditeurs ont été identifiés.

Pour les expéditeurs en masse, publier DMARC fait partie des exigences de certains destinataires, notamment Google. Vérifiez les conditions d'authentification et d'alignement applicables. Le standard est décrit dans la RFC 7489.

Combien de temps conserver none ?

Conserver none pendant deux à quatre semaines peut servir de repère initial, sans garantir l'observation des flux mensuels, trimestriels ou exceptionnels. Adaptez la surveillance aux cycles réels de votre organisation.

Trois jours donnent souvent trop peu d'informations : factures mensuelles, communications trimestrielles et anciennes applications de réinitialisation des mots de passe peuvent rester invisibles.

La surveillance devrait couvrir :

1. Courrier professionnel habituel.
2. Campagnes marketing.
3. Cycles de facturation.
4. Escalades du support.
5. Messages transférés.
6. Automatisations de tiers.

Comparez les rapports agrégés à votre inventaire : systèmes légitimes à corriger, usurpations probables et échecs encore inexpliqués. Les rapports ne permettent pas toujours d'établir la cause à eux seuls.

Exemple : la plateforme de newsletter signe avec son propre domaine et SPF réussit aussi pour un domaine non aligné. DMARC échoue malgré une authentification valide. Avant de demander le rejet, corrigez l'alignement de cet expéditeur légitime.

Dans TrekMail, le parcours DNS peut aider à contrôler les enregistrements indiqués et leur vérification selon le mode d'envoi. Consultez ajouter un domaine et les enregistrements DNS requis. Ces contrôles ne remplacent pas l'inventaire des services externes.

Pourquoi le transfert complique-t-il DMARC ?

Le transfert peut faire échouer SPF parce que le serveur d'envoi change. Une signature DKIM valide et alignée permet souvent à DMARC de réussir si les données signées sont conservées. Vérifiez DKIM sans supposer que tous les transferts le préservent.

La distinction entre identités d'expéditeur est essentielle.

L'utilisateur voit From ; le serveur utilise un expéditeur d'enveloppe pour les notifications d'échec. SPF contrôle cette identité et l'IP d'envoi. DMARC vérifie si un résultat SPF valide s'aligne sur le From visible.

Lors d'un transfert, l'IP change et peut ne plus être autorisée par le SPF original. DKIM peut rester valide si les données signées ne changent pas au-delà de ce que tolère sa canonicalisation.

Ces résultats peuvent donc coexister :

1. SPF échoue après transfert.
2. DMARC réussit parce que DKIM réussit et est aligné.

Avant de demander un traitement restrictif, testez les transferts importants et les signatures alignées des expéditeurs. Consultez transférer la messagerie d'un domaine vers Gmail et, pour les incidents de routage, le transfert de messages.

ARC transporte le contexte d'authentification entre intermédiaires et listes. Il ne remplace pas votre alignement et ne garantit pas l'acceptation du destinataire. Le protocole est décrit dans la RFC 8617.

Quand passer à quarantine ?

Envisagez quarantine après avoir vérifié que les expéditeurs légitimes réussissent SPF ou DKIM avec alignement. Cette politique demande de considérer les échecs comme suspects ; le destinataire peut appliquer ses exceptions ou d'autres mesures.

L'enregistrement est :

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

Un expéditeur oublié pourrait aboutir dans les indésirables et révéler le problème, mais il ne faut pas compter sur la conservation systématique des messages ni sur leur détection par les utilisateurs.

Pour traiter un incident :

1. Recevoir et vérifier le signalement d'un message absent.
2. Examiner l'expéditeur et son alignement.
3. Corriger SPF, DKIM ou les deux selon la cause.
4. Tester à nouveau avant d'envisager reject.

Certains utilisent pct=25 ou pct=50 pour demander une application partielle. Les destinataires ne respectent pas tous ce pourcentage de la même façon. Même 100% reste une demande, pas une garantie de couverture. Avancez selon les risques et les observations, pas seulement le pourcentage.

Avec un plan TrekMail incluant le SMTP géré, vérifiez que les signatures sont valides et alignées sur votre domaine. Lors d'un transfert, SPF peut échouer et DKIM réussir ; consultez mes messages arrivent dans les indésirables pour le diagnostic.

Quand passer à reject ?

Envisagez reject après résolution des échecs légitimes et analyse des causes inconnues. La politique demande le rejet des messages qui échouent à DMARC, mais les destinataires peuvent conserver leurs exceptions locales.

L'enregistrement est simple :

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

C'est un objectif courant lorsque le trafic légitime du domaine a été vérifié.

Cette politique peut être utile car :

1. Elle complique certaines usurpations directes du domaine lorsque le destinataire l'applique.
2. Elle peut réduire une partie des risques de phishing et de fraude professionnelle.
3. Elle communique aux destinataires le traitement demandé pour les échecs.
4. Elle participe à la protection de la marque, sans couvrir toutes les tromperies.

Google décrit des limitations et rejets liés à l'authentification et à l'alignement, avec des codes comme 4.7.31 et 4.7.32. Certains retours mentionnent 5.7.26 et la politique du domaine. Consultez la FAQ des consignes Google pour les expéditeurs pour le contexte actuel.

Attention : si la comptabilité utilise encore un service sans authentification alignée, ses factures pourraient être rejetées. Vérifiez ce flux avant de durcir la politique.

Quel enregistrement DMARC publier ?

Publiez un seul TXT de politique sous _dmarc.yourdomain.com. Même bref, sa configuration influence le traitement demandé pour les messages du domaine.

Ces exemples sont des alternatives ; ne les publiez pas tous ensemble :

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Avec TrekMail, examinez MX, SPF, DKIM et DMARC selon votre configuration réelle. Le modèle suivant est illustratif : quarantine n'est pas une recommandation d'appliquer des restrictions avant l'inventaire des expéditeurs.

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

Ne publiez pas plusieurs SPF et n'inventez pas de clé DKIM. Examinez les MX existants avant de les changer. Avec votre propre service d'envoi, SPF et DKIM doivent correspondre à ce service, pas forcément à l'exemple. Consultez SMTP personnalisé (BYO) et vérifiez l'alignement.

Quelles erreurs DMARC éviter ?

Les erreurs fréquentes comprennent p=none sans analyse, une application trop tôt, une dépendance exclusive à SPF et l'oubli des sous-domaines. Elles peuvent laisser une protection incomplète ou affecter des messages légitimes.

Vérifiez ces points :

1. Conserver none pendant des mois sans plan de suivi : aucun blocage n'est demandé et les rapports dépendent des participants.
2. Ignorer l'alignement DKIM parce que SPF réussit : les transferts peuvent exposer cette dépendance.
3. Oublier l'héritage des sous-domaines ; utilisez sp= pour une politique différente.
4. Dépasser la limite SPF de 10 termes évalués déclenchant des recherches DNS peut produire PermError ; ce n'est pas le simple nombre de requêtes réseau.
5. Faire confiance à un service utilisant votre domaine sans vérifier son authentification et ses signatures.

Un exemple pour les sous-domaines :

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

Il demande reject pour le domaine principal et none pour les sous-domaines qui héritent de cette politique. Il ne vise pas un seul sous-domaine ; leurs enregistrements spécifiques peuvent modifier le comportement.

Comment TrekMail aide à configurer DMARC

TrekMail peut coordonner domaines, stockage et contrôles DNS selon l'offre. Cela réduit le travail entre outils, mais la politique exige toujours de connaître les expéditeurs externes et leurs résultats réels.

À titre indicatif, Starter est annoncé à partir de $3.50 par mois avec SMTP géré selon ses conditions. Nano est proposé gratuitement avec votre propre SMTP. TrekMail utilise IMAP et propose domaines personnalisés, catch-all, transfert, migration et API selon l'offre et la configuration ; vérifiez les conditions actuelles.

Pour DMARC, publier le TXT ne suffit pas : il faut maîtriser et vérifier les systèmes qui envoient avec votre domaine.

Selon la configuration disponible, vous pouvez :

1. Gérer plusieurs domaines depuis un tableau de bord.
2. Vérifier les enregistrements DNS avant l'activation.
3. Utiliser le SMTP géré des offres concernées ou configurer SES/SendGrid avec Nano.
4. Séparer l'hébergement des boîtes du choix du service sortant.
5. Importer les anciens messages par une migration IMAP compatible.

Pour l'installation complète, consultez configurer la messagerie de mon domaine. Pour plusieurs marques ou clients, l'hébergement de messagerie multidomaine décrit le modèle d'exploitation.

Conclusion : avancer de none à reject avec des preuves

Une démarche courante commence par none, corrige l'authentification et l'alignement, évalue quarantine, puis reject. Chaque étape doit s'appuyer sur des tests et des observations.

En bref :

1. Utilisez p=none pendant 2 à 4 semaines comme repère initial, puis prolongez pour couvrir vos cycles.
2. Configurez SPF ou DKIM valides et alignés pour chaque expéditeur légitime ; vérifiez DKIM pour les transferts.
3. Envisagez p=quarantine pour demander un traitement intermédiaire.
4. Envisagez p=reject après résolution des échecs légitimes et analyse des autres.

Cette démarche peut réduire l'usurpation tout en surveillant le courrier légitime, sans garantir la remise ni une protection totale. Pour coordonner boîtes, transferts et migrations selon vos besoins, consultez les documents TrekMail ou comparez les offres sur https://trekmail.net/pricing.