Sécurisations et normes email - Historique des versions

Root xo1zfe7e le 31 octobre 2025 à 13:30

2025-10-31T13:30:29Z

← Version précédente		Version du 31 octobre 2025 à 13:30
Ligne 56 :		Ligne 56 :

	<pre>v=spf1 a mx include:spf.haisoft.net -all</pre>		<pre>v=spf1 a mx include:spf.haisoft.net -all</pre>

	~~<h4>Ancienne règle SPF par défaut HaiSoft</h4>~~

	~~Pour Paris :~~
	~~<pre>v=spf1 +a +mx ip4:154.41.66.0/23 ip4:149.71.232.0/22 include:relay.mailchannels.net -all</pre>~~

	~~Pour Tours :~~
	~~<pre>v=spf1 +a +mx ip4:185.177.44.0/24 ip4:91.212.26.0/24 include:relay.mailchannels.net -all</pre>~~



	<h4>Syntaxe SPF</h4>		<h4>Syntaxe SPF</h4>
Ligne 72 :		Ligne 62 :

	* <code>v=spf1</code> permet d'indiquer qu'il s'agit d'une règle SPF		* <code>v=spf1</code> permet d'indiquer qu'il s'agit d'une règle SPF
	* <code>+a</code> permet d'autoriser le serveur du domaine principal à émettre des mails pour le domaine		* <code>a</code> permet d'autoriser le serveur du domaine principal à émettre des mails pour le domaine
	* <code>+mx</code> permet d'autoriser le serveur de réception de mails du domaine à émettre des mails pour le domaine		* <code>mx</code> permet d'autoriser le serveur de réception de mails du domaine à émettre des mails pour le domaine
	* <code>ip4:~~154~~.41.66.0/23 ip4:~~149~~.71.~~232~~.~~0/22~~</code> permettent d'autoriser ~~les~~ deux IP ~~ranges les plus courant~~ d'HaiSoft à envoyer des emails		* <code>include:spf.haisoft.net</code> permet d'inclure une règle SPF existante. Si l'on regarde la règle SPF derrière spf.haisoft.net, on obtiens : <code>v=spf1 ip4:185.177.47.49 ip4:91.212.26.49 include:relay.mailchannels.net -all</code>
	* <code>~~include:_spf.google.com~~ include:relay.mailchannels.net</code> ~~permettent~~ d'autoriser ~~Gmail et notre~~ partenaire ~~relai~~ de mails MailChannels à transférer des emails pour le domaine.		* <code>ip4:185.177.47.49 ip4:91.212.26.49</code> permettent d'autoriser ces deux IP d'HaiSoft à envoyer des emails (il s'agit de serveurs de relais)
			* <code>include:relay.mailchannels.net</code> permet d'autoriser partenaire relais de mails MailChannels à transférer des emails pour le domaine.
	* <code>~all</code> permet d'indiquer que d'autres serveurs peuvent être amenés à éventuellement envoyer des emails.		* <code>~all</code> permet d'indiquer que d'autres serveurs peuvent être amenés à éventuellement envoyer des emails.
	* <code>-all</code> serait une règle plus stricte que ~all, elle indiquerait qu'aucun autre serveur que ceux cités dans la zone SPF n'a le droit d'envoyer d'emails pour le domaine.		* <code>-all</code> serait une règle plus stricte que <code>~all</code>, elle indiquerait qu'aucun autre serveur que ceux cités dans la zone SPF n'a le droit d'envoyer d'emails pour le domaine.

	<h4>Erreurs SPF courantes</h4>		<h4>Erreurs SPF courantes</h4>

Root xo1zfe7e : typo

2020-11-18T08:59:34Z

typo

← Version précédente		Version du 18 novembre 2020 à 08:59
Ligne 113 :		Ligne 113 :
	<pre>_DMARC TXT v=DMARC1; p=reject; fo=0; adkim=r; aspf=s; pct=100; ri=86400; sp=reject</pre>		<pre>_DMARC TXT v=DMARC1; p=reject; fo=0; adkim=r; aspf=s; pct=100; ri=86400; sp=reject</pre>

	Une telle valeur permet de rejeter tous les mails ne respectant pas SPF mais laisse passer en cas de souci ~~DMARC~~, 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.		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.

	D'autres champs existent pour recevoir des rapports des mails envoyés en tant que votre domaine vers les différents prestataires de mails.		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-		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-

Root xo1zfe7e : Add info rDNS

2020-11-10T23:00:30Z

Add info rDNS

← Version précédente		Version du 10 novembre 2020 à 23:00
Ligne 30 :		Ligne 30 :
	* Il doit être un FQDN (nom de domaine ou sous-domaine) valide, pointant vers l'IP du serveur SMTP envoyant le mail		* 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 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.		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.

Root xo1zfe7e : nouvelle règle spf

2020-10-01T12:15:31Z

nouvelle règle spf

← Version précédente		Version du 1 octobre 2020 à 12:15
Ligne 51 :		Ligne 51 :
	* 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.		* 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.

	<h4>Règle SPF ~~par défaut~~ HaiSoft</h4>		<h4>Règle SPF HaiSoft</h4>
	La règle SPF par défaut d'HaiSoft est :		La règle SPF par défaut d'HaiSoft est :

			<pre>v=spf1 a mx include:spf.haisoft.net -all</pre>

			<h4>Ancienne règle SPF par défaut HaiSoft</h4>

	Pour Paris :		Pour Paris :

Root xo1zfe7e : FQN > FQDN

2019-12-02T17:08:56Z

FQN > FQDN

← Version précédente		Version du 2 décembre 2019 à 17:08
Ligne 28 :		Ligne 28 :
	<h3>HELO</h3>		<h3>HELO</h3>
	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 :		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 ~~FQN~~ (nom de domaine ou sous-domaine) valide, pointant vers l'IP du serveur SMTP envoyant le mail		* 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 nom doit être identique correspondre au rDNS (reverse DNS) de l'IP du serveur SMTP.

Root xo1zfe7e le 28 août 2019 à 14:56

2019-08-28T14:56:03Z

← Version précédente		Version du 28 août 2019 à 14:56
Ligne 100 :		Ligne 100 :
	DMARC permet de choisir une action en cas de non-respect de DKIM ou de SPF.		DMARC permet de choisir une action en cas de non-respect de DKIM ou de SPF.

	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. Cette norme n'est ~~que peu~~ utilisée. Elle se présente sous forme d'entrée TXT dans votre zone DNS. Dans certains cas, si on vous l'impose, vous pouvez entrer une règle DMARC vide :		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. Cette norme est de plus en plus utilisée. Elle se présente sous forme d'entrée TXT dans votre zone DNS. Dans certains cas, si on vous l'impose, vous pouvez entrer une règle DMARC vide :

	<pre>_DMARC TXT v=DMARC1; p=none;</pre>		<pre>_DMARC TXT v=DMARC1; p=none</pre>

			Une valeur plus utile serait néanmoins plutôt de ce type :

			<pre>_DMARC TXT v=DMARC1; p=reject; fo=0; adkim=r; aspf=s; pct=100; ri=86400; sp=reject</pre>

			Une telle valeur permet de rejeter tous les mails ne respectant pas SPF mais laisse passer en cas de souci DMARC, 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.

			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-

Root xo1zfe7e : Page créée avec « Category:E-mail

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 vot... »

2019-04-26T13:32:35Z

Page créée avec « Category:E-mail <h1>Sécurisations et normes email</h1> La réception et la sécurisation des emails se fait principalement par des règles DNS présentes pour vot... »

Nouvelle page

[[Category:E-mail]]
<h1>Sécurisations et normes email</h1>
La réception et la sécurisation des emails se fait principalement par des règles [[DNS]] présentes pour votre domaine.

<h2>MX: Serveur de réception des emails</h2>
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.<hr />

Exemple:

Soit le domaine "monsite.tld" dont les emails sont hébergés chez HaiSoft sur le serveur srv12.haisoft.net

* Nous pouvons ajouter une entrée MX utilisant le nom d'hôte de la machine hébergeant le domaine :
<code>MX 0 srv12.haisoft.net</code>

Nous conseillons cette méthode car srv12.haisoft.net est également le serveur POP/IMAP/SMTP à utiliser pour vos connexions sécurisées, car le nom d'hôte contient les certificats SSL/TLS permettant de se connecter de manière sécurisée au serveur.

* Ou bien nous pouvons ajouter un sous-domaine et l'assigner en MX
<pre>mail A 154.41.66.12
MX 0 mail.monsite.tld</pre>

<h2>Sécurité</h2>

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é

<h3>HELO</h3>
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 FQN (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.

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é.

HaiSoft 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 HaiSoft 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.

<h3>SPF (Sender Policy Framework)</h3>
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.

<h4>Fonctionnement d'SPF</h4>

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.

<h4>Règle SPF par défaut HaiSoft</h4>
La règle SPF par défaut d'HaiSoft est :

Pour Paris :
<pre>v=spf1 +a +mx ip4:154.41.66.0/23 ip4:149.71.232.0/22 include:relay.mailchannels.net -all</pre>

Pour Tours :
<pre>v=spf1 +a +mx ip4:185.177.44.0/24 ip4:91.212.26.0/24 include:relay.mailchannels.net -all</pre>

<h4>Syntaxe SPF</h4>

Pour la règle SPF par défaut d'HaiSoft :

* <code>v=spf1</code> permet d'indiquer qu'il s'agit d'une règle SPF
* <code>+a</code> permet d'autoriser le serveur du domaine principal à émettre des mails pour le domaine
* <code>+mx</code> permet d'autoriser le serveur de réception de mails du domaine à émettre des mails pour le domaine
* <code>ip4:154.41.66.0/23 ip4:149.71.232.0/22</code> permettent d'autoriser les deux IP ranges les plus courant d'HaiSoft à envoyer des emails
* <code>include:_spf.google.com include:relay.mailchannels.net</code> permettent d'autoriser Gmail et notre partenaire relai de mails MailChannels à transférer des emails pour le domaine.
* <code>~all</code> permet d'indiquer que d'autres serveurs peuvent être amenés à éventuellement envoyer des emails.
* <code>-all</code> serait une règle plus stricte que ~all, elle indiquerait qu'aucun autre serveur que ceux cités dans la zone SPF n'a le droit d'envoyer d'emails pour le domaine.

<h4>Erreurs SPF courantes</h4>

* 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.

<h3>Les blacklists</h3>
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.

<h3>DKIM (DomainKeys Identified Mail)</h3>
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.

<h4>Activer DKIM via Plesk</h4>

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.

<h3>DMARC (Domain-based Message Authentication)</h3>

DMARC permet de choisir une action en cas de non-respect de DKIM ou de SPF.

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. Cette norme n'est que peu utilisée. Elle se présente sous forme d'entrée TXT dans votre zone DNS. Dans certains cas, si on vous l'impose, vous pouvez entrer une règle DMARC vide :

<pre>_DMARC TXT v=DMARC1; p=none;</pre>

Sécurisations et normes email - Historique des versions

Root xo1zfe7e le 31 octobre 2025 à 13:30

Root xo1zfe7e : typo

Root xo1zfe7e : Add info rDNS

Root xo1zfe7e : nouvelle règle spf

Root xo1zfe7e : FQN > FQDN