DMARC fail : ce que cela veut dire et comment corriger

« DMARC fail » signifie que le serveur destinataire n’a trouvé aucune raison de croire que le message vient du domaine de son champ De. DMARC réussit quand au moins un des deux contrôles réussit et est aligné :

SPF réussit pour le domaine d’enveloppe (l’adresse de retour, cachée), et ce domaine correspond à celui du champ De ;
DKIM vérifie une signature faite avec le domaine du champ De (le d= de la signature), ou un de ses sous-domaines dans le mode souple par défaut.

Un message peut donc réussir SPF, réussir DKIM, et échouer à DMARC, parce que les deux ont réussi pour le domaine de quelqu’un d’autre.

Lire d’abord le verdict

Demandez une copie d’un message refusé en pièce jointe et ouvrez ses en-têtes, ou collez-les dans l’analyseur d’en-têtes. Cherchez la ligne ajoutée par le destinataire :

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.outil-mail.example;
  dkim=pass header.d=outil-mail.example;
  dmarc=fail header.from=votredomaine.fr

Ici, les deux contrôles ont réussi, pour outil-mail.example. Rien n’a été signé ni envoyé pour votredomaine.fr : le service n’est pas authentifié pour votre domaine.

Les passerelles le formulent autrement. Mimecast écrit DNS Authentication: DMARC Fail, Microsoft renvoie 550 5.7.509, Gmail 550-5.7.26. Tous veulent dire la même chose, et la correction se fait côté expéditeur.

Les six causes habituelles

1. Un service envoie en votre nom sans DKIM pour votre domaine. La plus fréquente : un outil de newsletter, un CRM, un logiciel de facturation. Configurez son authentification de domaine pour qu’il signe avec d=votredomaine.fr. Ajouter son include: à SPF ne suffit souvent pas, car beaucoup de services utilisent leur propre adresse de retour.

2. Le transfert. Un message relayé par un serveur intermédiaire arrive depuis l’adresse de ce serveur, et SPF échoue. DKIM survit au transfert tant que le message n’est pas modifié. C’est pourquoi chaque service doit signer avec DKIM, et ne pas compter sur SPF.

3. dkim=fail (body hash did not verify). Le message a été modifié après sa signature : pied de page ou avertissement ajouté par une passerelle, liens réécrits par un filtre de sécurité, liste de diffusion qui ajoute son texte. Signez après le dernier système qui modifie le message, ou faites signer ce système lui-même.

4. SPF en permerror. Plus de dix recherches DNS, deux enregistrements SPF ou une erreur de syntaxe : SPF échoue pour tous les messages. Le vérificateur SPF le montre, et Trop de recherches DNS explique comment corriger.

5. L’alignement strict. adkim=s ou aspf=s dans votre enregistrement DMARC exigent une correspondance exacte. Un message signé par news.votredomaine.fr échoue alors pour votredomaine.fr. Retirez ces deux balises sauf raison précise.

6. Deux enregistrements DMARC, ou aucun lisible. Les destinataires ignorent un domaine qui a plusieurs enregistrements _dmarc. Le vérificateur DMARC le signale.

Ce qu’il ne faut pas faire

Ne revenez pas à p=none pour faire disparaître un échec. Cela rouvre votre domaine à tous les usurpateurs pour régler un seul expéditeur. Trouvez l’expéditeur dans vos rapports DMARC (le lecteur de rapports DMARC classe les sources par résultat), authentifiez-le, et les échecs cessent.

Vos messages échouent chez un seul destinataire

Si une seule entreprise vous refuse alors que les autres acceptent le même message, sa passerelle est souvent plus stricte que votre politique : certaines refusent les échecs DMARC même avec p=none. La correction reste la même, faire passer le message, mais cela explique pourquoi « ça marche partout ailleurs ».

Pour passer de l’observation à l’application une fois que tout passe : De p=none à p=reject.