Corriger les e-mails Google Workspace qui partent dans les spams

Tant que vous n’avez pas généré de clé dans la console d’administration et cliqué sur Démarrer l’authentification, aucune signature DKIM ne porte votre propre domaine : DMARC n’a rien à aligner côté DKIM et doit passer par le seul SPF. Ce guide couvre l’enregistrement SPF unique que Google publie, la clé DKIM que vous devez générer vous-même, le seuil qui fait de vous un expéditeur en masse aux yeux de Gmail, les limites d’envoi d’une boîte de messagerie et la façon de vérifier un envoi réel avec Unspam. Pour savoir où vous en êtes, ouvrez l’un de vos messages et lisez la valeur d= de son en-tête DKIM-Signature : si elle ne porte pas votre domaine, tout part de là.

Lancer un test de spam gratuit Comment tester vos envois

Pourquoi les e-mails Google Workspace finissent dans les spams.

DKIM reste inactif tant que vous ne générez pas la clé vous-même

Dans le cas général, Google Workspace ne génère aucune clé DKIM pour votre domaine, et Google ne documente que deux exceptions : si votre fournisseur de domaine est Squarespace, la clé est créée et ajoutée automatiquement à vos enregistrements DNS ; et vous pouvez n’avoir aucune configuration DKIM à faire si votre domaine en dispose déjà par défaut ou si vous l’avez acheté auprès d’un partenaire Google au moment de votre inscription.

Vous n’avez droit qu’à un seul enregistrement SPF, et le deuxième s’ajoute par accident

Pour un domaine qui n’envoie que par Workspace, Google publie exactement une valeur : v=spf1 include:_spf.google.com ~all, dans un enregistrement TXT sur le domaine racine, avec le champ d’hôte réglé sur @. Deux choses le cassent. Un second enregistrement SPF sur le même nom est une erreur permanente et aucun des deux n’est utilisé, ce qui arrive précisément la troisième fois qu’un nouvel outil vous demande d’ajouter cet enregistrement TXT. Et Google documente un plafond de dix mécanismes include, qu’un outil d’assistance, une application de facturation et une plateforme d’emailing atteignent bien plus vite qu’on ne l’imagine.

Gmail vous compte parmi les expéditeurs en masse et vous n’avez jamais publié de DMARC

Les consignes de Google aux expéditeurs vous traitent comme un expéditeur en masse dès que vous dépassez 5 000 messages par jour vers des comptes Gmail personnels, comptés par domaine principal. L’exemple de Google est parlant : 2 500 messages depuis solarmora.com plus 2 500 depuis promotions.solarmora.com franchissent la limite ensemble. Les expéditeurs en masse doivent publier un enregistrement DMARC, même en p=none, et le domaine From doit s’aligner soit sur le domaine SPF, soit sur le domaine DKIM. Google précise aussi que ce statut d’expéditeur en masse n’a aucune date d’expiration, et que les messages qui ne respectent pas ces exigences partent dans les spams ou sont rejetés avec une erreur 5.7.26.

Une boîte de messagerie n’est pas une plateforme d’envoi, et les limites tombent en pleine campagne

Les comptes en version d’essai sont plafonnés à 500 messages et 500 destinataires externes uniques par jour. Un compte payant monte à 2 000 messages par jour, mais plafonne aussi à 3 000 destinataires externes et 2 000 destinataires externes uniques, et les messages envoyés en SMTP, POP ou IMAP acceptent au maximum 100 destinataires chacun. Les compteurs tournent sur une fenêtre glissante de 24 heures et non sur le jour calendaire : rien ne se réinitialise à minuit et un envoi bien parti se coupe en plein milieu.

L’application passe par le mauvais hôte Google

smtp.gmail.com s’authentifie avec l’adresse d’un seul compte et un mot de passe d’application, et Google le plafonne à 2 000 messages par jour : c’est une route de boîte de messagerie, pas une route applicative.

Quelque chose réécrit vos messages en aval, après la signature de Google

DKIM signe le hachage du corps du message : toute modification postérieure à la signature l’invalide, et le serveur de réception consigne « body hash did not verify » dans l’en-tête Authentication-Results. La page de dépannage DKIM de Google désigne les passerelles sortantes comme cause habituelle, en particulier celles qui ajoutent un pied de page à chaque message sortant, et vous demande de vous assurer que la passerelle ne modifie pas les messages sortants. La même page note que Gmail n’évalue que les cinq premières signatures DKIM d’un message : une signature valide arrivée en sixième position n’est jamais contrôlée.

Comment Google Workspace authentifie vos e-mails.

Google n’écrit pas vos enregistrements DNS à votre place. Chacun des enregistrements ci-dessous vit chez votre hébergeur de domaine, et la console d’administration se contente d’en générer les valeurs puis de les contrôler. SPF et DKIM viennent d’abord, et Google vous demande d’attendre 48 heures après eux avant d’ajouter DMARC. Tout le travail DKIM se fait sous Applications > Google Workspace > Gmail > Authentifier les e-mails (Authenticate email), et vous devez être connecté en tant que super-administrateur.

enregistrement	par défaut	le problème	la solution
SPF	Rien n’est publié tant que vous ne l’avez pas publié vous-même. Ajouter les enregistrements MX de Google n’ajoute aucun SPF.	Sans enregistrement, il n’y a aucun SPF pass sur lequel s’aligner. Avec deux enregistrements sur le même nom, aucun des deux n’est utilisé. Au-delà de dix mécanismes include, l’enregistrement cesse d’être évalué et tous vos expéditeurs échouent d’un coup.	Publiez un seul enregistrement TXT sur le domaine racine, champ d’hôte @, valeur v=spf1 include:_spf.google.com ~all. Fusionnez tous vos autres expéditeurs dans ce même enregistrement plutôt que d’en ajouter un second. Google recommande ~all plutôt que -all, et précise qu’une modification de SPF peut mettre jusqu’à 48 heures à prendre effet.
DKIM	Inactif pour la plupart des domaines. Google note deux exceptions : un domaine hébergé chez Squarespace voit sa clé créée et ajoutée automatiquement, et un domaine qui dispose déjà de DKIM par défaut ou qui a été acheté auprès d’un partenaire Google à l’inscription peut n’avoir besoin d’aucune configuration. Partout ailleurs, après l’activation de Gmail, il faut attendre de 24 à 72 heures avant que la console d’administration accepte de générer une clé, et tant que vous n’avez pas terminé, la page Authentifier les e-mails affiche « Vous devez mettre à jour les enregistrements DNS de ce domaine ».	Sans votre propre clé, aucune signature ne porte votre domaine, donc DMARC doit passer par le seul SPF. Cela tient jusqu’au premier transfert ou à la première liste de diffusion, qui casse SPF et emporte le résultat DMARC avec lui.	Sous Applications > Google Workspace > Gmail > Authentifier les e-mails, sélectionnez le domaine, gardez le préfixe de sélecteur par défaut google, choisissez la longueur de clé de 2048 bits si votre hébergeur DNS la prend en charge, publiez l’enregistrement TXT sur google._domainkey, puis revenez cliquer sur Démarrer l’authentification (Start authentication). Le statut passe à « Authentification des e-mails avec DKIM » une fois que Google l’a vérifié.
DMARC	Non publié, et Google ne le publiera jamais pour vous.	Gmail exige un enregistrement DMARC de la part des expéditeurs en masse, et Google vous demande d’attendre 48 heures après la mise en place de SPF ou de DKIM avant d’en ajouter un, pour ne pas appliquer une politique contre une authentification qui n’a pas fini de propager.	Publiez un enregistrement TXT sur _dmarc.yourdomain.com, en commençant par v=DMARC1; p=none avec une adresse rua, lisez les rapports agrégés, puis durcissez vers p=quarantine et p=reject. Pointez rua vers un groupe ou une boîte dédiée : Google prévient que les grandes organisations peuvent recevoir des centaines, voire des milliers de rapports par jour.
Additional domains	La page Authentifier les e-mails propose un menu Domaine sélectionné qui liste les domaines de votre compte, et chacun d’eux démarre sans clé propre.	Les équipes génèrent une clé pour le domaine principal, puis envoient depuis un second domaine qui n’en a aucune : chaque message parti de celui-ci échoue à l’alignement DKIM pendant que le domaine principal paraît impeccable.	L’instruction de Google est explicite : si vous configurez DKIM pour plusieurs domaines, reprenez les étapes pour chacun d’eux et obtenez pour chacun une clé DKIM propre dans la console d’administration. Publiez google._domainkey sous chaque domaine depuis lequel vous envoyez, pas seulement sous le principal.

Une fois ces enregistrements mis à jour, vérifiez qu’ils passent avec les outils gratuits d’Unspam : SPF checker, DKIM checker et DMARC checker.

Comment tester une campagne Google Workspace avec Unspam.

Unspam ne se connecte pas à Google Workspace : aucune intégration à l’API Gmail, aucun accès administrateur, et jamais de connexion à votre compte. Vous récupérez une adresse de test, vous lui envoyez un vrai message exactement comme vos destinataires le reçoivent, et Unspam lit ce qui est arrivé. Si vous voulez que le test se répète à intervalles réguliers, vous pouvez fournir des identifiants SMTP pour des tests de placement en boîte de réception automatiques, et c’est le seul identifiant qu’Unspam détienne jamais.

01
Récupérez votre adresse de test et votre ID de test Unspam

Lancez un test antispam ou un test de placement en boîte de réception dans Unspam et copiez l’adresse qu’il génère. Les tests de placement livrent dans des boîtes de test chez Gmail, Outlook, Yahoo et cinq autres fournisseurs, et rapportent où chaque exemplaire a atterri. Un test de placement en boîte de réception génère aussi un ID de test. Vous devez le coller dans l’objet ou dans le corps du message avant l’envoi, sinon le message arrive dans les boîtes de test sans jamais être rattaché à votre test.
02
Envoyez depuis le compte et par la route que vos destinataires voient vraiment

Si le message en cause est celui d’une personne qui écrit depuis Gmail, envoyez-le en tant que cet utilisateur, pas depuis votre compte de super-administrateur, qui a en général d’autres signatures, d’autres groupes et un autre historique. S’il s’agit d’une application, déclenchez l’application pour que le message sorte par l’hôte qu’elle utilise en production, smtp.gmail.com ou smtp-relay.gmail.com. La route change le résultat : le relais laisse une application envoyer sous n’importe quelle adresse de votre organisation, tandis que smtp.gmail.com impose le From du compte authentifié.
03
Lisez les verdicts d’authentification, et regardez le d= de très près

Dans le rapport Unspam, contrôlez les résultats SPF, DKIM et DMARC. Le domaine signataire est le révélateur : si d= pointe vers un sous-domaine de gappssmtp.com plutôt que vers votre propre domaine, vous n’avez jamais terminé les étapes dans la console d’administration, et DMARC repose sur le seul SPF, quand il passe. Le même rapport note le contenu, les liens et les en-têtes, vous voyez donc si l’authentification explique tout ou seulement le début.
04
Lancez le test de placement en boîte de réception pour la vue par fournisseur

Un score de spam vous dit comment un filtre note le message. Un test de placement en boîte de réception vous dit où les exemplaires ont réellement atterri chez les fournisseurs de test, ce qui est la question que vous posiez. La répartition est rarement uniforme : un domaine auquel Gmail fait confiance depuis des années peut très bien être filtré ailleurs, et ce schéma désigne la réputation et le contenu plutôt que votre DNS.
05
Changez une seule chose, attendez, puis retestez

Ici, le DNS est la partie lente. Google indique qu’une modification de SPF peut mettre jusqu’à 48 heures, et que la console d’administration peut continuer d’afficher l’avertissement DNS pendant 48 heures après l’ajout correct de l’enregistrement DKIM. Vérifiez les valeurs publiées avec les outils Dig et Check MX de la Google Admin Toolbox plutôt que de vous fier à la bannière, puis renvoyez un message vers une nouvelle adresse de test. Si votre volume le justifie, ajoutez le domaine à Postmaster Tools et surveillez le taux de spam : Gmail vous demande de le maintenir sous 0,10 % et de ne jamais atteindre 0,30 %.

Le même test affiche votre campagne dans plus de 50 clients de messagerie réels, dont Gmail, Outlook, Apple Mail, iPhone et Android, chacun en mode clair et en mode sombre, grâce aux prévisualisations dans les clients de messagerie, pour confirmer le placement et le rendu en une seule passe.

Les fonctions Google Workspace qui influencent discrètement la livraison.

L’avertissement de la console survit au correctif

La documentation de Google indique elle-même que la page Authentifier les e-mails peut continuer à vous demander de mettre à jour vos enregistrements DNS pendant 48 heures après l’ajout du bon enregistrement TXT, et vous prévient séparément de ne pas cliquer sur Démarrer l’authentification avant que l’enregistrement soit réellement publié. Traitez la bannière comme un élément de décor, pas comme un diagnostic. Confirmez la valeur en ligne avec l’outil Dig de l’Admin Toolbox et lisez l’en-tête Authentication-Results d’un vrai message pour y trouver DKIM=pass.

Une clé de 2048 bits ne tient pas dans une seule chaîne TXT

Le DNS plafonne une chaîne de caractères unique à 255 caractères, et une clé de 2048 bits dépasse cette longueur. La solution de Google consiste à répartir les caractères de la clé sur plusieurs chaînes de texte, chacune entre ses propres guillemets droits, à l’intérieur d’un seul et même enregistrement. Certains panneaux DNS le font pour vous, d’autres refusent la saisie, et d’autres encore l’acceptent puis stockent une valeur tronquée : c’est le pire des cas, parce que l’enregistrement a l’air publié et ne se vérifie jamais. Si votre hébergeur en est vraiment incapable, Google propose l’option 1024 bits pour exactement ce cas de figure.

Le relais SMTP réécrit l’expéditeur d’enveloppe

Google documente que si l’expéditeur n’appartient pas à l’un de vos domaines, le relais remplace l’expéditeur d’enveloppe user@domain_you_don't_own par postmaster@your_domain. Les bounces reviennent alors sur votre adresse postmaster et le Return-Path cesse de correspondre au From. Google signale par ailleurs l’option Toutes les adresses comme déconseillée, parce qu’elle vous rend plus vulnérable aux abus, qu’ils viennent d’un logiciel malveillant présent sur les appareils de vos utilisateurs ou de paramètres SMTP incorrects.

Tester de Workspace à Workspace ne prouve rien

Google le dit sans détour : les consignes aux expéditeurs ne s’appliquent pas aux messages envoyés vers des comptes Google Workspace. Le message que vous adressez à un collègue de votre propre domaine, ou à une autre entreprise sous Workspace, n’est pas noté comme l’est un message adressé à un compte Gmail personnel. Si votre seul test est votre propre boîte de réception, vous testez le seul chemin qui n’allait jamais échouer. Écrivez plutôt à des boîtes de test chez de vrais fournisseurs grand public.

Ce que rencontrent les expéditeurs Google Workspace sur le terrain.

Les problèmes de délivrabilité que les expéditeurs Google Workspace rencontrent le plus souvent, chacun avec la solution qui le règle.

J’ai ajouté l’enregistrement DKIM il y a deux jours et la console d’administration me demande toujours de mettre à jour mes enregistrements DNS. Qu’est-ce que j’ai cassé ?

Deux causes distinctes produisent ce message. La documentation de Google indique qu’il peut persister jusqu’à 48 heures après l’ajout d’un enregistrement correct, donc la console est souvent simplement en retard. L’autre cause est le dernier clic oublié : générer la clé et publier l’enregistrement TXT ne suffit pas en soi, et le statut ne passe à « Authentification des e-mails avec DKIM » qu’après votre retour sur la page Authentifier les e-mails, un clic sur Démarrer l’authentification, et la vérification de l’enregistrement par Google.

La solution Contrôlez l’enregistrement publié directement avec l’outil Dig de la Google Admin Toolbox sur google._domainkey.yourdomain.com, au lieu de vous fier à la console. Envoyez ensuite un message vers une adresse extérieure et lisez l’en-tête Authentication-Results : un DKIM=pass avec un d= réglé sur votre propre domaine signifie que le travail est fait, quoi qu’affiche la bannière. Si l’enregistrement est correct et que Démarrer l’authentification a bien été cliqué, laissez passer les 48 heures.

Mon bureau d’enregistrement refuse la valeur DKIM. Il me répète que l’enregistrement est trop long.

Une clé publique de 2048 bits dépasse le maximum de 255 caractères d’une chaîne DNS unique, donc la clé doit être stockée sous forme de plusieurs chaînes entre guillemets dans un seul enregistrement TXT. Certains panneaux de configuration la découpent pour vous, d’autres refusent la saisie sans discuter, et d’autres encore l’acceptent puis la tronquent en silence, ce qui est le pire des cas : l’enregistrement existe, il a l’air correct dans le panneau, et il ne se valide jamais.

La solution Découpez vous-même la clé en plusieurs chaînes de texte, chacune entre ses propres guillemets à l’intérieur du même enregistrement TXT, ce qui est exactement l’instruction de la page de dépannage DKIM de Google. Vérifiez ensuite avec Dig que ce qui revient correspond caractère pour caractère à la valeur affichée dans la console d’administration. Si votre fournisseur en est vraiment incapable, régénérez la clé en 1024 bits, l’option que Google propose pour les hébergeurs qui ne prennent pas en charge les clés de 2048 bits.

Notre application est censée envoyer les factures depuis billing@ourdomain.com, mais tout arrive depuis le compte administrateur qui a servi à la configurer.

L’application s’authentifie auprès de smtp.gmail.com avec l’adresse d’un utilisateur et un mot de passe d’application. Google documente que, sur ce chemin, l’adresse From doit correspondre au compte authentifié, donc toute autre adresse From est remplacée. Le message est authentifié et remis, il ne vient simplement pas de l’adresse que vos clients attendent, et les réponses atterrissent dans la mauvaise boîte.

La solution Faites passer l’application par le relais SMTP. Dans la console d’administration, allez dans Applications > Google Workspace > Gmail > Routage, configurez le service de relais SMTP, puis réglez Expéditeurs autorisés sur Uniquement les adresses de mes domaines pour que l’application puisse envoyer depuis billing@. Pointez l’application vers smtp-relay.gmail.com sur le port 587 en TLS, et authentifiez-la avec Exiger l’authentification SMTP ou avec l’option N’accepter que les messages provenant des adresses IP spécifiées. Notez que deux pages de Google énoncent différemment le plafond du relais, l’une comme 10 000 messages par utilisateur sur une période de 24 heures, l’autre comme 10 000 destinataires par utilisateur et par jour : dimensionnez vos lots sur la lecture la plus basse.

Gmail nous a coupés pendant une journée en disant que nous avions atteint une limite d’envoi. Nous avions à peine envoyé 600 e-mails.

La limite qui vous a arrêtés n’était probablement pas le nombre de messages. Un compte Workspace payant dispose de 2 000 messages par jour, mais seulement de 3 000 destinataires externes et de 2 000 destinataires externes uniques, et les messages envoyés en SMTP, POP ou IMAP sont limités à 100 destinataires chacun. Une série de 600 messages qui contient des listes de diffusion fait exploser les compteurs de destinataires bien avant le compteur de messages. Les limites se calculent sur une fenêtre glissante de 24 heures, pas sur une journée calendaire, donc rien ne se remet à zéro à minuit.

La solution Comptez les destinataires, pas les envois, et identifiez le compteur que vous avez touché avant de changer quoi que ce soit. Si le volume est réel et récurrent, sortez-le de la boîte de messagerie : le relais SMTP autorise 10 000 messages par utilisateur sur 24 heures, et l’emailing véritable a sa place sur une plateforme faite pour ça. En version d’essai, attendez-vous à 500 messages et 500 destinataires uniques par jour tant que le domaine n’a pas dépensé $100 USD ou l’équivalent, et notez que Google indique que la hausse peut demander jusqu’à 75 jours après ce seuil pour s’appliquer.

DKIM est configuré dans Google Workspace, mais notre newsletter échoue toujours à DMARC.

La clé Workspace ne signe que les messages qui sortent des serveurs de Google. Une newsletter envoyée depuis une plateforme d’emailing ne touche jamais cette clé, donc il lui faut son propre enregistrement DKIM publié sur votre domaine, sur le sélecteur que cette plateforme vous donne. La page de dépannage DMARC de Google vous renvoie précisément pour ce cas à la documentation du tiers. Cela vaut aussi pour les outils d’assistance, les reçus e-commerce, les notifications de CRM et tout ce qui envoie sous votre domaine.

La solution Inventoriez tous les systèmes qui envoient sous votre domaine, puis authentifiez-les un par un : publiez l’enregistrement DKIM de la plateforme sur son propre sélecteur, et fondez son mécanisme SPF dans votre enregistrement SPF unique. Servez-vous des rapports agrégés DMARC reçus à votre adresse rua pour retrouver les expéditeurs que vous avez oubliés, puisque c’est exactement à cela qu’ils servent. Envoyez ensuite un message de test par chaque source vers une adresse de test, pour lire le domaine d= système par système au lieu de le deviner.

La délivrabilité avec Google Workspace, vos questions.

Google signe déjà mes e-mails, alors pourquoi configurer DKIM ?

Parce que DMARC contrôle le domaine signataire, pas la signature. Les messages sortants de Workspace sont signés sur un domaine d’infrastructure de Google, un sous-domaine de gappssmtp.com, et cette valeur d= ne peut jamais correspondre à votre domaine From. Les consignes de Google aux expéditeurs exigent que le domaine de l’en-tête From s’aligne soit sur le domaine SPF, soit sur le domaine DKIM. Générer votre propre clé sous Applications > Google Workspace > Gmail > Authentifier les e-mails est ce qui rend possible la moitié DKIM de cet alignement. Pour savoir où vous en êtes, ouvrez un message que vous avez envoyé et lisez le d= de son en-tête DKIM-Signature.

Que dois-je mettre exactement dans mon enregistrement SPF ?

Si Workspace est votre seul expéditeur, un seul enregistrement TXT sur le domaine racine, champ d’hôte @, valeur v=spf1 include:_spf.google.com ~all. Si vous envoyez aussi par une plateforme d’emailing, un outil d’assistance ou un système de facturation, ajoutez leurs mécanismes dans ce même enregistrement. Ne publiez jamais un second enregistrement SPF sur le même nom, et gardez un œil sur la limite de dix mécanismes include documentée par Google.

L’enregistrement doit-il se terminer par ~all ou par -all ?

Google recommande ~all, qu’il décrit comme demandant aux serveurs de réception de marquer les messages comme spam s’ils viennent de serveurs absents de l’enregistrement. -all demande un rejet pur et simple, ce qui n’est prudent qu’une fois certain que tous vos expéditeurs légitimes figurent dans l’enregistrement. Comme SPF n’est que l’une des deux façons de satisfaire DMARC, le qualificateur strict rapporte moins qu’on ne le croit et coûte plus cher le jour où quelqu’un ajoute un nouvel outil.

Combien de recherches DNS coûte include:_spf.google.com ?

Une seule, vérifié en août 2026. L’enregistrement chaînait autrefois vers _netblocks, _netblocks2 et _netblocks3, et beaucoup de conseils le supposent encore. Aujourd’hui, _spf.google.com répond par un enregistrement unique de plages ip4 et ip6, sans include imbriqué, donc il consomme une seule de vos dix recherches. Vérifiez-le vous-même avant d’aplatir quoi que ce soit sur la foi d’un vieil article de blog, parce que c’est l’enregistrement de Google et que Google peut le changer.

Suis-je un expéditeur en masse si je n’écris qu’à mes clients depuis ma boîte Workspace ?

Seulement à partir de 5 000 messages par jour vers des comptes Gmail personnels, comptés sur votre domaine principal et ses sous-domaines ensemble, et non sous-domaine par sous-domaine. Le plafond de 2 000 messages par jour et par utilisateur rend la chose difficile depuis une seule boîte, et facile à l’échelle d’une équipe ou d’un relais. Google indique que ce statut n’a aucune date d’expiration : une fois franchi, il reste. Et ces exigences ne s’appliquent pas aux messages envoyés vers des comptes Google Workspace.

Unspam peut-il se connecter à mon compte Google Workspace et le tester automatiquement ?

Non. Unspam n’a aucune intégration à l’API Gmail et ne se connecte jamais à votre compte ni à votre console d’administration. Il y a deux points de contact : une adresse de test à laquelle vous envoyez un vrai message et, pour les tests qui tournent à intervalles réguliers, des identifiants SMTP que vous fournissez pour des tests de placement en boîte de réception automatiques. Tout ce que contient le rapport est lu dans le message qui est arrivé. Le palier gratuit couvre 10 tests antispam et 3 tests de placement en boîte de réception par mois, sans carte ; les plans payants démarrent à $9 par mois avec un remboursement sous 14 jours.

Les informations sur la plateforme Google Workspace ont été vérifiées à partir de la documentation publique en août 2026 et ont pu changer depuis. Google Workspace est une marque de son propriétaire respectif. Unspam n’est ni affilié à Google Workspace ni approuvé par Google Workspace.

Testez votre prochaine campagne Google Workspace avant vos abonnés.

Lancer un test de spam gratuit Test d’Inbox Placement