Corriger les erreurs DMARC : 8 causes de «dmarc=fail»

Comment le destinataire décide pour DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) repose sur deux contrôles. SPF vérifie si le serveur d'envoi est autorisé pour le domaine de l'expéditeur figurant dans l'enveloppe de l'e-mail. Cette adresse s'appelle Return-Path et n'est pas visible pour le destinataire. DKIM vérifie une signature numérique qu'un domaine donné appose sur l'e-mail.

DMARC n'est réussi que si au moins un des deux contrôles réussit et que son domaine correspond à l'adresse d'expéditeur visible (From). Cette correspondance s'appelle alignement. Par défaut, l'alignement souple s'applique : les domaines doivent seulement partager le même domaine principal. bounce.example.com est donc aligné avec example.com, newsletter.example.net ne l'est pas.

Trouver la cause dans l'en-tête de l'e-mail

Envoyez un e-mail de test vers une boîte externe et ouvrez les en-têtes complets. Dans Gmail, la commande s'appelle «Afficher l'original» ; dans Outlook, vous trouvez les en-têtes dans les propriétés du message. Cherchez la ligne Authentication-Results. Elle ressemble à ceci :

Authentication-Results: spf=pass smtp.mailfrom=bounce.newsletter.example.net;
 dkim=pass header.d=newsletter.example.net;
 dmarc=fail action=none header.from=example.com

Comparez trois domaines : header.from est votre domaine d'expéditeur visible. smtp.mailfrom est le domaine pour lequel SPF a été vérifié. header.d est le domaine de la signature DKIM. Si aucun des deux ne correspond à header.from, DMARC échoue, même si SPF et DKIM réussissent séparément.

Trouver la cause dans le rapport DMARC

Les rapports DMARC des destinataires montrent tous les e-mails envoyés avec votre domaine, regroupés par adresse IP d'envoi. Pour chaque source, vous voyez le résultat SPF et DKIM, les domaines contrôlés et le résultat DMARC. Cherchez les sources avec un volume notable où DMARC est en rouge. Comment lire les fichiers XML est expliqué dans le guide Lire un rapport DMARC : ce que contiennent les fichiers XML et quoi en faire

Erreur 1 : SPF et DKIM réussissent, mais pas pour votre domaine

Comment la reconnaître : l'en-tête ou le rapport indique spf=pass et dkim=pass, mais dmarc=fail. Les domaines de smtp.mailfrom et header.d appartiennent au prestataire, pas à vous. C'est l'erreur d'alignement DMARC classique.

Comment la corriger : faites en sorte qu'au moins un contrôle porte sur votre domaine. Le plus fiable est une signature DKIM avec d=example.com. De nombreux services proposent en plus leur propre domaine Return-Path, par exemple bounce.example.com via une entrée CNAME. SPF est alors aussi aligné.

Erreur 2 : systèmes tiers sans signature DKIM propre

Comment la reconnaître : vos e-mails principaux depuis Microsoft 365 ou Google Workspace passent, mais la newsletter, le CRM, le logiciel de comptabilité ou la boutique en ligne échouent. Le rapport montre des adresses IP inconnues avec dkim=none ou une signature du fournisseur.

Comment la corriger :

1. Dressez la liste de tous les systèmes qui envoient avec votre adresse, y compris imprimantes, système de tickets et formulaire de contact.
2. Cherchez dans chaque outil le réglage du domaine d'expéditeur. Il s'appelle souvent «authentifier le domaine» ou similaire.
3. Saisissez les entrées DKIM affichées dans le DNS, par exemple un CNAME sous s1._domainkey.example.com. Le sélecteur s1 n'est qu'un exemple ; reprenez exactement le nom indiqué par l'outil.
4. Lancez la vérification dans l'outil et envoyez un e-mail de test.

Si un système ne peut pas du tout signer avec votre domaine, faites-le envoyer via votre propre serveur de messagerie ou attribuez-lui un sous-domaine dédié.

Erreur 3 : SPF dépasse dix requêtes DNS

Comment la reconnaître : l'en-tête indique spf=permerror, souvent pour toutes les sources en même temps. En général, un include: supplémentaire vient d'être ajouté à l'entrée SPF.

Comment la corriger : SPF autorise au maximum dix requêtes DNS. Au-delà, toute l'entrée est considérée comme erronée et SPF ne peut plus sauver DMARC. Supprimez les services inutilisés et comptez sur DKIM pour les systèmes tiers. Comment compter et raccourcir est expliqué dans le guide Erreur SPF «too many DNS lookups» : pourquoi dix requêtes doivent suffire

Erreur 4 : transferts

Comment la reconnaître : le rapport montre une petite quantité d'e-mails provenant de serveurs que vous ne connaissez pas, par exemple celui d'une haute école ou d'une association. SPF échoue, DKIM réussit le plus souvent.

Comment la corriger : lors d'un transfert, c'est un serveur tiers qui envoie, et SPF échoue forcément. L'important est que tous vos e-mails portent une signature DKIM avec votre domaine. Elle survit au transfert tant que personne ne modifie le contenu.

En détail, y compris SRS et ARC : Transfert d'e-mails : SPF fail et e-mails transférés en spam

Erreur 5 : syntaxe incorrecte de l'entrée DMARC

Comment la reconnaître : au lieu de dmarc=fail, l'en-tête indique dmarc=none ou un permerror. Les rapports n'arrivent pas, alors que vous avez indiqué une adresse.

Comment la corriger : une entrée correcte est une entrée TXT sous _dmarc.example.com avec la valeur v=DMARC1; p=none; rua=mailto:dmarc@example.com. Erreurs typiques :

• v=DMARC1 n'est pas au début, ou p= ne suit pas directement.
• Des virgules au lieu de points-virgules entre les paramètres.
• L'adresse de rapport sans mailto:.
• Deux entrées TXT avec v=DMARC1. Les destinataires n'appliquent alors aucun DMARC.
• L'éditeur DNS ajoute lui-même le domaine. _dmarc.example.com devient ainsi _dmarc.example.com.example.com. Saisissez seulement _dmarc comme nom.

Erreur 6 : sous-domaines

Comment la reconnaître : les e-mails avec une adresse d'expéditeur comme info@facture.example.com échouent, le domaine principal passe. Ou tout a échoué après que vous avez ajouté adkim=s ou aspf=s.

Comment la corriger : sans entrée DMARC propre, un sous-domaine reprend l'entrée du domaine principal, avec sp= s'il existe, sinon avec p=. SPF, en revanche, ne s'hérite pas : si le sous-domaine a besoin de SPF, il lui faut sa propre entrée SPF. Configurez SPF et DKIM pour les sous-domaines qui envoient. L'alignement strict (s pour strict) exige des domaines identiques. Restez sur le réglage souple par défaut tant qu'il n'y a pas de raison claire de faire autrement.

Erreur 7 : passage trop tôt à p=reject

Comment la reconnaître : l'erreur existe en fait depuis longtemps, mais vous ne la remarquez que maintenant. Des clients signalent des e-mails manquants et les expéditeurs reçoivent des retours avec «rejected due to DMARC policy».

Comment la corriger : p=reject ne provoque pas de dmarc=fail, il rend seulement les conséquences visibles. Revenez temporairement à p=quarantine ou p=none, corrigez la source, puis durcissez à nouveau quand les rapports sont propres depuis quelques semaines. Ce qui se passe lors du rejet est expliqué dans «Rejected due to DMARC policy» : votre propre domaine bloque vos propres e-mails et le bon moment pour changer dans DMARC de p=none à quarantine et reject : quand est-ce sûr ?

Erreur 8 : clé DKIM changée ou supprimée

Comment la reconnaître : tout fonctionnait depuis des mois, soudain apparaît dkim=fail ou «no key for signature». Souvent après un changement d'hébergeur, une remise en ordre du DNS ou un changement de clé dans le système de messagerie.

Comment la corriger : relevez le sélecteur dans l'en-tête (header.s ou s= dans la signature) et vérifiez qu'une entrée complète existe sous <sélecteur>._domainkey.example.com. Avec Microsoft 365, les deux entrées CNAME selector1 et selector2 doivent rester en place, même si une seule est active. Les autres messages d'erreur DKIM sont expliqués dans Signature DKIM invalide : «body hash did not verify» et autres erreurs

Vérifier que la correction fonctionne

1. Attendez que la modification DNS soit visible. Selon le réglage, cela prend de quelques minutes à quelques heures.
2. Envoyez depuis le système concerné un e-mail de test vers une boîte externe et vérifiez dmarc=pass dans l'en-tête.
3. Contrôlez les rapports DMARC des jours suivants. La source doit y être en vert, chez tous les grands destinataires.

Ce que DomainRadar prend en charge

DomainRadar vous fournit une adresse de rapport, analyse les rapports DMARC chaque jour et attribue les adresses IP aux services. Vous voyez d'un coup d'œil quelle source échoue et si la cause est SPF, DKIM ou l'alignement. Si une nouvelle source en erreur apparaît ou si un sélecteur DKIM disparaît, vous recevez une alerte.