Sécurisations et normes email

From

Sécurisations et normes email

La réception et la sécurisation des emails se fait principalement par des règles DNS présentes pour votre domaine.

MX: Serveur de réception des emails

La réception des emails ne peut se faire que si une entrée de type "MX" est présente dans la zone DNS du domaine. Cette entrée MX correspond au serveur SMTP de réception de mails. Le MX est par convention un nom canonique et non une adresse IP.


Exemple:

Soit le domaine "monsite.tld" dont les emails sont hébergés chez LRob sur le serveur ds.lrob.net

  • Nous pouvons ajouter un sous-domaine et l'assigner en MX
mail A 138.201.17.216
MX 0 mail.monsite.tld

Sécurité

Bien que les normes relatives aux emails parviennent difficilement à être universalisées, quelques standards sont de plus en plus utilisés afin de :

  • Diminuer la réception de spams
  • Limiter au maximum l'usurpation d'identité

HELO

Le "HELO" est le message de présentation envoyé par un serveur SMTP. Afin d'atteindre un niveau de confiance correct, ce HELO doit répondre à plusieurs critères :

  • Il doit être un FQDN (nom de domaine ou sous-domaine) valide, pointant vers l'IP du serveur SMTP envoyant le mail
  • Ce nom doit être identique correspondre au rDNS (reverse DNS) de l'IP du serveur SMTP.
  • Ce rDNS ne doit PAS être sous la forme par défaut IPReversed.provider.tld car un serveur SMTP n'ayant pas un rDNS personnalisé a de fortes propensions à être un botnet émettant du spam.

En somme il faut choisir un nom (en général le nom d'hôte de la machine contenant le serveur SMTP), mettre ce nom en reverse DNS de l'IP du serveur, et demander au serveur de mails d'indiquer ce nom en HELO.

Un mail ne répondant pas à ces critères est généralement considéré comme spam.

Nos serveurs sont configurés pour rejeter les emails n'ayant pas un HELO correct, car cela est le minimum à respecter lorsque l'on envoie un email. Si l'expéditeur n'est pas en mesure de corriger sa configuration, nous pouvons en dernier recours whitelister son adresse pour que vous receviez ses emails, mais cela anihile alors toute possibilité de vérification de l'authenticité de l'expéditeur, c'est donc extrêmement non recommandé.

LRob met tout en oeuvre pour fournir un HELO correct et ainsi permettre la meilleure délivrabilité de vos mails. Tout mail envoyé par votre serveur LRob est configuré pour posséder un HELO correct. Si vous détectiez toutefois une anomalie à ce niveau, n'hésitez pas à nous contacter par ticket support.


SPF (Sender Policy Framework)

SPF permet de définir les serveurs habilités à relayer les emails d'un domaine. Cette règle est présente sous forme de règle TXT dans la zone DNS du domaine. Cela permet d'éviter qu'une tierce personne envoie des emails à votre nom. Cela signifie également qu'il faut utiliser un serveur habilité à vous authentifier pour envoyer vos emails, sinon ces derniers n'ont aucune valeur d'authentification et seront donc rejetés.

Fonctionnement d'SPF

Lorsqu'un prestataire de mails reçoit un mail provenant de votre domaine, il vérifie donc si la zone DNS du domaine emétteur du mail contient une règle SPF :

  • Si la zone DNS contient une règle SPF et qu'elle est respectée, tout va bien.
  • Si elle n'en contient pas, alors le mail peut passer, mais sa chance de tomber dans les spams augmente.
  • Si elle contient une règle SPF qui n'est pas respectée, alors si cette règle est stricte (-all) le mail a d'énormes chances d'être rejeté, et si cette règle est non stricte (~all), le mail risque d'être considéré comme du spam, d'être rejeté, ou peut passer normalement, au choix du serveur de réception.

Règle SPF LRob

La règle SPF par défaut de LRob est :

v=spf1 +mx include:_spf.lrob.net -all

Erreurs SPF courantes

  • Lorsque l'on vous fournit une règle SPF à ajouter, il ne faut pas créer une nouvelle entrée, mais éditer votre règle existante.
  • Si vous avez plusieurs règles SPF, l'une ou l'autre sera aléatoirement lue par vos destinataires, pouvant causer le rejet de vos emails.
  • Il ne faut pas utiliser un relai SMTP qui n'est pas autorisé dans votre règle SPF. Seul votre serveur hébergeant les emails et étant capable de vous authentifier est habilité à envoyer des emails pour votre domaine. Vos mails risquent d'être rejetés si vous ignorez cette règle.

Les blacklists

Des listes publiques d'expéditeurs de spams existent. Si l'IP du serveur SMTP envoyant un mail est listée sur l'une de ces listes, le serveur SMTP destinataire rejettera probablement le mail.

DKIM (DomainKeys Identified Mail)

DKIM permet de chiffrer une partie de vos emails sortants par un code qui n'est déchiffrable qu'avec la clé publique présente dans votre zone DNS. Cela permet d'augmenter l'authentification des emails envoyés par votre domaine. DKIM s'inscrit sous forme d'entrée TXT dans votre zone DNS.

Activer DKIM via Plesk

Pour activer DKIM, pour votre domaine:

  • Rendez-vous dans votre Panneau de contrôle Plesk
  • Dans "Adresses email" puis "Paramètres de la messagerie"
  • Cochez "Utiliser le système anti-spam DKIM pour signer les mails sortants" et cliquez sur OK

La signature DKIM et l'entrée DNS correspondante sont alors automatiquement activées.

DMARC (Domain-based Message Authentication)

DMARC permet de choisir une action en cas de non-respect de DKIM ou de SPF. Cette norme est de plus en plus utilisée. Elle se présente sous forme d'entrée TXT dans votre zone DNS.

Une règle par défaut est présente dans votre zone DNS :

"v=DMARC1; p=reject; sp=reject; aspf=s; rua=mailto:dmarcreport@lrob.fr; ruf=mailto:dmarcreport@lrob.fr; rf=afrf; pct=100; ri=172800

Une telle valeur permet de rejeter tous les mails ne respectant pas SPF mais laisse passer en cas de souci DKIM, elle permet aussi de ne pas accepter l'envoi de mails en tant qu'un sous-domaine de votre domaine. C'est donc un gage de sécurité non négligeable pour votre domaine.

Cette entrée DNS de type TXT permet également de définir une adresse à qui envoyer les informations de rejets de mails de votre domaine, ce qui vous fera recevoir un email de la part de tous les plus grands prestataires à qui votre domaine aura envoyé des emails.


D'autres champs existent pour recevoir des rapports des mails envoyés en tant que votre domaine vers les différents prestataires de mails. Cet article vous donnera plus d'informations : https://help.returnpath.com/hc/fr/articles/222437867-Quelles-sont-les-diff%C3%A9rentes-balises-d-un-enregistrement-DMARC-