Un échec DMARC signifie que le message n’a pas obtenu de résultat d’authentification valide et aligné sur le domaine de From. p=reject demande le rejet ; p=quarantine demande un traitement restrictif. Le destinataire peut appliquer des exceptions locales et aucun dossier spam précis n’est garanti. Examinez la configuration, sans exclure des problèmes de réputation concomitants. Pour le contexte général, consultez le courrier professionnel pour les petites entreprises.
De nombreux cas concernent l’alignement, un transfert faisant échouer SPF, un flux sans DKIM ou un SPF dépassant son plafond d’évaluation DNS. Lisez les en-têtes, comparez les domaines et identifiez le mécanisme qui ne fournit pas de résultat valide et aligné.
Ce guide propose un tableau de diagnostic, une démarche d’examen et des exemples DNS à adapter et vérifier, sans promettre une solution définitive pour tous les cas.
Que signifie réellement un échec DMARC ?
DMARC échoue si aucun mécanisme ne fournit de résultat d’authentification valide et aligné. SPF ou DKIM peut réussir pour un autre domaine ; si aucun ne réussit avec alignement sur From, DMARC échoue.
La spécification exige que SPF ou DKIM réussisse et que le domaine authentifié soit aligné sur le domaine RFC5322 de From. Consultez RFC 7489.
| Situation | SPF | DKIM | DMARC | Interprétation | Vérifications |
|---|---|---|---|---|---|
| Les deux mécanismes échouent | Fail | Fail | Fail | Configuration erronée, transfert ou expéditeur non autorisé possibles ; ce n’est pas une preuve d’abus | Confronter expéditeur, IP, DNS et signature à l’inventaire et aux journaux |
| Authentification sans alignement | Pass, non aligné | Pass, non aligné | Fail | L’authentification réussit, mais pas avec alignement sur From | Configurer et vérifier Return-Path personnalisé et DKIM aligné |
| Message transféré | Fail | Pass, aligné | Pass | Comportement de transfert potentiellement attendu | Vérifier signature valide et alignée et préservation des données signées après canonicalisation |
| Transfert avec modification | Fail | Fail | Fail | Une liste ou un relais peut avoir modifié les données signées ; examiner la cause | Évaluer le flux et les exceptions locales ; ARC peut éclairer le destinataire, pas transformer l’échec en authentification réussie |
| SPF PermError | PermError | Fail ou absent | Fail | Plafond d’évaluation SPF dépassé ou syntaxe incorrecte possibles | Auditer SPF ; répartir les fournisseurs exige l’utilisation réelle des nouveaux domaines d’enveloppe |
Étape 1 : vérifier d’abord l’alignement
De nombreux échecs sur des messages légitimes viennent de l’alignement : le fournisseur authentifie son domaine plutôt que le vôtre. Le domaine qui réussit compte autant que la réussite elle-même.
Exemple :
From d’en-tête :
support@yourdomain.com
Return-Path:bounces.vendor.net
DKIM:d=vendor.net
Le message peut afficher spf=pass et dkim=pass tout en échouant à DMARC, car vendor.net n’est pas aligné sur yourdomain.com.
C’est fréquent avec le marketing, les CRM, l’assistance et les SMTP de secours. Vérifiez si le fournisseur permet l’authentification du domaine, un Return-Path et un domaine de rebond personnalisés ou une signature DKIM avec votre domaine. Un domaine de suivi ou de personnalisation des liens ne remplace pas un Return-Path personnalisé.
Ces changements DNS sont illustratifs ; utilisez les valeurs du fournisseur réel, puis activez et testez ses fonctions :
Type: CNAME
Host: bounces
Value: yourvendor.example.net
Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net
Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.netTrekMail propose un processus DNS selon le service choisi. Consultez l’ajout d’un domaine et les enregistrements DNS requis. Si SPF existe déjà, réunissez les autorisations valides dans un seul enregistrement par domaine d’enveloppe réel, sans ajouter un second SPF. L’interface ne prouve pas l’authentification de tous les flux.
Étape 2 : examiner les en-têtes originaux
Ouvrez la source du message et identifiez Authentication-Results, Return-Path et les domaines DKIM d=. Fiez-vous uniquement aux résultats produits par le destinataire qui évalue le message ; l’expéditeur peut ajouter de faux en-têtes.
Suivez cette liste :
- Identifiez le domaine visible de From.
- Vérifiez si SPF a réussi.
- Vérifiez pour quel domaine SPF a réussi.
- Vérifiez si DKIM a réussi.
- Identifiez le domaine signataire réel de DKIM.
- Comparez les deux à From.
Voici un exemple d’en-tête avec un échec DMARC :
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net header.s=s1;
spf=pass smtp.mailfrom=bounces.sendgrid.net;
dmarc=fail (p=reject) header.from=yourdomain.comInterprétez-le avec attention :
SPF a réussi pour bounces.sendgrid.net, qui partage le domaine organisationnel sendgrid.net. L’identité DKIM indiquée appartient à sendgrid.net, mais header.i ne remplace pas le domaine d= de la signature : vérifiez celui-ci. From utilise yourdomain.com. Le résultat du destinataire indique qu’aucun mécanisme n’a fourni d’authentification alignée.
Répétez la vérification pour chaque flux. Le courrier transactionnel peut être corrigé alors que marketing, assistance ou alias transférés échouent encore. Consultez aussi la configuration des e-mails sur votre domaine.
Étape 3 : examiner le transfert séparément
Le transfert peut faire échouer SPF : le relais envoie depuis une autre IP qui peut ne pas être autorisée par le domaine réel de MAIL FROM. DMARC réussit encore si DKIM reste valide et aligné et si les données signées sont préservées après canonicalisation.
Un échec SPF dans Google Groups, Outlook ou des relais universitaires ne raconte pas toute l’histoire. Si DKIM réussit avec alignement, DMARC réussit. Cela ne garantit ni un contenu sûr ni la remise en boîte de réception.
RFC 7960 explique que conserver l’expéditeur d’enveloppe original peut faire échouer SPF ; le réécrire, par exemple avec SRS, ne rétablit pas l’alignement sur le From original. DKIM peut fournir le résultat aligné, mais ne résiste pas à toutes les routes. Consultez RFC 7960.
N’ajoutez pas indistinctement des autorisations SPF pour tenter de réparer tous les transferts. Vérifiez plutôt :
- Signer avec DKIM les flux sortants compatibles et vérifier leur alignement.
- Évaluer le mode souple, qui compare le domaine organisationnel ; le mode strict demande un besoin précis et des tests.
- Examiner les listes modifiant les données signées, qui peuvent faire échouer DKIM et, sans autre résultat aligné, DMARC.
Si vous dépendez du transfert, consultez la configuration du transfert des e-mails et le transfert du courrier d’un domaine vers Gmail. TrekMail propose transfert et choix SMTP selon le plan, sans garantir la conservation de DKIM ni la remise à travers tous les intermédiaires.
Étape 4 : auditer SPF et les erreurs permanentes
SPF PermError peut apparaître si le plafond de dix mécanismes ou modificateurs déclenchant des recherches DNS est dépassé, évaluations imbriquées comprises, ou si la syntaxe ou des inclusions sont invalides. Ce n’est pas une limite du total des paquets DNS. Un résultat permanent inutilisable ne fournit pas de SPF valide et aligné à DMARC.
Un SPF contenant de nombreuses inclusions peut ressembler à ceci :
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~allSon apparence ne détermine pas sa validité. Évaluez inclusions imbriquées et redirections selon les règles SPF ; compter les seules requêtes visibles ne suffit pas.
Interrogez les enregistrements avec ces outils :
dig +short txt yourdomain.com
nslookup -type=txt yourdomain.comCes recherches ne prouvent pas à elles seules un PermError. Auditez les services actifs. Si une plateforme n’est plus utilisée depuis six mois, retirez son autorisation uniquement après confirmation qu’elle est inutile. Vous pouvez envisager de répartir les fournisseurs par sous-domaines :
marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.comChaque domaine peut avoir sa propre évaluation SPF si le fournisseur l’utilise réellement dans MAIL FROM. Créer le sous-domaine ne modifie pas l’envoi : activez la configuration, puis testez SPF, DKIM et l’alignement sur From avant de déplacer le flux.
La documentation TrekMail explique comment éviter les doublons SPF et réunir les autorisations dans un TXT valide. Consultez la vérification de l’état DNS.
Étape 5 : distinguer erreurs et usurpations possibles
Tous les échecs DMARC ne justifient pas d’autoriser une nouvelle source. Certains correspondent à des usurpations, d’autres à des expéditeurs légitimes mal configurés ou à des transferts. Le résultat d’authentification ne suffit pas pour trancher.
Si SPF et DKIM échouent depuis une IP inconnue, ne l’autorisez ni ne la bloquez automatiquement. Confrontez inventaire, journaux et routes de transfert. p=quarantine et p=reject demandent des restrictions, dont l’application dépend du destinataire et des exceptions locales possibles.
Suivez cette démarche :
- Examinez l’IP ou le fournisseur inconnu avant de conclure à un abus.
- Pour un expéditeur autorisé, identifiez la plateforme et vérifiez son authentification de domaine.
- Si DKIM manque sur une plateforme compatible, configurez-le et vérifiez signature et alignement.
- Si aucun mécanisme ne peut réussir avec alignement, évaluez un changement de fournisseur ou une séparation du flux avec configuration active et tests, pas seulement de nouveaux DNS.
Les consignes Google citées expliquent l’application des politiques DMARC en cas d’échec d’authentification ou d’alignement, selon le cas et les règles locales. Vérifiez les exigences actuelles et leur portée dans les consignes d’authentification des expéditeurs de Google.
Les schémas d’échec selon l’expéditeur
Le type de système peut orienter l’examen, sans prouver automatiquement la cause. Vérifiez le flux et les résultats réels.
| Type d’expéditeur | Cause possible | Vérification ou correction |
|---|---|---|
| Marketing | DKIM ou domaine de rebond non aligné | Configurer et tester DKIM personnalisé et Return-Path propre |
| Assistance ou CRM | Domaines d’authentification fournisseur non alignés sur From | Terminer et vérifier l’authentification du domaine |
| Transfert de boîte | SPF échoue après le relais | Vérifier DKIM valide et aligné et la préservation des données signées |
| Liste de diffusion | Transfert et modifications du corps ou des en-têtes signés | Examiner les échecs ; ARC peut éclairer des exceptions locales, sans garantir la réussite de DMARC |
| Petite entreprise utilisant plusieurs services | Évaluation SPF excessive ou DNS incomplet | Réunir les autorisations et évaluer des domaines d’enveloppe séparés réellement utilisés |
| Agence gérant de nombreux domaines | Configurations DNS incohérentes | Standardiser le processus avec des valeurs adaptées et des tests par client |
Résoudre les échecs DMARC sur plusieurs domaines
Un client utilise Google Workspace, un autre cPanel, un autre SendGrid et un autre transfère vers Gmail. Sans documentation des DNS actuels, les échecs peuvent devenir récurrents.
Un processus commun peut aider : inventaire, liste DNS et plan de migration pour examiner domaines, transferts, SMTP et authentification. La centralisation ne remplace pas les tests par flux.
L’offre TrekMail décrite présente des plans payants à partir de $3.50 par mois, un essai gratuit de 14 jours soumis à conditions et un plan sans frais avec votre SMTP selon l’offre actuelle. Domaines personnalisés, boîtes IMAP, catch-all, transfert, copie IMAP, API et outils DNS dépendent du plan et de ses limites. Copier les messages ne remplace pas le changement des MX et ne migre pas toutes les applications ; ces fonctions ne garantissent ni économies ni baisse des incidents.
Pour de nombreux domaines clients, consultez l’hébergement de messagerie multidomaine et comparez ce processus à la gestion manuelle chez chaque bureau d’enregistrement.
Liste courte pour examiner un échec DMARC
Commencez par un message en échec, identifiez les domaines authentifiés, comparez-les à From et testez la correction correspondante. Répétez l’examen sur les autres flux, y compris ceux qui sont critiques et peu fréquents.
- Ouvrez le message et examinez
Authentication-Resultsdu destinataire fiable. - Vérifiez la réussite SPF et le domaine d’enveloppe réel concerné.
- Vérifiez la réussite DKIM et le domaine
d=. - Comparez les deux domaines à From visible.
- Si aucun ne réussit avec alignement, corrigez l’authentification et l’alignement nécessaires.
- En cas de transfert, vérifiez DKIM valide et aligné et la préservation des données signées.
- Si SPF dépasse son plafond, retirez les autorisations inutiles ou configurez et testez des domaines d’enveloppe séparés.
- Si les deux mécanismes échouent pour une source inconnue, examinez-la avant de la classer ou de modifier son traitement.
La démarche repose sur des résultats fiables, un inventaire et des tests, pas sur des suppositions.
Conclusion : identifier le mécanisme à l’origine de l’échec
Un échec DMARC peut apparaître à la remise en raison d’un défaut d’alignement, d’un transfert avec DKIM invalide, de SPF PermError ou d’une source non autorisée. Il faut distinguer ces cas sans supposer que tous les échecs sont abusifs ni qu’un résultat réussi garantit la sécurité.
Corrigez la configuration identifiée et vérifiez des messages réels plutôt que d’ajouter des DNS au hasard. TrekMail propose stockage mutualisé, gestion multidomaine, SMTP propre sur Nano, SMTP géré sur les plans compatibles et copie IMAP selon l’offre actuelle. Cela ne remplace pas la validation ni ne garantit une migration complète. Consultez TrekMail ou comparez les conditions sur https://trekmail.net/pricing.
