E-mail rejeté par la politique DMARC (554 5.7.5) : solution

Que signifie l’échec ?

DMARC, défini dans la RFC 9989, évalue le domaine de l’adresse From visible, appelé Author Domain. DMARC réussit quand SPF ou DKIM réussit pour un domaine aligné sur cet Author Domain. Une seule réussite alignée suffit. La valeur p=reject est le traitement demandé par le propriétaire du domaine, et un destinataire peut appliquer sa politique locale pour traiter un message en échec.

Le rejet prouve qu’un destinataire a refusé un message. Il ne prouve pas que tous les destinataires le refuseront, n’identifie pas l’application responsable et ne montre pas que l’enregistrement DMARC publié est faux. La rubrique DMARC explique le modèle d’évaluation complet.

Ces exemples sont illustratifs et masqués. Le rejet reçu prouve le refus. Le bloc Authentication-Results provient d’un autre message de test livré dans une boîte.

Returned bounce:
550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.
Controlled delivered test:
Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.marketing-tool.example;
  dkim=none;
  dmarc=fail (p=REJECT) header.from=example.com

Les jetons de résultat spf, dkim et dmarc, et des propriétés comme smtp.mailfrom, header.d et header.from, suivent le format Authentication-Results de la RFC 8601. Ne lisez ce champ que si vous faites confiance au service d’authentification qui l’a ajouté. Un message peut porter une copie non fiable ou falsifiée.

Une réponse 550 5.7.0 seule n’identifie pas DMARC comme cause. La RFC 3463 définit X.7.0 comme un statut de sécurité non défini, tandis que la RFC 7372 définit des codes plus précis pour l’authentification. Conservez le texte de diagnostic complet et l’hôte émetteur.

Google cite 550-5.7.26 comme exemple de rejet d’e-mail non authentifié dans ses consignes d’envoi Gmail. Microsoft indique qu’Exchange Online peut appliquer la politique DMARC publiée d’un expéditeur pendant SMTP dans son guide de configuration DMARC. Ces exemples ne prédisent pas la réponse de chaque destinataire.

Causes habituelles

Un expéditeur légitime n’a aucune authentification alignée

Une plateforme marketing, un CRM, un help desk ou un service transactionnel peut utiliser votre domaine From visible avec son propre expéditeur d’enveloppe et son domaine de signature DKIM. Dans l’en-tête d’exemple, SPF échoue pour bounce.marketing-tool.example et DKIM est absent. Aucun n’apporte de réussite alignée pour example.com.

Confirmez l’application et la route sortante avant de toucher au DNS. Échec DMARC : causes et corrections explique comment une authentification réussie peut échouer à l’alignement DMARC.

DKIM réussit pour un signataire non aligné

Un résultat dkim=pass ne suffit pas à lui seul. Le domaine header.d validé doit être aligné sur le domaine From visible selon le mode d’alignement DMARC du domaine. C’est la conséquence des règles d’alignement DMARC de la RFC 9989. Cela ne prouve pas qu’un service d’envoi donné ne prend pas en charge l’authentification de domaine.

SPF réussit pour une enveloppe non alignée

SPF évalue le domaine d’enveloppe SMTP, affiché en smtp.mailfrom dans un champ Authentication-Results fiable. Un service peut réussir SPF pour son propre domaine return-path alors que l’adresse From visible utilise votre domaine. DMARC échoue alors, sauf si DKIM fournit une réussite alignée.

N’ajoutez pas un service à SPF sur la seule foi d’un rejet. Confirmez que ce service a envoyé par le chemin de production rejeté, puis suivez ses instructions actuelles propres à votre compte pour un return-path authentifié ou un domaine DKIM.

Un flux indirect a changé le chemin du message

Le transfert peut casser SPF, car le destinataire évalue l’adresse IP du serveur de transfert. Une signature DKIM alignée peut préserver DMARC dans un flux indirect sans modification, mais les changements d’une liste ou d’un intermédiaire peuvent invalider cette signature. La RFC 7960 explique ces limites des flux indirects.

C’est une hypothèse tant que vous n’avez pas comparé la route d’origine à celle transférée ou traitée par la liste.

Le message rejeté était usurpé

Si les journaux d’envoi et les rapports DMARC n’identifient pas l’IP, l’application ou la plateforme comme source autorisée, le message rejeté peut être usurpé. Le rejet peut alors être le résultat attendu de l’application de la politique. Changer la politique réduit la protection demandée sans réparer d’expéditeur légitime.

Pour interpréter d’autres symptômes de retour, voir Rejet d’e-mail : lire l’erreur et corriger la cause.

Et « 554 5.7.5 Permanent Error Evaluating DMARC Policy » ?

554 5.7.5 Permanent Error Evaluating DMARC Policy signale un rejet permanent que le système de réception décrit comme un problème d’évaluation DMARC. La formulation complète compte : la RFC 3463 définit X.7.5 comme un échec cryptographique, pas comme un code universel d’erreur DNS DMARC. Ne concluez pas de cette seule réponse que deux enregistrements existent ou que SPF et DKIM ont réussi.

Vérifiez l’enregistrement sans deviner la cause

En cas d’erreur d’évaluation, inspectez l’enregistrement publié pour le domaine From visible. Remplacez example.com par ce domaine :

dig +short TXT _dmarc.example.com

Lisez la réponse DNS en enregistrements, pas en nombre de chaînes entre guillemets. Un seul enregistrement TXT peut contenir plusieurs chaînes jointes à l’évaluation. La RFC 7489, section 6.1 décrit cette représentation ; la RFC 9989, section 4.10.1 régit la découverte de politique actuelle.

• Plusieurs enregistrements DMARC au même nom : réglez le doublon avec le propriétaire du domaine. N’ajoutez pas une deuxième politique à côté de l’existante. Le générateur DMARC produit la valeur de remplacement unique.
• Aucune réponse au nom exact : vérifiez la politique du domaine parent applicable et la résolution DNS. Une réponse vide pour un sous-domaine ne prouve pas que le message échappe à DMARC.
• Un enregistrement existe : validez la version et les valeurs de politique reconnues. Comparez-le à la configuration DNS faisant autorité avant de modifier une politique légitime.

Demandez au destinataire ses preuves d’évaluation

Si les contrôles DNS n’expliquent pas l’erreur, transmettez à l’administrateur du destinataire la réponse exacte, l’hôte émetteur, l’horodatage, les domaines d’expéditeur et de destinataire, et les réponses DNS obtenues. Demandez quelle requête ou étape de validation a échoué. Conservez les résultats d’authentification disponibles ; ne supposez pas SPF ou DKIM hors de cause parce que la réponse commence par 554.

Une réponse permanente 5xx signale un échec de livraison, pas une demande de renvoyer le message inchangé. La RFC 5321, section 4.2.1 définit les classes de réponse. Refaites un test contrôlé une fois le problème identifié réparé.

Comment Gmail et Microsoft 365 signalent-ils un rejet DMARC ?

Gmail et Microsoft 365 publient des réponses DMARC précises. Vérifiez le destinataire et l’explication complète avant de choisir une réparation ; votre boîte d’envoi peut être hébergée par un autre fournisseur.

Gmail : lisez l’explication après 550 5.7.26

La référence des erreurs SMTP de Gmail inclut ce diagnostic propre à DMARC, avec un domaine fictif :

550 5.7.26 Unauthenticated email from domain-name is not accepted due to domain's DMARC policy.

Gmail utilise aussi 5.7.26 pour d’autres échecs d’authentification. Si le texte cite la politique DMARC du domaine, cherchez une réussite SPF ou DKIM alignée. Sinon, utilisez le guide de dépannage 550 5.7.26 pour choisir la bonne piste.

Microsoft 365 : repérez la réponse DMARC 5.7.509

La référence NDR d’Exchange Online associe 5.7.509 à :

Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject.

Cette réponse indique un échec DMARC chez le destinataire Microsoft. Trouvez l’application d’envoi et réparez son authentification alignée. Un rejet Microsoft ne signifie pas que le message est passé par Microsoft 365. Le guide 550 5.7.509 couvre ce NDR précis.

Que signifie « DMARC unauthenticated mail is prohibited » ?

« DMARC unauthenticated mail is prohibited » cite DMARC dans le refus, mais la phrase seule n’identifie ni le fournisseur ni le contrôle exact en échec. Conservez l’hôte émetteur et le reste de la réponse, puis examinez l’authentification et l’alignement de l’expéditeur. N’attribuez pas cette phrase à Microsoft ou à un autre éditeur sans la rapprocher de son diagnostic documenté.

Comment diagnostiquer l’échec ?

1. Conservez le rejet complet reçu

Gardez le rejet complet, l’hôte émetteur, le statut SMTP, l’horodatage, le domaine From visible, celui du destinataire et le diagnostic. Rapprochez-le des journaux d’envoi par Message-ID, destinataire et heure d’envoi si possible.

Avant de toucher au DNS ou au fournisseur, montez un dossier de preuves :

Illustrative redacted rejection evidence packet
Visible From domain: example.com
SPF envelope domain/result: bounce.marketing-tool.example / fail
DKIM d=/selector/result: not present / not present / none
DMARC result/disposition: fail / p=REJECT
Exact recipient response: 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.
Message ID/time: <redacted-message-id> / 2026-08-12T10:15:00Z
Sender application: marketing platform

Si la réponse dit 550 5.7.1, gardez son texte exact. Le guide des variantes 550 5.7.1 aide à distinguer un texte DMARC des refus liés au relais, aux listes de blocage, à la politique du destinataire ou au contenu.

2. Trouvez l’expéditeur de production exact

Cherchez l’application, l’ESP, la passerelle ou l’utilisateur qui a soumis le message. Notez le domaine From, l’expéditeur d’enveloppe, le relais ou l’IP sortante, le sélecteur DKIM et le domaine de marque.

N’identifiez pas l’application d’après le nom affiché. Un domaine peut servir à plusieurs systèmes indépendants, chacun avec ses réglages SPF, DKIM et return-path.

3. Lisez un message de test livré

Si possible, envoyez un test par la même application, le même domaine authentifié, le même modèle, la même route sortante et vers le même fournisseur. Livrez-le dans une boîte que vous gérez, qui affiche les en-têtes complets.

L’analyseur d’en-têtes d’e-mail aide à repérer les résultats d’authentification dans les en-têtes bruts. Seuls les résultats ajoutés par un service de réception fiable font foi.

Comparez le domaine From visible au domaine SPF smtp.mailfrom et à tout domaine DKIM header.d validé dans le champ Authentication-Results fiable ajouté par le destinataire. Vous saurez quelle piste réparer :

• Échec d’authentification : SPF et DKIM échouent ou manquent. Réparez l’authentification de l’expéditeur confirmé.
• Échec d’alignement : SPF ou DKIM réussit, mais son domaine n’est pas aligné sur le domaine From visible. Configurez le return-path authentifié ou le domaine de signature DKIM.
• Décision du destinataire : DMARC échoue et le destinataire rejette, met en quarantaine ou accepte le test. La politique est une demande, pas la garantie d’un traitement identique partout.

4. Vérifiez la politique DMARC publiée à part

Consultez l’enregistrement DMARC du domaine From après avoir conservé les preuves du message. Vérifiez que le domaine contrôlé est bien le domaine From visible exact ou son domaine organisationnel applicable. Notez p=, adkim= et aspf= s’ils sont présents.

Un résultat public montre la publication DNS actuelle. Il ne prouve pas que l’application signe les e-mails, utilise le return-path configuré ou a produit le message rejeté.

Comment corriger ?

Configurez le DKIM aligné de l’expéditeur confirmé

Si l’application gère une signature DKIM personnalisée, configurez le domaine prévu dans les réglages du compte et publiez les enregistrements DNS générés pour ce compte. Terminez ensuite la vérification du fournisseur.

Ne publiez pas de sélecteurs, cibles CNAME, jetons ou noms d’hôte copiés d’un autre compte. Utilisez seulement les valeurs générées pour votre domaine et tenant.

Cette réparation touche l’authentification et l’alignement, pas l’application de DMARC.

Quel fournisseur d’envoi faut-il réparer ?

Réparez DKIM dans le service qui a envoyé le message en échec, pas d’office chez le fournisseur de votre boîte.

• Envoyé par Google Workspace : générez la clé DKIM du domaine dans la console d’administration, publiez le TXT fourni par Google chez votre fournisseur DNS, puis lancez l’authentification dans la console. Publier l’enregistrement seul n’active pas la signature. Suivez les instructions DKIM de Google.
• Envoyé par Microsoft 365 : utilisez les réglages DKIM du domaine personnalisé dans Microsoft Defender, publiez les CNAME générés pour le tenant et activez la signature une fois les enregistrements détectés. Suivez les instructions DKIM de Microsoft ; ne déduisez pas les cibles de sélecteur d’un exemple.
• Envoyé par un CRM, un help desk ou un service marketing : authentifiez le domaine dans ce service. Activer DKIM pour votre boîte Google Workspace ou Microsoft 365 ne configure pas une plateforme d’envoi distincte. Vérifiez les enregistrements générés par le service et le domaine de signature d’un nouveau message.

Configurez un return-path authentifié si SPF assure l’alignement

Si l’expéditeur gère un return-path personnalisé, publiez les enregistrements DNS générés pour votre compte et vérifiez que l’expéditeur d’enveloppe utilise le sous-domaine authentifié. Envoyez ensuite un message et comparez le domaine smtp.mailfrom obtenu au domaine From visible.

Un include SPF peut autoriser une infrastructure, mais il n’aligne pas à lui seul un domaine d’enveloppe tiers sur votre domaine From visible.

Revoyez signature et routage des flux indirects

Si un serveur de transfert, une liste ou une passerelle modifie le message après la signature, voyez si la modification peut avoir lieu avant la signature DKIM alignée ou si la route peut l’éviter. Testez une route contrôlée à la fois.

Le transfert ne prouve pas que l’expéditeur est bien configuré. Transfert et modification du message sont des conditions distinctes selon les conseils de la RFC 7960 sur les flux indirects.

Séparez changement de politique et réparation

Ne baissez pas p=reject comme correctif technique. Changer p= modifie le traitement DMARC demandé par le domaine, pas le résultat SPF de l’expéditeur, sa signature DKIM ni l’alignement du domaine. Si un incident exige un choix temporaire de politique, documentez-le à part, limitez sa durée et continuez à réparer l’expéditeur identifié.

Comment valider la réparation ?

Pour valider la réparation DMARC, reproduisez le même chemin de production : même application, domaine From visible, modèle, fournisseur destinataire et conditions de routage. Une requête DNS réussie n’est que la première couche de validation.

Vérifiez chaque couche utile :

• DNS : interrogez les enregistrements publiés du domaine via le DNS faisant autorité et au moins un résolveur public.
• Fournisseur : confirmez dans son interface l’état actuel d’authentification ou de vérification du domaine.
• Message : envoyez un nouveau message et cherchez dans le champ Authentication-Results fiable une réussite SPF ou DKIM alignée sur le domaine From visible.
• DMARC : une fois les rapports reçus, vérifiez que la source réparée apparaît comme prévu dans les rapports agrégés DMARC.

From: billing@example.com
Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.marketing-tool.example;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Le header.d=example.com validé est aligné sur le domaine From visible. La réussite SPF pour bounce.marketing-tool.example n’apporte pas cet alignement. C’est la règle « l’un ou l’autre mécanisme » de la RFC 9989, section 4.4.

Gardez le message brut réussi avec les preuves de l’échec précédent. Un statut fournisseur vert ne prouve pas que la route de production exacte a produit une réussite alignée.

Trouvez chaque expéditeur encore non aligné pour DMARC

Vérifiez la politique publiée du domaine avant tout autre changement.

Vérifiez le DMARC de votre domaine

Le test inspecte l’enregistrement DMARC publié. Il ne peut pas prouver pourquoi un destinataire précis a rejeté un message précis, ne surveille pas en continu et ne garantit pas le placement futur en boîte de réception.

Une fois un expéditeur aligné, reste à savoir quelles autres sources de production sont encore non alignées. L’agent DMARC de Palisade analyse les rapports agrégés DMARC entrants, identifie les sources d’envoi et les problèmes d’authentification ou d’alignement, et crée des tickets de correction priorisés. Votre équipe examine les preuves et applique la correction. Palisade ne modifie pas automatiquement votre DNS ni votre politique DMARC, ne contrôle pas le traitement côté destinataire et ne garantit pas la livraison.

Commencez avec Palisade