Preuve que Google autorise les envois à partir d’un compte gmail.com via un serveur SMTP externe

"Si j'ai une adresse e-mail gmail.com, mes e-mails ne seront-ils pas envoyés dans les spams si mes e-mails "de" gmail.com sont envoyés via SendGrid, Mailgun, Amazon SES ou tout autre serveur qui n'est pas celui de Google ?"

C’est une excellente question et une préoccupation légitime ! Voyons pourquoi ce n’est pas un problème et offrons même la preuve que Google est d’accord – pour l’instant en tout cas.

Vérifions l’enregistrement SPF

Pour comprendre pourquoi cela est acceptable, nous devons comprendre le fonctionnement de SPF, DKIM et DMARC. L’enregistrement SPF de Gmail.com est le suivant :

v=spf1 redirect=_spf.google.com

Puisque cet enregistrement nous demande de regarder un autre enregistrement, l’enregistrement SPF pour _spf.google.com est le suivant :

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

Cela signifie que les courriels dont le MAIL-FROM est gmail.com doivent avoir une IP contenue dans l’un des désignateurs ci-dessus. N’oubliez pas qu’il y a une différence entre l’adresse MAIL-FROM et l’adresse de départ réelle vue par les destinataires du courrier électronique. SPF vérifie uniquement l’adresse MAIL-FROM vue par le serveur, pas par le destinataire.

Supposons maintenant que vous envoyez vos messages par SendGrid ou Amazon SES. Par défaut, lorsque vous envoyez par l’un de ces services, même si votre adresse « from » est [email protected], l’adresse MAIL-FROM est [email protected] ou [email protected]. Comme le MAIL-FROM n’est pas gmail.com, vous êtes toujours en conformité.

Donc pour SPF, vous êtes en conformité.

QUE FAIRE LORSQUE GMAIL NE SE SYNCHRONISE PAS ?

Ok, et pour DKIM ?

Lorsque vous envoyez un e-mail à un ami depuis votre compte gmail.com dans Gmail, la signature DKIM de votre e-mail ressemble à ceci :

DKIM-Signature : v=1 ; a=rsa-sha256 ; c=relaxed/relaxed ;
d=gmail.com ; s=20161025 ;
h=mime-version:from:date:message-id:subject:to ;
bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs= ;
b=f8vKOrTL8SFHtNe4G69kvXGs6xfx2D4whxS8vl0j6rslGIK9INVVCGEDRb4o6fFM6n
BmpkNaAECGCvvf1imZfVjlqaFpM2abkVum+PwKkCugt8KpKEPDGmVuMst8B7gaMvBxvo
BIygX7oIRTKRtraG/Esug0cxPTY8wDDvjXNa9Z/zLGcO7n57V7IzE2hzguYHL4xeLv7q
WsI0NDFDGa23NVlSfX+AdnyCLbSa3tQfhDjafRFglhTL0dAX1x0Nou4QIjN2tD8IS8GQ
YhIlHJzHT4h5bNEcxi2n/JxvjTmmeyw2eGWCy3qvjKey+QfNtxz8e2NFDxaH6RbUCxYB
fDjw==

L’e-mail est signé par le domaine gmail.com, qui est la partie d=gmail.com de ce texte désordonné. Techniquement, ce qui se passe ici, c’est que Gmail prend l’e-mail que vous avez tapé, et le hachure en utilisant une clé privée pour Gmail que seul Google connaît.

Cette clé privée est propriétaire, cachée et conservée sous clé.

Lorsque vous envoyez un e-mail depuis votre compte gmail.com en utilisant SendGrid ou Amazon SES, chacun de ces fournisseurs signe l’e-mail avec son domaine respectif. SendGrid signe les e-mails sortants avec sendgrid.net, et Amazon SES signe les e-mails sortants avec amazonses.com.

Il convient de mentionner que SendGrid et Amazon SES vous permettent de marquer le domaine de signature autour de votre propre domaine si vous le souhaitez ; mais d’emblée, les deux fournisseurs signent les e-mails avec leurs propres domaines afin que les e-mails soient conformes à DKIM dès le départ.

DKIM-Signature : v=1 ; a=rsa-sha256 ; c=relaxed/relaxed ; d=sendgrid.net ;
h=mime-version:subject:from:to:content-type ;
s=smtpapi ; bh=MLOxbqehWaMM2DEWhURrbRF13UbLZJkxWDLneKqUJVY= ;
b=t5iyssLz1OFtFDZ0MRsju381iqwZi0j7vshv3SWscVhwmGw4GZP4o2+bzj6/gugGmkYq
huZ+af3+rqM0/i872nWmp2mOQsOrzwv49ZWb5Pg67x92sGghAHKXBLh7GfteN81qcX2K+3
O+B4Wl8G54VC53AP1YPoRhHDEduizjC+8=
Sujet : Envoi depuis gmail.com via SendGrid
De : Ajay Joel [email protected]
To : Ajay Joel [email protected]

Cela peut prêter à confusion, mais les fournisseurs signant avec leurs propres domaines plutôt que gmail.com sont autorisés, car avec DKIM seul, un courriel peut être signé avec n’importe quel domaine que vous voulez. Bien sûr, il doit s’agir d’un domaine que vous contrôlez, mais il n’est pas nécessaire que le courriel provienne de ce domaine. C’est contre-intuitif, mais il ne s’agit pas nécessairement du domaine figurant dans la ligne MAIL-FROM ou de l’adresse d’origine affichée. Vous pouvez voir que Gmail ajoute un en-tête à l’e-mail reçu pour indiquer que DKIM a été accepté sur la base de la signature utilisant le domaine sendgrid.net :

Authentication-Results : mx.google.com ;
dkim=pass [email protected] header.s=smtpapi header.b=t5iyssLz ;
spf=pass (google.com : le domaine de [email protected] désigne 167.89.100.13 comme expéditeur autorisé) smtp.mailfrom= »[email protected] » ;
dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com

DKIM passe donc.

Vous vous dites peut-être : « Si un e-mail peut être signé avec n’importe quel domaine, en quoi cela le rend-il « authentique » ? Le but initial de DKIM n’était pas d’empêcher le spam ou même de déterminer quels réseaux peuvent envoyer pour quel domaine. Le but de DKIM était de s’assurer que le contenu du courrier électronique n’était pas altéré lors de son transfert de l’expéditeur au destinataire. Il lui suffisait d’avoir accès à la clé de signature privée d’un domaine – tout domaine utilisé dans la partie d= pour signer l’e-mail.

Par la suite, DMARC a permis de faire respecter le domaine dans la signature DKIM en exigeant une correspondance avec le domaine dans l’adresse d’origine affichée. Mais la signature DKIM pure n’exige pas cela.

Si vous avez l’œil, vous remarquerez que dans l’exemple ci-dessus, il est écrit dmarc=fail. C’est un problème, non ? En fait, non ! Lisez la suite…

Enfin et surtout, examinons DMARC.

La partie la plus délicate est de passer DMARC. Vous savez que je viens de dire qu’avec DKIM, vous pouvez signer vos e-mails avec le domaine de votre choix… il n’est pas nécessaire que ce soit l’un des deux domaines « from ». La politique DMARC d’un domaine précise si ces domaines doivent correspondre… c’est ce qu’on appelle « l’alignement ».

La politique DMARC d’un domaine peut spécifier si le domaine SPF doit correspondre à l’affichage du domaine « From », et si le domaine DKIM doit correspondre au domaine « From ». Avec DMARC, l’alignement peut être « relaxé » ou « strict », et s’il n’est pas spécifié, « relaxé » est supposé. L’option « relaxed » signifie toujours que les domaines doivent correspondre, mais elle permet à un sous-domaine de correspondre au domaine racine.

Sans plus attendre, voici l’enregistrement DMARC de gmail.com :

v=DMARC1 ; p=none ; sp=quarantine ; rua=mailto:[email protected]

La partie pertinente à examiner ici est celle qui dit : p=none.

Cela signifie qu’en raison de la présence d’un enregistrement DMARC, l’alignement du domaine détendu est attendu pour que SPF ou DKIM passe DMARC. Maintenant, lorsque vous envoyez par SendGrid ou Amazon SES avec leurs configurations par défaut de domaine sans marque, l’alignement de domaine ne passera pas pour SPF ou DKIM, DMARC échouera. MAIS, comme l’enregistrement contient p=none, Google demande aux serveurs de NE PAS sanctionner l’e-mail à cause de cela.

Donc, vous l’avez. Vous pouvez envoyer des messages « à partir » de votre compte gmail.com via un fournisseur tiers comme SendGrid et Amazon SES. SPF et DKIM passeront. DMARC échouera, mais cela n’aura pas d’importance car l’enregistrement DMARC de gmail.com indique de ne prendre aucune mesure pour les échecs DMARC.

Dans ce cas, quels sont les services SMTP qui vous permettent d’envoyer des messages « à partir » de votre compte gmail.com ? Nous avons récemment procédé à un examen technique exhaustif, et voici les services SMTP qui vous permettront d’envoyer des messages à partir de votre compte Gmail : SendGrid, Mailgun, Mailjet, Sendinblue, SMTP.com, SMTP2Go et Amazon SES. Deux fournisseurs, SocketLabs et Mandrill (qui fait partie de MailChimp), ne vous permettront PAS de le faire.

Mais allez-vous toucher la boîte de réception ?

Si vous êtes un spécialiste du marketing par e-mail ou de l’envoi d’e-mails à froid, c’est tout ce qui compte vraiment. Mes tests montrent que c’est généralement le cas. Google contrôle environ la moitié des boîtes de réception d’e-mails dans le monde, et c’est la plate-forme sur laquelle j’ai le plus testé la délivrabilité. Dans quelques tests que je viens d’effectuer, les e-mails envoyés depuis mon compte gmail.com ont atteint la boîte de réception de mon compte G Suite.

envoyer via SendGrid

Notez que l’e-mail est envoyé « via sendgrid.net ». C’est normal. Il existe des conditions qui entraînent l’apparition de la balise « via » à côté du nom de l’expéditeur, mais cette désignation est inoffensive.

Pour savoir si Gmail place les e-mails dans le dossier Boîte de réception, Promotions ou Spam, il ne suffit pas de passer quelques contrôles simples, et il ne suffit certainement pas de savoir si l’e-mail provient de Gmail lui-même ou d’un serveur externe. Google utilise un algorithme complexe d’apprentissage automatique basé sur l’IA qui analyse des millions de facteurs pour prendre cette décision.

Parfois, le destinataire peut également voir cette désignation en haut du message, mais d’après notre expérience, même cette désignation ne modifie pas le placement dans la boîte de réception ou dans le spam :

avertissement par courriel

Quelle est la conclusion, alors ?

Les expéditeurs sont souvent gênés par les limites d’envoi quotidiennes de Gmail. Cependant, d’après notre expérience, les expéditeurs qui déploient des courriels recherchés vers des destinataires peuvent les envoyer à partir de leur compte gmail.com via des serveurs SMTP externes, ce qui leur permet d’envoyer plus de courriels qu’ils ne pourraient le faire via leur compte Gmail.