Transformez vos e-mails en revenus avec Brew.
Authentification, réponses des fournisseurs, qualité de l’audience, désabonnement : comprenez pourquoi vos e-mails sont rejetés ou classés en spam.
Délivrance et placement en boîte de réception sont deux choses différentes. Un serveur de réception peut accepter un message et le classer en spam. Un tableau de bord de campagne qui affiche « délivré » ne prouve pas que le lecteur l’a vu.
Quand un problème apparaît, rassemblez les éléments avant de modifier le texte ou de changer de prestataire d’envoi. Le maillon défaillant peut être l’authentification, la réputation, l’audience ou le message lui-même.
Pour les messages rejetés ou différés, examinez la réponse SMTP réelle et le code de statut étendu. Les échecs temporaires et les rejets définitifs ne se traitent pas de la même façon. La FAQ de Google pour les expéditeurs décrit les deux ; elle n’affirme pas que tout manquement aux règles produit désormais des erreurs définitives.
Si les messages sont acceptés mais arrivent en spam, examinez les résultats d’authentification dans les en-têtes reçus, les données de réputation des fournisseurs lorsqu’elles existent, et les changements récents d’audience ou de volume. Quelques boîtes de réception témoins aident à diagnostiquer un problème, mais elles ne mesurent pas le placement sur l’ensemble de la liste.
Un code de statut étendu se compose de trois nombres séparés par des points, définis dans la RFC 3463. Le premier nombre indique la classe. Un code qui commence par 4 signale un échec temporaire : le serveur d’envoi doit réessayer plus tard. Un code qui commence par 5 signale un échec définitif : renvoyer le même message sans le modifier ne servira à rien.
Le deuxième nombre précise le sujet. Les codes de la plage X.1.X concernent l’adressage, et 5.1.1 signifie généralement que la boîte aux lettres n’existe pas : excluez cette adresse. Les codes de la plage X.7.X concernent la sécurité ou les politiques, et c’est là qu’apparaissent généralement les problèmes d’authentification et de réputation.
Google recense les réponses renvoyées par Gmail dans sa référence des erreurs SMTP. Lisez le texte complet de la réponse en plus du code, car un même code peut recouvrir plusieurs raisons différentes.
Google Postmaster Tools montre comment Gmail perçoit votre domaine d’envoi, y compris le taux de spam signalé par les utilisateurs auquel renvoient les exigences de Google. Vous validez le domaine avec un enregistrement DNS. Gmail n’affiche des données qu’à partir du moment où un domaine envoie suffisamment d’e-mails par jour à ses utilisateurs : un petit expéditeur peut donc voir des tableaux de bord vides.
Smart Network Data Services, le service de Microsoft plus connu sous le nom de SNDS, rend compte des e-mails envoyés depuis des adresses IP précises vers les boîtes grand public d’Outlook.com, y compris les taux de plainte et les pièges à spam touchés. Vous enregistrez les adresses IP que vous contrôlez : l’outil est donc surtout utile avec des IP d’envoi dédiées. Sur des IP partagées, demandez à votre prestataire d’envoi ce qu’il surveille.
Aucun de ces deux outils ne vous dit où une campagne donnée a atterri. Ils montrent des tendances quotidiennes, et c’est ce qu’il vous faut quand un problème s’est installé au fil de plusieurs envois.
SPF autorise une infrastructure d’envoi pour un domaine d’enveloppe. DKIM signe un message avec l’identité d’un domaine. DMARC vérifie l’alignement avec le domaine From visible et publie une politique ainsi qu’un mécanisme de rapports. Aucun des trois ne garantit l’arrivée en boîte de réception.
Utilisez les enregistrements fournis par votre prestataire d’envoi et vérifiez le résultat sur un message réellement reçu. N’ajoutez pas d’enregistrements SPF contradictoires, et ne supposez pas qu’un enregistrement DNS prouve que chaque circuit d’envoi l’utilise correctement. Votre infrastructure a aussi besoin d’un DNS inverse adapté et d’un transport sécurisé.
Dans Brew, suivez le parcours de vérification du domaine et publiez les enregistrements demandés. Contrôlez l’adresse From utilisée par la campagne ou l’automatisation réelle, surtout quand un agent gère plusieurs marques.
Une politique DMARC est un enregistrement TXT publié sur l’hôte _dmarc du domaine de l’adresse From. Commencez par p=none. Cette politique demande aux serveurs de réception de ne rien faire de particulier des e-mails en échec, mais ils continuent d’envoyer les rapports agrégés à l’adresse rua.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Les rapports listent chaque source qui envoie des e-mails au nom de votre domaine, et indiquent si chacune a réussi SPF ou DKIM avec alignement. Attendez-vous à découvrir des outils oubliés, comme un système de facturation ou un outil de support. Corrigez ou supprimez chaque source en échec.
Une fois que tous les e-mails légitimes réussissent, passez à p=quarantine. Cette politique demande aux serveurs de réception de traiter les e-mails en échec comme suspects, ce qui signifie généralement les classer en spam.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"La politique la plus stricte, p=reject, demande aux serveurs de réception de refuser les e-mails en échec. N’y passez qu’après une période en quarantine sans échec d’e-mails légitimes. Continuez à lire les rapports à chaque étape : un nouvel outil qui commence à envoyer au nom de votre domaine y apparaîtra en premier.
Un sous-domaine d’envoi dédié, comme mail.example.com, fait exception. Quand rien d’autre n’envoie depuis ce sous-domaine et que votre prestataire a vérifié son SPF et son DKIM, il peut démarrer directement en p=reject. Brew recommande p=reject pour un sous-domaine dédié qu’il a configuré, et p=none pour un domaine principal depuis lequel d’autres services peuvent envoyer.
Les consignes de Google distinguent les exigences applicables à tous les expéditeurs de règles plus strictes pour ceux qui atteignent environ 5 000 messages par jour vers des comptes Gmail personnels. Google demande un taux de spam inférieur à 0,1 % et met en garde contre le seuil de 0,3 %. Ses exigences pour les envois en masse comprennent SPF et DKIM, DMARC, l’alignement et le désabonnement en un clic pour les messages d’abonnement concernés.
La liste de Google pour tous les expéditeurs, quel que soit leur volume, comprend notamment ces points :
Les expéditeurs en masse doivent aussi respecter les points suivants :
p=none.Pour appliquer le seuil, Google additionne les e-mails envoyés depuis un même domaine principal, et un domaine qui l’a franchi une fois conserve le statut d’expéditeur en masse. Sa FAQ pour les expéditeurs explique comment fonctionne ce décompte.
Les recommandations de Yahoo couvrent elles aussi l’authentification, les plaintes et le désabonnement. Yahoo ne publie pas de seuil chiffré équivalent pour les expéditeurs en masse : consultez sa FAQ plutôt que d’appliquer le chiffre de Gmail à tous les fournisseurs.
Microsoft a annoncé en 2025 que les domaines qui envoient plus de 5 000 e-mails par jour vers ses boîtes grand public, c’est-à-dire les adresses outlook.com, hotmail.com et live.com, doivent réussir SPF et DKIM et publier DMARC. La politique DMARC peut être p=none, et le domaine From doit être aligné sur SPF ou DKIM.
Recommandations des fournisseurs vérifiées le 28 septembre 2026. Consultez les pages en lien lorsque vous diagnostiquez un nouvel incident.
Le désabonnement en un clic défini par la RFC 8058 est un mécanisme qui associe des en-têtes et une requête POST en HTTPS. Un lien visible en pied de page est également utile, et exigé par les règles applicables, mais une page de préférences seule n’implémente pas le protocole.
Un message compatible avec le désabonnement en un clic porte deux en-têtes :
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickQuand le lecteur clique sur « Se désabonner » dans sa boîte de réception, le fournisseur de messagerie envoie une requête POST à l’URL HTTPS avec le corps List-Unsubscribe=One-Click. L’adresse mailto: sert d’alternative pour les logiciels de messagerie qui ne prennent pas en charge le désabonnement en un clic. La RFC 8058 exige aussi une signature DKIM valide qui couvre les deux en-têtes. Rendez l’URL propre à chaque destinataire et difficile à deviner. Les scanners de sécurité ouvrent souvent les liens des e-mails entrants : une simple requête GET sur cette URL ne doit donc désabonner personne.
Brew ajoute les en-têtes List-Unsubscribe et List-Unsubscribe-Post aux envois marketing. Ils pointent vers une URL HTTPS signée, propre à chaque destinataire, qui accepte la requête POST du désabonnement en un clic.
Vérifiez qu’un désabonnement marketing bloque bien les envois marketing ultérieurs, par tous les circuits d’envoi que vous utilisez. Conservez les exclusions quand vous importez des contacts ou changez de plateforme. Gardez les messages transactionnels essentiels séparés, par leur finalité comme par leur configuration d’envoi.
Examinez l’origine des adresses et ce à quoi les personnes s’attendaient lors de leur inscription. Retirez les adresses invalides via le processus d’exclusion de votre prestataire, analysez les pics de plaintes, et évitez de renvoyer un e-mail à des personnes simplement parce que le suivi indique qu’elles ne l’ont pas ouvert.
Aucun âge de liste, aucun ratio image/texte ni aucun mot interdit ne garantit la délivrance de façon universelle. Une hausse soudaine du volume vers une liste mal connue pose un problème bien plus sérieux que l’emploi du mot « gratuit ».
Si c’est un agent qui envoie la campagne, les mêmes vérifications s’appliquent. Utilisez des faits vérifiés, une audience pertinente et une adresse de réponse surveillée. Corrigez la cause identifiée, faites un envoi de test contrôlé et examinez les réponses des fournisseurs avant d’élargir de nouveau.
