Différences

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

--- pratique:informatique:mail:mail_dns [20/09/2024 07:35] – ↷ Page déplacée de pratique:informatique:mail_dns à pratique:informatique:mail:mail_dns Zatalyz
+++ pratique:informatique:mail:mail_dns [13/10/2025 19:31] (Version actuelle) – [Spécificités GAFAM] Zatalyz
@@ Ligne 1: / Ligne 1: @@
-====== DNS, SPF, DKIM, DMARC et autres choses à configurer sur le mail ======
+====== 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 =====
@@ Ligne 14: / Ligne 18: @@
 ===== DNS, la base =====
-Concernant les déclarations dans le DNS, il faut obligatoirement déclarer les divers relais mail autorisés à gérer l'envoi de nos mails. Et oui, pour éviter les soucis, mieux vaut en avoir au moins deux.
+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.
-<WRAP center round todo 60%>
-À compléter, là je bouge juste les infos de place
+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.
-</WRAP>
+Ç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 =====
@@ Ligne 38: / Ligne 50: @@
     * Le mieux est de commencer avec ''~'' et de voir comment ça passe, puis de mettre ''-'' si les retours sont bons.
-Si l'option initiale ne suffit pas, dans ce que j'ai ici et là qui semble valide...
+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 include:_mailcust.gandi.net a:moi.mondomain.com include:autremail.com ?all"
 "v=spf1 mx -all"
 example.org.             IN  TXT  "v=spf1 a mx ip6:2001:db8::/32 -all"</code>
@@ Ligne 48: / Ligne 61: @@
 Attention, c'est des exemples, une seule de ces lignes dans votre zone DNS ou ça va créer des soucis !
-Plus de doc chez [[https://support.google.com/a/answer/10683907|Google : Définir votre enregistrement SPF (configuration avancée)]].
+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.
-Gandi et Infomaniak permettent de gérer DKIM très simplement. Par contre, en 2023, OVH a toujours du mal avec le concept. Donc OVH n'est pas un bon choix pour le relai de mail !
 ==== En passant par le relai des autres ====
-<WRAP center round todo 60%>
+Gandi et Infomaniak permettent de gérer DKIM très simplement. Par contre, en 2023, OVH avait toujours du mal avec le concept.
-infos à transférer
-</WRAP>
+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 ====
@@ Ligne 238: / Ligne 263: @@
 ===== 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.
@@ Ligne 262: / Ligne 290: @@
     * ''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.
@@ Ligne 271: / Ligne 304: @@
 ===== Champs DNS en plus =====
-Google entre autre veut un enregistrement txt rien que pour lui
+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