Guide technique - Qui héberge les mails

📬 Étape 1 : Les enregistrements MX

L'enregistrement MX (Mail Exchanger) indique quel serveur est responsable de la réception des emails pour un domaine. C'est le point de départ de toute analyse.

Chaque enregistrement MX contient une priorité (plus le chiffre est bas, plus le serveur est prioritaire) et un nom d'hôte. C'est ce nom d'hôte qui donne souvent le premier indice sur l'hébergeur.

🐧 Linux / macOS 🪟 Windows

$ dig MX exemple.fr +short

# Résultat :
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
10 alt2.aspmx.l.google.com.

C:\> nslookup -type=MX exemple.fr

; Résultat :
exemple.fr MX preference = 1, mail exchanger = aspmx.l.google.com
exemple.fr MX preference = 5, mail exchanger = alt1.aspmx.l.google.com

Pourquoi le MX ? Le nom du serveur MX contient presque toujours une signature de l'hébergeur. Si vous voyez google.com, outlook.com, ovh.net ou infomaniak.ch dans le nom, l'identification est immédiate.

On analyse le MX de plus haute priorité (chiffre le plus bas). L'outil compare le nom d'hôte avec une base de mots-clés associés à des hébergeurs connus.

Limite : Si un service anti-spam (Mailinblack, Altospam, Proofpoint…) est en frontal, le MX pointe vers l'anti-spam et non vers l'hébergeur réel. C'est là qu'intervient l'analyse SPF.

🛡️ Étape 2 : L'enregistrement SPF

Le SPF (Sender Policy Framework) est un enregistrement TXT qui liste les serveurs autorisés à envoyer des emails pour un domaine. C'est notre meilleur allié quand un anti-spam masque le MX.

🐧 Linux / macOS 🪟 Windows

$ dig TXT exemple.fr +short | grep spf

# Résultat :
"v=spf1 include:_spf.google.com include:spf.mailinblack.com ~all"

C:\> nslookup -type=TXT exemple.fr

; Chercher la ligne commençant par v=spf1
"v=spf1 include:_spf.google.com include:spf.mailinblack.com ~all"

Pourquoi le SPF ? Même si le MX pointe vers un anti-spam, le SPF doit lister l'hébergeur mail réel pour que les emails sortants soient authentifiés. Les directives include: pointent vers les domaines SPF des services utilisés. C'est un indicateur fiable car l'hébergeur mail doit y figurer pour que l'envoi fonctionne.

L'analyse consiste à :

1. Extraire toutes les directives include: et redirect= du SPF.
2. Filtrer les services qui ne sont pas des hébergeurs mail : outils marketing (Mailchimp, Sendinblue…), ERP/CRM (Salesforce, HubSpot…), et les anti-spam eux-mêmes.
3. Comparer les includes restants avec la base de mots-clés d'hébergeurs.

Dans l'exemple ci-dessus, _spf.google.com identifie Google Workspace comme hébergeur, et spf.mailinblack.com est filtré comme anti-spam.

Cas problématique : Si le SPF contient plusieurs hébergeurs mail (par exemple _spf.google.com + spf.protection.outlook.com), c'est souvent le signe d'une migration en cours ou d'un SPF mal nettoyé. C'est là qu'on passe à l'Autodiscover pour trancher.

🔄 Étape 3 : Autodiscover / Autoconfiguration

Autodiscover est un mécanisme utilisé par les clients mail (Thunderbird, Outlook,…) pour configurer automatiquement les paramètres de connexion. Il pointe vers l'hébergeur mail actuellement utilisé.

On vérifie deux types d'enregistrements :

a) Le CNAME autodiscover.domaine.fr

🐧 Linux / macOS 🪟 Windows

$ dig CNAME autodiscover.exemple.fr +short

# Résultat :
autodiscover.outlook.com.

C:\> nslookup -type=CNAME autodiscover.exemple.fr

; Résultat :
autodiscover.exemple.fr canonical name = autodiscover.outlook.com

b) L'enregistrement SRV _autodiscover._tcp.domaine.fr

🐧 Linux / macOS 🪟 Windows

$ dig SRV _autodiscover._tcp.exemple.fr +short

# Résultat :
0 0 443 mail.infomaniak.com.

C:\> nslookup -type=SRV _autodiscover._tcp.exemple.fr

; Résultat :
_autodiscover._tcp.exemple.fr SRV service location:
priority = 0, weight = 0, port = 443, target = mail.infomaniak.com

Pourquoi l'Autodiscover ? Contrairement au SPF qui peut contenir des traces d'anciens hébergeurs, l'Autodiscover pointe presque toujours vers le fournisseur actuellement en service. C'est un très bon arbitre quand le SPF est ambigu. Son principal défaut : il n'est pas toujours configuré.

🤝 Étape 4 : La bannière SMTP

En se connectant au port 25 du serveur MX, on récupère sa bannière d'accueil SMTP. Cette bannière peut révéler le logiciel utilisé (Postfix, Exchange, Exim…) ou parfois directement le nom de l'hébergeur.

🐧 Linux / macOS 🪟 Windows

# Avec telnet
$ telnet aspmx.l.google.com 25
220 mx.google.com ESMTP gsmtp

# Ou avec openssl (si le port 25 est filtré)
$ echo "QUIT" | nc -w 3 aspmx.l.google.com 25
220 mx.google.com ESMTP gsmtp

:: Avec telnet (activer la fonctionnalité Windows d'abord)
C:\> telnet aspmx.l.google.com 25
220 mx.google.com ESMTP gsmtp

:: Avec PowerShell
PS> (New-Object Net.Sockets.TcpClient("aspmx.l.google.com",25)).GetStream() | ...
220 mx.google.com ESMTP gsmtp

Attention : Beaucoup de FAI et de réseaux d'entreprise bloquent le port sortant 25. Cette étape peut ne pas fonctionner depuis tous les environnements.

🏠 Étape 5 : Détection de l'auto-hébergement

Si aucun hébergeur connu n'est identifié, on vérifie si le domaine du serveur MX correspond au domaine recherché.

# Domaine recherché : monentreprise.fr
# MX trouvé :
10 mail.monentreprise.fr.

# → Le MX contient le domaine recherché
# → Probable auto-hébergement

Logique : Si monentreprise.fr a un MX qui pointe vers mail.monentreprise.fr, smtp.monentreprise.fr ou tout sous-domaine de monentreprise.fr, c'est que probalement l'organisation gère elle-même son infrastructure mail.

🌍 Étape 6 : Géolocalisation du serveur

Une fois le serveur MX identifié, on résout son adresse IP puis on interroge une base de géolocalisation pour déterminer le pays d'hébergement. Service : db-ip.com

🐧 Linux / macOS 🪟 Windows

# Résoudre l'IP
$ dig A aspmx.l.google.com +short
142.250.153.26

# Géolocaliser (via API publique)
$ curl -s "http://api.db-ip.com/v2/free/142.250.153.26/countryName"
United States

:: Résoudre l'IP
C:\> nslookup aspmx.l.google.com
Address: 142.250.153.26

:: Géolocaliser (PowerShell)
PS> (Invoke-WebRequest "http://api.db-ip.com/v2/free/142.250.153.26/countryName").Content
United States

Fiabilité : La géolocalisation IP donne le pays du datacenter, pas nécessairement le pays de l'entreprise hébergeuse. Un hébergeur français peut utiliser un datacenter aux Pays-Bas, par exemple. Si un anti-spam est en frontal, la localisation sera celle de l'anti-spam, pas de l'hébergeur mail final.

📝 Récapitulatif des enregistrements DNS utilisés

Enregistrement	Rôle	Fiabilité
MX	Identifie le serveur qui reçoit les emails	Haute sauf si anti-spam en frontal
TXT (SPF)	Liste les serveurs autorisés à envoyer des emails	Haute mais peut contenir des restes d'ancienne config
CNAME / SRV (Autodiscover)	Pointe vers le fournisseur mail pour la configuration auto	Très haute mais pas toujours présent
Bannière SMTP	Identifie le logiciel serveur, parfois l'hébergeur	Variable dépend de la configuration du serveur

⚠️ Limites connues

Cette méthode fonctionne dans la majorité des cas, mais certaines configurations restent difficiles à analyser :

Anti-spam sans SPF exploitable : si le domaine n'a pas d'enregistrement SPF (ou un SPF trop générique), la détection derrière un anti-spam échoue.
SPF hérité / non nettoyé : des includes d'anciens hébergeurs peuvent fausser l'analyse.
Hébergeurs non référencés : la méthode repose sur une base de mots-clés ; un hébergeur inconnu ne sera pas reconnu.
Configurations atypiques : relais SMTP personnalisés, serveurs mutualisés avec des noms génériques, etc.
Port 25 filtré : la récupération de la bannière SMTP peut échouer depuis certains réseaux.

Le code source de cet outil est disponible sur GitLab. Contributions bienvenues !

Vérifier par vous-même

Toutes les commandes de cette page portent sur des données publiques : n'importe qui peut refaire l'analyse et arriver au même résultat. C'est le principe de l'outil, et son code est ouvert. Pour la version sans jargon, il y a le guide simplifié.