Bonjour,
Concernant DMARC :
Ce ne sont pas vraiment des problèmes, DMARC est par défaut non bloquant afin de ne pas perturber le mode de fonctionnement du client si celui-ci envois par exemple des mails depuis un autre service ou si le domaine n'est pas réputé pour être usurpé.
Par défaut chez FSH, le DMARC est défini ainsi dans la zone DNS :
C'est-à-dire avec une "policy" (p) à "none" donc non actif.
Voici les 3 policy possibles pour DMARC :
- policy "none" : Vous voulez juste surveiller les résultats DMARC et vous ne voulez pas prendre des mesures spécifiques sur tous les emails défaillants. Vous pouvez utiliser la politique «none» pour commencer avec DMARC et rassembler tous les rapports DMARC et commencer à analyser ces données.
- policy "quarantine" : Vous mettez les emails qui échouent aux vérifications en quarantaine. La plupart de ces emails se retrouveront dans le dossier de courrier indésirable du destinataire
- policy "reject" : Vous pouvez rejeter tous les emails qui échouent aux vérifications DMARC. Les destinataires doivent le faire «au niveau SMTP». Les emails seront rejetés directement dans le processus d’envoi.
Les modes d'alignement "sdkim" et "aspf" sont par défaut en "Relaxed" (r) mais comme la "policy" (p) n'est pas active (none) rien ne s'applique.
Il est possible de faire du "rua", du "ruf" et du "rf" pour recevoir les alertes par mail mais c'est facultatif, c'est selon son souhait.
Il existe un certain nombre de paramètres pour configurer son DMARC, voici la FAQ sur le site officiel :
https://dmarc.org/wiki/FAQ ainsi que le lien sur les tag reconnus par le consortium Internet et les RFC :
https://dmarc.org//draft-dmarc-base-00- ... dmarc_tags
Pour résumer, voilà un début de configuration possible :
Tag Requise Infos
v required Version de protocole : v=DMARC1
p required Politique pour domaine,
example : p=quarantine
pct facultative % de messages soumis à un filtrage,
exemple : pct=20
rua facultative Rapporter l’URL des rapports cumulés
example : rua=mailto:
example@example.com
ruf facultative Les adresses auxquelles les informations légales
spécifiques du message doivent être rapportées
(liste d’URI en texte clair séparées par des virgules)
example ruf=mailto:
example@example.com
rf facultative Format à utiliser pour les rapports d’informations
légales spécifiques du message (liste de valeurs en
texte clair séparées par des virgules).
example : rf=afrf
aspf facultative Mode d’alignement pour SPF, example : aspf=r
adkim facultative Mode d’alignement pour DKIM, example : adkim=r
Attention car un DMARC incorrectement configuré peut bloquer la réception des mails ou se voir être envahi de mails d'alertes.
Concernant la différence entre les NS :
Ceux définis dans la zone DNS et ceux définis chez votre revendeur de domaine Gandi n'ont pas la même extension mais il n'y a aucune incidence car le .COM et le .FR (ainsi que les autres extensions) des domaines de FSH pointent sur les 2 mêmes des adresses IP des serveurs DNS. (voir les 4 IP en comptant les IPv6).
Pour le côté esthétique et supprimer cette "alerte", vous pouvez remplacer chez Gandi le .COM en .FR dans les NS mais ça fonctionnera pareil.
Concernant le "Same Subnet" pour les DNS :
C'est également normal et c'est à mettre en corrélation avec la stabilité des serveurs DNS de son prestataire, ceux de FSH sont très stables. J'estime qu'il est inutile de vouloir utiliser plusieurs réseaux pour ses DNS si l'on n'a pas plusieurs hébergeurs différents pour son site Internet. Après vous pouvez en utiliser plus que 2 mais il va vous falloir gérer ça de votre côté vous-même avec un risque d'erreurs possibles.