Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:mail:mail_dns [20/09/2024 07:35] – supprimée - modification externe (Unknown date) 127.0.0.1
+++ pratique:informatique:mail:mail_dns [13/10/2025 19:31] (Version actuelle) – [Spécificités GAFAM] Zatalyz
@@ Ligne 1: / Ligne 1: @@
+====== SPF, DKIM, DMARC et autres choses à configurer sur le mail côté DNS ======
+Qu'on délègue une grande partie ou qu'on fasse tout soi-même, il faut paramétrer diverses choses dans le DNS afin que les mails puissent être envoyés, reçus, et passer les filtres antispam.
+<WRAP center round info 60%>
+Afin d'assurer la meilleure délivrance possible, il vaut mieux "plus" que moins. Chaque acteur va vérifier des choses spécifiques, certaines n'étant pas dans les standards (comme Google qui demande un champ texte spécifique). Avoir ces champs limite le classement en spam du serveur mail, sans suffire totalement car d'autres paramètres entrent aussi en compte.
+</WRAP>
+===== Relai et domaine, deux choses différentes =====
+Il y a un concept important à bien comprendre, la différence entre le nom de domaine associé au mail (pour l'exemple, ''mondomaine.org'', qui sera associé à l'adresse mail ''moi@mondomaine.org'') et le domaine lié à la machine autorisée à gérer réellement les envois et réceptions de mail (ici, ''relai.org''). Certaines choses sont à paramétrer sur le domaine associé au mail, d'autres concernent uniquement le relai.
+Tout ce qui concerne la vérification de l'identité dans le DNS (mesures anti-spoofing) est toujours associé au domaine du mail (''mondomaine.org'') et non au relai ! Donc, SPF, DKIM, DMARC entre autre (mais il y en a d'autres et je complèterais à mesure...).
+Bien configurer SPF, DKIM, DMARC va nous donner une bonne déliverabilité chez la majorité des acteurs (oui, même les gros). Cela ne suffit pas pour tout, mais ça aide vraiment. Accessoirement cela rend plus difficile à un acteur malveillant de se faire passer pour “nous”, alors pas de raison de s'en priver.
+Et puis c'est vraiment faisable quand on gère soi-même toute la chaîne. Ça va bien se passer… tant que je ne perds pas la doc !
+===== DNS, la base =====
+Concernant les déclarations dans le DNS, il faut obligatoirement déclarer les divers relais mail (champ MX) autorisés à gérer l'envoi de nos mails. Et oui, pour éviter les soucis, mieux vaut en avoir au moins deux.
+Si on passe par un relai de son fournisseur de domaine (OVH par exemple) c'est généralement déjà rempli par défaut.
+Ça va ressembler à ça :
+<code>@
+        IN MX     5 mx2.mail.ovh.net.
+        IN MX     100 mx3.mail.ovh.net.
+        IN MX     1 mx1.mail.ovh.net.
+</code>
+  * Source pour OVH : https://help.ovhcloud.com/csm/fr-dns-configure-mx-dns-zone?id=kb_article_view&sysparm_article=KB0051707
+===== SPF =====
+On peut indique des ip, des noms de domaine... Je trouve le nom de domaine plus versatile et ça suffit.
+  @ IN TXT 10800 "v=spf1 mx a include:relai.org -all"
+  * ''@'' : ça va concerner l'ensemble du domaine, mais attention pas les sous-domaines. Sinon il faut déclarer un sous-domaine précis.
+  * ''TXT'' : type d'enregistrement DNS (obligatoirement ça)
+  * ''v=spf1 '' indique qu'on va parler de SPF
+  * ''mx'' : autorise les enregistrement MX du domaine sur lequel SPF est paramétré
+  * ''a'' : autorise les serveurs de messagerie du nom de domaine. On peut indiquer un nom de domaine spécifique
+  * ''include:...'' : là autant mettre son relai SMTP pour être sûr que ce soit pris en compte ? On peut en indiquer plusieurs et donc déléguer sa confiance aux enregistrements SPF de ces autres serveurs. Ça donne ce genre d'option : ''v=spf1 include:relai.domain1.net include:mail.domain2.org ~all''
+  * ''all'' : indique quelle correspondance les messages doivent avoir . Ce paramètre est forcément à la fin.
+    * ''?'' : neutre : on n'approuve ni ne refuse rien, c'est juste déclaratif.
+    * ''~'' : échec partiel possible : les serveurs de réceptions peuvent accepter les mails d'expéditeurs qui ne sont pas dans l'enregistrement SPF mais les noter comme suspects. En plus clair : peut-être qu'on s'est fait spoofer ou peut-être qu'on a pas été doué en envoyant un mail légitime d'un endroit mal paramétré.
+    * ''-'' : échec, les mails en question risquent plus de finir dans le spam car ils ne sont définitivement pas authentifiés.
+    *  ''+'' : c'est la fête du slip, si je comprends bien ? On évite cette option, autant ne rien mettre. C'est d'ailleurs le truc "par défaut" : on dit que "dans le doute, toutes les ip sont légitimes à envoyer des mails". Ça fait désordre.
+    * Le mieux est de commencer avec ''~'' et de voir comment ça passe, puis de mettre ''-'' si les retours sont bons.
+Plus de doc chez [[https://support.google.com/a/answer/10683907|Google : Définir votre enregistrement SPF (configuration avancée)]].
+==== Examples ====
+<code>
+"v=spf1 include:_mailcust.gandi.net ?all"
+"v=spf1 mx -all"
+example.org.             IN  TXT  "v=spf1 a mx ip6:2001:db8::/32 -all"</code>
+Attention, c'est des exemples, une seule de ces lignes dans votre zone DNS ou ça va créer des soucis !
+Sur OVH, par défaut :
+  "v=spf1 include:mx.ovh.com ~all"
+Sur Gandi :
+  "v=spf1 include:_mailcust.gandi.net ?all"
+Si on utilise le mail sur le domaine principal (exemple.com) et des sous-domaine (moi.exemple.com), et OVH, et un service tiers (autremail.com). Oui, on peut...
+"v=spf1 include:mx.ovh.com a:moi.mondomain.com include:autremail.com ~all"
+===== DKIM =====
+DKIM est LE point compliqué : cela demande de générer une clé sur le serveur de relai. Donc, DKIM dépend entièrement du bon vouloir du service.
+==== En passant par le relai des autres ====
+Gandi et Infomaniak permettent de gérer DKIM très simplement. Par contre, en 2023, OVH avait toujours du mal avec le concept.
+Chez Gandi c'était((Cette info datant d'avant le rachat, je ne saurais dire si c'est encore valable.)) tout automatique, suffit de cliquer sur le bon bouton : [[https://news.gandi.net/fr/2021/05/protegez-la-reputation-de-votre-nom-de-domaine-avec-dkim/|Protégez la réputation de votre nom de domaine avec DKIM]].
+Chez OVH, je vous laisse survivre à la doc sur le sujet : [[https://help.ovhcloud.com/csm/fr-dns-zone-dkim?id=kb_article_view&sysparm_article=KB0058101]] mais visiblement c'est possible à présent ?
+  * [[https://support.google.com/a/topic/2752442|Doc Google : Authentifier les e-mails avec DKIM]]
+==== Quand on a son propre relai ====
+DKIM m'aura filé des boutons... Espérons que tout est noté proprement.
+Je préfère passer par Opendkim plutôt que Rspamd. Ce dernier gère trop de choses, plante, a une configuration bien touffue, bref j'ai eu vraiment des soucis, donc on va séparer un peu ; ce serait abusé de dire qu'on va vers du KISS vu la complexité des bouzins mais... on essaie un peu.
+<WRAP center round info 100%>
+Pour la génération de la clé, comme indiqué [[https://poolp.org/posts/2019-12-23/mettre-en-place-un-serveur-de-mail-avec-opensmtpd-dovecot-et-rspamd/|ici]], si on s'amuse à faire plus grand que 1024 bit, il faudra faire deux enregistrements MX et prendre le risque que certains gros fournisseurs de mails ne sachent pas quoi en faire. (Info à vérifier en 2023, mais dans le doute...)
+Il est aussi possible de générer une clé ed25519, mais elle n'est pas prise en compte chez plein de fournisseurs mails et fera donc échouer la vérification DKIM ([[https://rspamd.com/doc/modules/dkim_signing.html#dkim-key-management|source]]).
+Oui, c'est ridicule, mais... L'objectif de paramétrer DKIM est que notre courrier soit distribué au mieux, alors on ne cherche pas. Avec la trinité SPF/DKIM/DMARC ce n'est quand même pas si simple de se faire usurper, même avec une clé faible sur DKIM. On peut espérer qu'avant que ça devienne un vrai souci, les fournisseurs passeront à des clés plus correctes.
+Au passage, il faudra que je vérifie, de mon côté, que j'accepte bien les clefs RSA en deux parties et les clés ed25519...
+</WRAP>
+Avant tout : on va mettre toute la configuration dans un dossier.
+  sudo mkdir -p /etc/opendkim/dkimkeys
+On créera autant de dossier que de domaines. Oui c'est un peu lourd mais ça simplifiera la gestion plus tard.
+  sudo mkdir /etc/opendkim/dkimkeys/mondomaine.org
+Et s'assurer des bons droits sinon ça ne va pas aller.
+  sudo chown -R opendkim: /etc/opendkim/
+On va commencer par générer la clé, en tant qu'user ''opendkim''.
+  sudo -u opendkim opendkim-genkey -D /etc/opendkim/dkimkeys/mondomaine.org -d mondomaine.org -s dkim23 -b 1024
+  * ''sudo -u opendkim'' : la clé sera créée directement avec les bons droits.
+  * ''opendkim-genkey'' : c'est la commande ; ''man opendkim-genkey'' donne plus d'options :)
+  * ''-D /etc/opendkim/dkimkeys/mondomaine.org'' : dossier où les clés seront stockées. Sur ''/etc/'' c'est bien vu qu'on sauve tout dans les backups.
+  * ''-d mondomaine.org'' : à adapter à son domaine (de premier niveau ! pas le sous-domaine du relai !)
+  * ''-s dkim23'' : le "sélecteur" (selector in english). En fait, si j'ai bien compris, le petit surnom donné à la clé pour pouvoir les repérer entre elles. Du coup c'est pertinent de mettre par exemple la date (sous une forme ou une autre) pour pouvoir repérer la plus vieille si on change. Ce nom va apparaître dans le champ DNS. On peut bien mettre n'importe quoi en fait ; la plupart des sysadmins ne se prennent pas la tête et mettent "dkim" (option par défaut sur rspamd).
+  * ''-b 1024'' : la taille de la clé, en bit. Debian met par défaut en 2048 (bien qu'upstream, opendkim reste en 1024). Les deux options sont fonctionnelles, voir la note plus haut. C'est vraiment un choix à faire, suivant où on place le risque (se faire distribuer/se faire usurper).
+Générez autant de clés que de domaines autorisés à envoyer des mails en leur nom.
+S'assurer aussi qu'elles ont les bons droits :
+  sudo chmod 640 /etc/opendkim/dkimkeys/example.org/default.private
+  sudo chmod 644 /etc/opendkim/dkimkeys/example.org/default.txt
+On va ensuite modifier ''/etc/opendkim.conf'' et s'assurer que certains paramètres sont bien renseignés.
+<WRAP center round todo 60%>
+Là je vais copier ma version, commentée, ne me souvenant plus de ce que c'était par défaut.
+</WRAP>
+<code bash /etc/opendkim.conf>
+# Active les logs. L'option LogWhy permet plus de verbosité, à réserver au débugage.
+Syslog                  yes
+SyslogSuccess           yes
+#LogWhy                 no
+# Comment les mails sont signés. Ma politique n'est pas des plus strictes mais dans mon cas ça devrait être adapté.
+Canonicalization        relaxed/simple
+Mode                    sv
+SubDomains              yes
+OversignHeaders         From
+# La partie à adapter et modifier ! La plus importante ! Mais... On va avoir du multidomaine, donc ici c'est juste en backup (ou si vous n'avez qu'un domaine). Décommentez Keyfile dans ce cas.
+Domain                  mondomain.org
+Selector                dkim23
+#KeyFile         /etc/opendkim/dkimkeys/dkim23.private
+# Permissions et user ; ne pas bidouiller sans savoir
+UserID                  opendkim
+UMask                   007
+# Cette partie est si on a plusieurs domaines. On va avoir des fichiers à parser pour voir la concordance clé/domaine.
+# L'option "refile" plutôt que "file" indique que les expressions régulières doivent être interprétées.
+# Fichier qui indiquera où sont les clés
+KeyTable                 refile:/etc/opendkim/KeyTable
+# Fichier pour dire comment utiliser ces clés
+SigningTable                 refile:/etc/opendkim/SigningTable
+# Hôtes pour qui les mails seront signés. Là, il y a une subtilité ; on va donc les déclarer dans un fichier annexe.
+InternalHosts           refile:/etc/opendkim/TrustedHosts
+# Pour qu'on ne signe pas des trucs qui ne viennent pas du bon endroit ?
+ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
+# Socket pour le MTA, Postfix dans notre cas, qui marche avec celui-ci.
+Socket                  inet:8891@localhost
+PidFile                 /run/opendkim/opendkim.pid
+# The trust anchor enables DNSSEC. In Debian, the trust anchor file is provided
+# by the package dns-root-data.
+TrustAnchorFile         /usr/share/dns/root.key
+# permettre un redémarrage automatique, mais pas trop vite non plus pour ne pas se bloquer
+AutoRestart             Yes
+AutoRestartRate         10/1h
+</code>
+Par défaut Opendkim a sans doute généré ''/etc/opendkim-trustedhosts.conf''. On va copier ça dans ''/etc/opendkim/TrustedHosts'' et déclarer le localhost (en principe par défaut mais ça va mieux en le disant ?), l'ip sur le réseau local et l'ip publique du serveur. Si on oublie la dernière, les mails envoyés par le système seront signés, mais pas ceux envoyés depuis Thunderbird... potentiellement c'est aussi là qu'il faudrait mettre l'ipv6 ?
+Chez moi ça ressemble à ça (j'ai gardé les ip locales par défaut aussi...) :
+<code>127.0.0.1
+.168.0.0/16
+.0.0.0/8
+.16.0.0/12
+# IP sur le réseau local
+.168.1.85/24
+# IP publique
+.190.XXX.XXX
+</code>
+=== Multidomain ===
+Si on a déclaré quelques fichiers... il va falloir les remplir.
+<code txt /etc/opendkim/KeyTable>
+dkim23._dkim.example.org example.com:dkim23:/etc/opendkim/dkimkeys/example.org/dkim23.private
+</code>
+Ajouter autant de ligne que de domaines, potentiellement en adaptant la partie selector (et évidement le nom de domaine).
+Puis l'autre fichier sur comment utiliser les clés. Cela permet plus précisément de dire "tel domaine doit utiliser tel type de sélecteur". On peut même affiner par utilisateur.
+<code txt /etc/opendkim/SigningTable>
+*@example.org dkim23._dkim.example.org
+bob@example2.com dkim23._dkim.example2.com
+</code>
+Enfin, dans ce cas, mieux vaut encore affiner TrustedHosts. Les domaines déclarés ici, puisqu'ils sont référencés à la fois avec InternalHosts et ExternalIgnoreList, seront donc considérés comme interne et DKIM signera leur courrier sortant.
+<WRAP center round help 60%>
+Un petit doute si c'est pertinent... Je sens qu'on va avoir des trucs bizarres avec ça.
+</WRAP>
+=== Finitions ===
+On recharge :
+  service opendkim restart
+Et on configure postfix en ajoutant ceci :
+<code bash /etc/postfix/main.cf>
+#Antispam et DKIM
+milter_default_action = accept
+smtpd_milters = inet:localhost:8891
+non_smtpd_milters = $smtpd_milters
+milter_protocol = 6
+milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
+internal_mail_filter_classes = bounce
+</code>
+On recharge :
+  service postfix restart
+Ensuite, la zone DNS. Toutes les infos sont avec ''cat /etc/opendkim/dkimkeys/mondomaine.org/dkim23.txt'', il suffit de copier ce qu'il faut dans un champ txt. Sur OVH, restez bien en txt, en essayant d'ajouter un champ "DKIM" je n'ai pas rencontré un franc succès.
+La clé publique devrait renvoyer quelque chose comme ça :
+dkim23._domainkey	IN	TXT	( "v=DKIM1; h=sha256; k=rsa; "
+	  "p=MIIBIouquecestlongcetteclé" )  ; ----- DKIM key 2023 for mondomaine.org
+Et l'enregistrement DNS ressemblera à quelque chose comme ça :
+  dkim23._domainkey IN TXT "v=DKIM1; h=sha256; k=rsa; "p=MIIBIouquecestlongcetteclé"
+<WRAP center round tip 60%>
+On peut déclarer plus de choses dans le DKIM. Et ça serait sans doute mieux. Mais, là, ça me gonfle, alors ça ira jusqu'à ce que les mails soient refusés.
+</WRAP>
+<WRAP center round important 60%>
+Bien attendre la propagation du DNS avant de s'inquiéter. Je conseille https://dnschecker.org/dkim-record-checker.php ; attention les tests sur le DNS ne prennent pas tous DKIM en compte, pas besoin de s'inquiéter trop vite, suffit de prendre le bon outil ou sa bonne option !
+</WRAP>
+Et on s'envoie quelques mails pour tester.
+Sources :
+  * https://wiki.debian.org/opendkim
+  * https://www.malekal.com/installer-configurer-postfix-spf-dkim-dmarc/
+  * https://serverfault.com/questions/966176/opendkim-postfix-sign-console-sent-mail-but-not-from-a-mail-client-smtp
+  * https://www.stevejenkins.com/blog/2011/08/installing-opendkim-rpm-via-yum-with-postfix-or-sendmail-for-rhel-centos-fedora/
+===== DMARC =====
+<WRAP center round important 60%>
+Attention ! DMARC doit être activé uniquement si DKIM et SPF sont fonctionnels, sinon ça ne marchera pas !
+</WRAP>
+Après les options compliquées à comprendre avec SPF et DKIM, DMARC parait facile. Oui mais... pour qu'il marche bien, il faut que les deux autres soient fonctionnels, sinon certains fournisseurs (dont Google) vont le classer en non valide.
+Les autres fournisseurs de mail envoient un rapport quotidien de vos échanges avec eux. Cela fait pas mal de bruit et on pourrait être tenté d'envoyer ça dans le vide, mais en cas de souci de distribution, cela peut donner quelques indices.
+Le champ dmarc va ressembler à ça si on est strict :
+  _dmarc 10800 IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:admin@mondomaine.org "
+Et ceci si on ne veux pas trop de soucis dans un premier temps :
+  _dmarc 10800 IN TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:admin@mondomaine.org "
+  * ''v='' : indique qu'on utilise DMARC, faut pas chercher. Paramètre obligatoire.
+  * ''p'' : indique la politique à appliquer si DMARC n'est pas bon. Paramètre obligatoire.
+    * ''none'' : ne rien faire. C'est souvent la première option à mettre le temps de vérifier que tout roule.
+    * ''quarantine'' : sera envoyé au dossier "spam" du destinataire. Il aura quand même les messages au besoin.
+    * ''reject'' : les messages ne seront pas distribués. À faire quand on est sûr de soi.
+  * ''adkim'' : précise s'il faut vérifier la concordance avec DKIM, de façon plus ou moins strict
+    * ''s'' : strict.  Le nom de domaine de l'expéditeur doit correspondre exactement à ce qui est déclaré dans DKIM sinon le message doit être rejeté.
+    * ''r'' : "relaxed" (souple). Permet que ça corresponde "mais pas exactement", c'est à dire si ça vient d'un des sous-domaine, le message peut être accepté (mais classé dans les spams ?).
+  * ''aspf'' : idem avec SPF.
+    * ''s'' : strict. L'en-tête De du message doit correspondre exactement au nom de domaine de la commande SMTP "MAIL FROM".
+    * ''r'' : "relaxed" . Autorise les correspondances partielles et tous les sous-domaines sont acceptés.
+    * ''rua=mailto'' : le mail à qui envoyer les rapports. Ayez une adresse dédiée pour ce genre de bordel de sysadmin, avec de bons filtres et des règles pour vider les messages trop vieux. On peut envoyer à plusieurs adresses mais qui veut faire ça ?
+Un exemple simple avec Gandi (modifiez mail@mondomain.com par l'adresse sur laquelle recevoir les rapports) :
+  "v=DMARC1; p=reject; rua=mailto:mail@mondomain.com"
+Voir https://support.google.com/a/answer/2466563#dmarc-record-tags pour plus de détails.
+==== Lire les rapports ====
+C'est du xml et un peu obtus, comme ça.
+Je teste [[https://github.com/gene-git/dmarc_report]] pour une analyse en local. C'est plutôt lisible, effectivement. Mais ça serait intéressant de voir comment automatiser la lecture des rapports et avoir des stats au fil du temps (bref, ce que propose des acteurs pros... sauf que je ne veux pas confier ça à des externes).
+===== Champs DNS en plus =====
+C'est plus "facultatif" mais comme dit en introduction, ce genre de détail contribue à avoir un mail bien délivré.
+==== Spécificités GAFAM ====
+Là, on va rentrer surtout chez les acteurs vers qui on envoie. Chercher "postmaster Nom_du_Service" permet parfois de trouver le lien vers le service en question !
+Il faut souvent leur déclarer nos serveurs mails, les relais utilisés suivant les noms de domaines.
+=== Google ===
+Google utilise un outil ([[https://postmaster.google.com]]) qui va offrir des rapports sur la façon dont nos mails sont géré par eux. Au passage, les petits sagouins en profitent pour ajouter une validation, ils donnent un champ TXT à ajouter dans le DNS pour valider que le domaine est à nous.
+Nul doute que ce genre de détail aide aussi à la délivrance des mails.
+=== Microsoft ===
+https://sender.office.com si on est en spam, mais il semblerait qu'au delà de ça, ça permette de se faire reconnaitre aussi par eux, même en amont ?
+https://sendersupport.olc.protection.outlook.com/pm/Postmaster a d'autres infos.
+=== Yahoo ===
+Ils [[https://senders.yahooinc.com/|semblent avoir un truc]], mais faut un compte Yahoo, et vu qu'ils banissent même les vieux comptes, et bien je ne sais pas comment je testerais. Mais cet acteur n'étant pas trop utilisé en France, j'imagine que c'est secondaire.
+=== Mail.ru ===
+Idem, vos correspondants communiquent-ils avec le géant russe ? Si non, on peut donc s'en passer. Si oui il semblerait que l'adresse soit [[https://postmaster.mail.ru]].
+=== Orange ===
+Leur doc/outil est ici : https://postmaster.orange.fr
+=== La Poste ? ===
+J'ai un doute. Pas essayé :P
+https://postmaster.laposte.net
+=== Free ===
+https://postmaster.free.fr
+==== Les trucs qu'il faut que je creuse ====
+  * https://en.wikipedia.org/wiki/Category:Email_authentication
+  * MTA-STS (Mail Transfer Agent Strict Transport Security) : impose un chiffrement pour la transmission entre les serveurs mails.
+    *  TLS-RPT (TLS Reporting) : envoie des rapports s'il y a échec de connexion TLS avec le protocole précédent
+  * [[https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_Identification|Brand Indicators for Message Identification]] (BIMI) : ça semble super gadget mais c'est potentiellement un truc que les GAFAM regardent et classent comme "plus sérieux" si c'est présent. Demande à bien vérifier quand même...
+    * Mais ça va rapidement avec le fait d'avoir une marque "enregistrée" et... comment dire... https://bimigroup.org/verified-mark-certificates-vmc-and-bimi/
+  * Enregistrement CAA ? Pour préciser qui a le droit d'émettre un certificat SSL/TLS pour le domaine, mais comme de toute façon j'utilise Let's Encrypt, pas sûr que la contrainte soit énorme.
+  * Enregistrement Autodiscover : ça faut vraiment que je creuse... permet à Thunderbird de remplir tout seul la partie du relai quand on ajoute un compte.
+  * DANE (alternative/complément à MTA-STS), s'appuie sur DNSSEC (un autre truc qu'il faut que je creuse).
+Par ailleurs, faut aussi creuser "ARC", mais ça ne se joue pas côté DNS, c'est sur le relai.
+===== Plus de sources et outils =====
+  * [[https://support.google.com/mail/answer/81126|Empêcher le blocage ou le placement dans le dossier "Spam" des messages envoyés aux utilisateurs Gmail]] : la doc de google est étonnamment bien.
+  * Google :
+    * [[https://toolbox.googleapps.com/apps/checkmx/]] : test du nom de domaine par Google
+    * [[https://transparencyreport.google.com/safe-browsing/overview]] : État des soucis sur le nom de domaine répertorié par Google (la réputation de notre nom de domaine chez eux)
+  * [[https://www.mail-tester.com/]] : envoyer un email à une adresse qui va vérifier sa conformité face à plein de paramètres
+  * https://mxtoolbox.com : divers outils de vérification de la qualité du mail
+{{tag>Mail DNS DKIM DMARC SPF}}
+[[https://creativecommons.org/publicdomain/zero/1.0/deed.fr|{{ https://liev.re/imagesweb/licences/cc-zero.png?100 | Ce texte est placé sous licence CC0}}]]