Postmaster

Pourquoi votre message a été refusé ou a rebondi.

Un serveur sous OxiMail a renvoyé une erreur renvoyant vers cette page. Trouvez la raison ci-dessous : chacune explique ce qu’il s’est passé et ce que l’expéditeur peut changer. OxiMail utilise les codes de statut étendus SMTP standard (RFC 3463 / 7372) ; cette page en est la version en clair. Ce sont des décisions automatiques et conformes aux standards, et non un blocage permanent de votre part : corrigez la cause ci-dessous et renvoyez.

550 5.7.26

Rejeté par la politique DMARC du domaine expéditeur

Le domaine du champ From: publie une politique DMARC p=reject, et votre message a échoué à l’authentification : ni SPF ni DKIM n’ont réussi et ne sont alignés avec ce domaine. Le propriétaire du domaine demande explicitement aux destinataires de rejeter ce courrier ; OxiMail s’y conforme.

Comment corriger

Émettez depuis un hôte listé dans l’enregistrement SPF du domaine From: (ou via un service qui l’est).
Signez le message en DKIM avec une clé publiée sous le domaine From:.
Assurez l’alignement de SPF ou DKIM avec le domaine From: (même domaine organisationnel).
Si vous gérez le domaine, vérifiez vos enregistrements DNS SPF/DKIM/DMARC ; un rapport DMARC montrera ce qui a échoué.

550 5.7.1

Refusé : l’adresse From: ne désigne pas un auteur unique

Le serveur destinataire vérifie l’expéditeur par rapport au domaine affiché dans le champ From: (DMARC). Il ne peut le faire que si le message a un seul champ From: contenant une seule adresse, écrite selon la norme du courriel. Ce message n’avait pas de champ From:, en avait plusieurs, contenait plusieurs adresses, ou une valeur qui n’est pas une adresse valide : le domaine que verrait le lecteur ne pouvait pas être établi, et le message a été refusé avant livraison. Les grandes messageries refusent aussi ces messages.

Comment corriger

Envoyez le message avec un seul champ From: contenant une seule adresse, par exemple : From: "Jeanne Dupont" <jeanne@example.com>.
Si le nom affiché contient une virgule, des guillemets, un @ ou des chevrons, mettez-le entre guillemets doubles.
Si le message vient d’une application ou d’un script, corrigez l’en-tête qu’il produit : les logiciels de messagerie le produisent correctement.

550 5.7.1

Refusé comme spam

Le pipeline de filtrage d’OxiMail a évalué le message comme non sollicité ou abusif et l’a refusé avant livraison. C’est une décision de contenu/réputation, pas d’authentification.

Comment corriger

Vérifiez que SPF, DKIM et DMARC passent tous : un courrier non authentifié est jugé suspect.
Contrôlez la réputation de votre IP et de votre domaine (listes de blocage, pics de volume, IP neuves/froides).
Évitez les contenus de type spam (objets trompeurs, raccourcisseurs de liens, en-têtes mal formés).
Si vous pensez à un faux positif, contactez le destinataire par un autre canal pour que son administrateur examine le cas.

550 5.7.1

Refusé pour une pièce jointe dangereuse

Le message contenait un type de fichier que ce serveur n’accepte pas, et il a été refusé avant livraison : rien n’a été conservé. La réponse nomme la règle, et le nom du fichier quand c’est lui qui a décidé : un exécutable ou une image disque (reconnus à leur contenu, quel que soit leur nom), une extension de la liste bloquée, une double extension comme facture.pdf.exe, un document Office avec macros, une archive protégée par mot de passe, ou une archive illisible. C’est une décision sur le type du fichier, pas une analyse antivirus : le fichier n’a pas été jugé malveillant, il est d’un type qui ne doit pas circuler par courriel.

Comment corriger

Partagez le fichier par un lien (service de partage ou votre propre espace de fichiers) plutôt qu’en pièce jointe.
Pour un document Office, enregistrez-le sans macros (.docx, .xlsx) si elles ne sont pas nécessaires.
N’envoyez pas d’archive protégée par mot de passe : son contenu ne peut pas être vérifié. Utilisez un lien de partage, et transmettez le mot de passe à part si besoin.
Si vous pensez que le refus est une erreur, transmettez le message de refus au destinataire par un autre canal : l’identifiant queue= qu’il contient permet à son administrateur de retrouver la décision dans le journal du serveur.

550 5.1.1

Utilisateur inexistant : la boîte n’existe pas ici

L’adresse destinataire à laquelle vous avez écrit n’existe pas sur ce serveur. Le plus souvent, la partie locale (avant le @) comporte une faute, le compte a été fermé, ou l’adresse n’a jamais été valide.

Comment corriger

Vérifiez l’orthographe de l’adresse, y compris la partie avant le @.
Si vous avez repris l’adresse d’un ancien message ou d’un annuaire, confirmez qu’elle est toujours d’actualité.
Si vous êtes certain que l’adresse devrait exister, contactez le destinataire par un autre canal pour qu’il la fasse vérifier par son administrateur.

550 5.1.1

Ce serveur n’accepte pas le courrier pour ce domaine

Vous vous êtes connecté à un serveur (généralement un MX de secours) en lui demandant d’accepter du courrier pour un domaine qu’il n’héberge pas et ne sauvegarde pas. Le serveur ne relaie pas le courrier pour des domaines arbitraires, et c’est volontaire : cela empêche l’abus de relais ouvert.

Comment corriger

Vérifiez les enregistrements MX du domaine destinataire et livrez à l’hôte correct.
Si vous exploitez un relais, assurez-vous de vous connecter à un serveur réellement autorisé pour le domaine destinataire.
Si vous pensez que ce domaine devrait être accepté ici, l’administrateur du destinataire doit l’ajouter aux domaines acceptés du serveur.

451 4.3.5

Livraison reportée : l’adresse est configurée deux fois

L’adresse du destinataire mène à plus d’un endroit sur ce serveur, par exemple une liste de diffusion et une boîte portant la même adresse. Plutôt que de deviner, au risque de livrer au mauvais endroit, le serveur a reporté votre message avec une erreur temporaire. Rien n’est en cause de votre côté : l’administrateur du destinataire a été alerté et doit supprimer l’un des deux.

Comment corriger

Vous n’avez rien à faire : votre serveur garde le message et réessaie automatiquement, en général pendant plusieurs jours.
Une fois l’adresse corrigée par l’administrateur du destinataire, la tentative suivante est livrée normalement.
Si le délai compte, prévenez le destinataire par un autre canal pour que son administrateur agisse plus vite.

DSN

Votre message a rebondi (retourné à l’expéditeur)

OxiMail a accepté le message pour livraison mais n’a pas pu le délivrer ; après plusieurs jours de tentatives, il vous l’a retourné sous forme de rebond (une notification d’état de livraison, RFC 3464).

Comment corriger

Lisez la ligne « Diagnostic-Code » du rebond : elle contient l’erreur SMTP exacte du serveur de destination.
Causes fréquentes : la boîte n’existe pas (5.1.1), la boîte est pleine (quota), ou une politique l’a rejetée.
Un échec temporaire (4.x.x) signifie qu’OxiMail a réessayé ~5 jours avant d’abandonner ; vérifiez si la destination était joignable.
Corrigez l’adresse ou la cause sous-jacente puis renvoyez.

DMARC + ARC

Un message réexpédié, ou passé par une liste de diffusion

La réexpédition et les listes de diffusion cassent l’authentification : le SPF désigne désormais le réexpéditeur, et une liste qui réécrit l’objet ou ajoute un pied de page invalide la signature DKIM. Le message échoue alors au DMARC chez nous sans que l’expéditeur d’origine y soit pour quoi que ce soit. OxiMail évalue les chaînes ARC (RFC 8617) : un réexpéditeur qui scelle ce qu’il a vu, et à qui nous avons des raisons de faire confiance, permet d’honorer le résultat d’origine au lieu de le jeter.

Comment corriger

Si vous exploitez une liste de diffusion ou un réexpéditeur, scellez vos relais en ARC. Sans cela, vous cassez silencieusement le DMARC de tous les domaines que vous traitez.
Évitez si possible de réécrire les objets et d’ajouter des pieds de page : chaque modification invalide la signature DKIM.
Sur-signez les en-têtes qui comptent, pour qu’un en-tête ajouté en aval ne puisse pas se faire passer pour l’original.
Si vous êtes l’expéditeur d’origine, demandez à l’intermédiaire s’il scelle en ARC : la correction lui revient, pas à vous.

Envois en nombre

Infolettres et envois en nombre : ce que nous attendons

L’envoi en nombre n’est pas refusé en soi, mais il est tenu aux exigences que les grands fournisseurs imposent désormais. Une campagne qui arrive sans désabonnement réellement utilisable est traitée comme suspecte, et les plaintes qui suivent abîment votre réputation bien plus qu’un refus ne le ferait.

Comment corriger

Proposez le désabonnement en un clic (RFC 8058) et honorez-le immédiatement. Notre client affiche le bouton au destinataire, et lorsqu’il signale une infolettre comme indésirable, nous lui proposons le désabonnement à la place.
Authentifiez chaque envoi : SPF, DKIM aligné sur le domaine de l’en-tête De, et une politique DMARC que vous appliquez vraiment.
Envoyez depuis un domaine et une adresse IP stables, et chauffez-les progressivement. Une adresse froide qui émet soudain des milliers de messages ressemble exactement à une adresse compromise.
Retirez les rebonds définitifs de votre liste au lieu de les réessayer. Renvoyer sans cesse vers des adresses mortes est l’un des signaux négatifs les plus forts qui soient.

Toujours bloqué ? L’administrateur du destinataire peut retrouver le refus dans les journaux de son serveur.