Une politique DMARC reject demande le rejet des messages qui échouent à DMARC. Avec p=none, vous demandez des rapports sans restriction, mais leur envoi n'est pas garanti ; quarantine demande déjà une mesure d'application. Passer trop tôt à p=reject peut affecter factures, réinitialisations de mots de passe et support. Pour les bases, commencez par la messagerie professionnelle.
Surveiller sans inventorier les expéditeurs laisse des problèmes ; durcir une politique DMARC reject sans tests crée aussi des risques. Ce guide rassemble prérequis, transition indicative et échecs pertinents en 2025 et 2026.
| Prérequis | Objectif | Pourquoi vérifier avant reject |
|---|---|---|
| Observation du trafic | 30 jours comme repère initial | Examiner les cycles mensuels et prolonger pour les flux rares ou trimestriels |
| Audit d'alignement | 100% des expéditeurs légitimes alignés comme objectif | SPF ou DKIM valide sans alignement ne suffit pas à DMARC |
| Réputation | Taux de spam inférieur à 0.1% selon les recommandations du destinataire | Réputation et erreurs DMARC peuvent coexister |
| Transferts | DKIM valide et aligné conservé | SPF peut échouer sur les routes indirectes |
| Sous-domaines | Champ sp vérifié | L'héritage peut affecter développement et anciens sous-domaines |
Ce que fait réellement reject
Une politique DMARC reject demande au destinataire de rejeter les messages lorsque ni SPF ni DKIM ne réussit avec l'alignement exigé pour votre domaine. Elle peut réduire certaines usurpations lorsqu'elle est appliquée, sans garantir blocage ou boîte de réception.
L'alignement est essentiel : au moins une authentification valide doit s'aligner sur le domaine From visible selon le mode souple ou strict. Un indicateur SPF ou DKIM positif seul ne suffit pas.
Selon la RFC 7489, les destinataires peuvent tenir compte de pct et appliquer leur jugement local. Une politique DMARC reject ne corrige ni réputation, ni contenu, ni configuration d'envoi.
Prérequis 1 : observer 30 jours avant reject
Ne fondez pas une politique DMARC reject sur une seule semaine favorable. Trente jours sont un repère pratique, pas une garantie : facturation mensuelle, rapports trimestriels et automatisations rares demandent tests ou observation prolongée.
Examiner sept jours, publier p=reject, puis découvrir des factures rejetées est un risque à réduire par inventaire et tests de chaque cycle.
Exemple : la facturation n'envoie qu'au début du mois. Elle s'authentifie sur le domaine du prestataire, sans alignement sur le vôtre. Avec
p=none, l'échec peut passer inaperçu ; avecp=reject, les factures pourraient être rejetées.
Recherchez les expéditeurs rares mais importants : facturation, RH, scanners, formulaires et support. La politique DMARC reject doit être évaluée après leur identification, pas remplacer l'inventaire.
Contrôlez le DNS avant d'interpréter les rapports. Le guide des enregistrements DNS requis TrekMail décrit SPF, DKIM, MX et DMARC selon le mode de service.
Prérequis 2 : auditer alignement et authentification
Avant une politique DMARC reject, vérifiez SPF ou DKIM valide et aligné chez chaque expéditeur légitime. Un service peut s'authentifier correctement sur son domaine sans alignement avec votre From.
Exemple SaaS courant :
From visible :
support@yourcompany.com
Return-Path :bounce.vendor-mail.com, avec SPF valide
DKIM :d=vendor-mail.com, avec DKIM valide
Résultat : DMARC échoue pouryourcompany.com
Le tableau de bord du prestataire peut montrer une authentification valide sans alignement de votre domaine. Une politique DMARC reject peut affecter ces messages.
Corrections habituelles :
- Publier les enregistrements DKIM et configurer la signature avec votre domaine.
- Configurer un domaine de retour personnalisé pour l'alignement SPF.
- Tester de vrais messages et lire les en-têtes.
Surveillez SPF : la limite concerne dix mécanismes ou modificateurs évalués déclenchant des recherches DNS, pas toutes les requêtes réseau. Plusieurs TXT SPF produisent une erreur permanente. Le guide de configuration du domaine explique les SPF dupliqués.
Prérequis 3 : vérifier la réputation
Une politique DMARC reject peut limiter une partie de l'usurpation, sans améliorer à elle seule la réputation. Des messages authentiques peuvent aussi recevoir des plaintes, être filtrés ou rejetés pour d'autres raisons.
Les consignes Google citées recommandent aux expéditeurs en masse un taux inférieur à 0.1% et d'éviter 0.3% ou plus, pouvant affecter les mesures de mitigation. Yahoo cite également 0.3% comme plafond. Vérifiez les exigences actuelles et la définition de ces métriques.
Si Postmaster indique 0.18%, examinez listes et pertinence. Cela n'exclut pas un problème DMARC simultané ; contrôlez les deux avant de modifier la politique.
Avant une politique DMARC reject, vérifiez :
- Le taux de spam Google Postmaster Tools du domaine d'envoi.
- Les pics de plaintes liés à des campagnes, des listes ou des outils.
- Les rejets suggérant des données anciennes ou des adresses fonctionnelles.
- La réputation partagée entre transactionnel et marketing.
Références : FAQ des consignes Google et bonnes pratiques Yahoo.
Prérequis 4 : tester les transferts avec reject
Avant une politique DMARC reject, testez les transferts. SPF peut échouer car le serveur intermédiaire n'est pas autorisé par le domaine original. DKIM valide et aligné peut permettre DMARC si les données signées sont conservées.
Un échec SPF dans un rapport ne prouve pas l'usurpation. Si DKIM réussit avec alignement, DMARC réussit, mais listes et passerelles peuvent modifier les données signées et l'invalider.
Vérifiez canonicalisation et signature des flux importants avant la politique DMARC reject. SRS peut aider SPF pour la nouvelle enveloppe sans forcément rétablir l'alignement original ; ARC dépend du destinataire.
La documentation TrekMail décrit SPF en échec et DKIM valide après transfert, et l'envoi géré disponible selon l'offre. Vérifiez la signature du domaine sur de vrais messages. Consultez le transfert de messages pour examiner les modifications.
Consultez aussi Mes messages arrivent dans les indésirables et les paramètres IMAP et SMTP. L'authentification alignée ne garantit pas la remise, et le SMTP sortant dépend de l'offre.
Prérequis 5 : vérifier les sous-domaines avant reject
Une politique DMARC reject du domaine organisationnel peut être héritée par dev.example.com ou alerts.example.com en l'absence de politique propre. Examinez sp et les enregistrements spécifiques avant les restrictions.
Inventoriez développement, imprimantes, scanners et anciens outils. Une production correcte ne prouve pas que ces parcours soient prêts.
Cet exemple utilise sp pour différencier l'héritage :
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.comIl demande reject pour le domaine principal et none pour les sous-domaines héritant de cet enregistrement, pas ceux ayant leur propre politique. Évaluez ensuite leur durcissement.
Les rapports peuvent révéler des CRM ou relais oubliés, mais leur couverture reste partielle et une source inconnue ne prouve pas un abus. La politique DMARC reject demande un inventaire indépendant.
Déployer reject par étapes
Évaluez une politique DMARC reject après tests et observation. Quarantine demande déjà une restriction ; pct demande une application partielle selon le destinataire, sans garantir la transition.
Exemple indicatif :
- Demander quarantine à 10% pendant une semaine avec une réponse aux incidents prévue.
- Envisager quarantine à 100% pendant une à deux semaines supplémentaires, puis prolonger selon les cycles.
- Envisager reject après tests du support, de la facturation, de l'authentification et des transferts.
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.comv=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comCes enregistrements sont des alternatives successives : n'en publiez qu'un. Quarantine ne garantit pas une récupération ; reject peut produire des retours et, selon l'erreur, des tentatives ultérieures. Une politique DMARC reject peut faire rejeter un message légitime avant qu'il n'atteigne la boîte aux lettres.
Gérer reject sur plusieurs domaines
Une politique DMARC reject demande davantage de coordination avec dix, cinquante ou cinq cents domaines. Chaque prestataire a sa configuration DKIM et chaque domaine son inventaire à maintenir.
Approche dispersée : examiner manuellement le XML, rechercher les IP, corriger domaine par domaine et dépendre d'avis informels sur les expéditeurs.
Approche coordonnée : centraliser les domaines, documenter le DNS et maintenir des tests reproductibles.
TrekMail annonce des offres payantes dès $3.50 par mois avec SMTP géré selon les conditions et une interface pour gérer les domaines, les boîtes IMAP, les transferts et le DNS. Nano est proposé gratuitement jusqu'à 10 domaines avec votre propre SMTP. Consultez l'hébergement multidomaine et les fonctions actuelles.
La coordination peut réduire des tâches répétitives, sans garantir économies ou baisse d'incidents. Gardez des procédures d'actualisation des expéditeurs avant une politique DMARC reject.
Consultez les enregistrements DNS requis et trekmail.net/pricing. Les offres payantes peuvent inclure un essai de 14 jours avec carte requise ; Nano est proposé sans carte selon les conditions actuelles.
Conclusion : quand publier reject
Pour évaluer une politique DMARC reject, observez au moins 30 jours comme repère et prolongez pour les cycles rares, vérifiez authentification alignée, plaintes, transferts et héritage des sous-domaines. Aucun indicateur isolé ne prouve une préparation complète.
Inventoriez les expéditeurs, lisez les en-têtes et corrigez DNS et routes avant la politique DMARC reject. Continuez ensuite la surveillance : elle peut aider contre l'usurpation sans couvrir tous les abus.
Pour coordonner l'infrastructure, consultez TrekMail ou comparez les offres sur trekmail.net/pricing.
