E-mails et domaines
Enregistrements MX d’un domaine
Couverture: Fonctionne avec les domaines de tous les pays, y compris les noms avec accents ou dans d’autres alphabets. Nous reconnaissons le fournisseur des grands services de messagerie (Google, Microsoft 365, Yahoo, iCloud, Zoho, Proton, Fastmail, GMX, IONOS, OVHcloud, Yandex, Mail.ru, QQ, NetEase et Naver), d’Amazon SES et des principaux filtres de sécurité des e-mails (Mimecast, Proofpoint, Barracuda et Cisco).
Ouvrir l’outilSur cette page
Objectif
Découvrez si un domaine reçoit des e-mails, quels serveurs de messagerie il utilise (ses enregistrements MX, par ordre de priorité) et quel fournisseur les gère : Google, Microsoft 365, Zoho, Proton et d’autres.
Prérequis
Tout le monde peut lire ces guides, sans compte. Certains outils nécessitent Pro, comme indiqué dans chaque guide.
Tout domaine qui reçoit des e-mails indique ses serveurs de messagerie dans le DNS, dans ses enregistrements MX. Saisissez un domaine, une adresse e-mail ou un lien et nous vous dirons s’il peut recevoir des e-mails, quels serveurs s’en chargent et qui les gère. Nous lisons uniquement le DNS public.
Mode d’emploi
Saisissez un domaine comme example.com, ou collez une adresse e-mail ou un lien : nous n’utilisons que son domaine.
Appuyez sur « Consulter les MX ». Nous lisons les enregistrements MX du domaine dans le DNS public et vérifions que chaque serveur a une adresse.
Lisez le résultat : si le domaine reçoit des e-mails, ses serveurs dans l’ordre où ils sont essayés et le fournisseur qui se trouve derrière.
Exemple fictif
Exemple inventé, pas une recherche réelle. N’appelez pas et n’ouvrez pas ses liens.
example.comInterpréter le résultat
Ce domaine reçoit des e-mails: Il indique ses serveurs de messagerie dans le DNS : un message envoyé à une adresse de ce domaine a donc un endroit où arriver.
Il reçoit des e-mails, mais quelque chose ne va pas: Il indique des serveurs de messagerie, mais au moins l’un d’eux est mal configuré : certains messages peuvent être retardés ou perdus.
Ce domaine ne reçoit pas d’e-mails: Il n’indique aucun serveur de messagerie, ou il déclare n’accepter aucun e-mail. Un message envoyé à une adresse de ce domaine n’arrivera pas.
Ce domaine n’existe pas: Il n’est pas enregistré ou n’a pas de DNS. Personne ne peut y recevoir d’e-mails : méfiez-vous donc d’un message qui prétend en venir.
Les serveurs au numéro de priorité le plus bas sont essayés en premier ; les autres servent de secours.
Limites
Nous lisons les enregistrements DNS publics du domaine. Si vous saisissez une adresse e-mail ou un lien, seul son domaine quitte votre navigateur. Nous ne conservons pas le domaine que vous consultez.
Résoudre un problème
Cela ne ressemble pas à un domaine public. Essayez par exemple avec example.com.
Le DNS n’a pas répondu à temps. Réessayez dans quelques secondes.
Vous avez lancé beaucoup de vérifications d’affilée. Attendez une minute et réessayez.
Utiliser avec l’API
Nécessite une API key et des crédits. Chaque appel abouti coûte 1 crédit, même sans données. Un compte Pro actif inclut 20 crédits par mois calendaire UTC, partagés entre toutes les routes de l’API et consommés en premier ; les crédits mensuels non utilisés ne sont pas reportés. Les crédits achetés sur la page de votre compte fonctionnent sans Pro et n’expirent jamais.
Les erreurs ne sont jamais facturées : 401 invalid_api_key (clé absente ou invalide), 403 pro_required (ni crédits Pro ni crédits achetés), 422 entrée invalide, 429 quota_exceeded (plus de crédits), rate_limit_exceeded ou ai_busy (l’IA de sms-check est à pleine capacité), 503 tool_warming (les données sont encore en préparation) ou tool ou fournisseur indisponible. Après un 429 ou un 503, réessayez une fois écoulées les secondes indiquées dans l’en-tête Retry-After.
Indique si un domaine reçoit des e-mails : ses serveurs MX par ordre de priorité, si chacun a une adresse, un null MX ou un MX implicite, et le fournisseur qui les gère (google, microsoft, zoho, proton, amazon_ses et d’autres). Accepte un domaine, une adresse e-mail ou un lien. DNS public uniquement ; rien n’est enregistré.
Envoyez le corps JSON à la route propre au tool, ou à POST /v2/tools en ajoutant le champ tool. Les deux routes renvoient le même résultat.
POST https://api.nocall.io/v2/mx-lookup
POST https://api.nocall.io/v2/tools {"tool":"mx-lookup","domain":"example.com"}Paramètres
| Nom | Type | Obligatoire | Description |
|---|---|---|---|
| domain | string (1–320) | Oui | Un domaine, ou une adresse e-mail ou un lien dont le domaine est utilisé, jusqu’à 320 caractères. Noms publics uniquement : les adresses IP, les noms à un seul label et les noms à usage spécial (.local, .internal, .test…) renvoient un 422. |
REQUEST_ID="$(uuidgen)" && [ -n "$REQUEST_ID" ] &&
curl --request POST 'https://api.nocall.io/v2/mx-lookup' \
--header "Authorization: Bearer $NOCALL_API_KEY" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $REQUEST_ID" \
--data '{"domain":"example.com"}'import json
import os
import urllib.request
import uuid
api_key = os.environ.get('NOCALL_API_KEY')
if not api_key:
raise SystemExit('Set NOCALL_API_KEY')
request = urllib.request.Request(
'https://api.nocall.io/v2/mx-lookup',
method='POST',
data=json.dumps({'domain': 'example.com'}).encode(),
headers={
'Authorization': 'Bearer ' + api_key,
'Content-Type': 'application/json',
'Idempotency-Key': str(uuid.uuid4()),
},
)
with urllib.request.urlopen(request, timeout=30) as response:
result = json.load(response)
print(result['data']['result'], result['meta']['unitsCharged'])import { randomUUID } from 'node:crypto';
const requestId = randomUUID();
const apiKey = process.env.NOCALL_API_KEY;
if (!apiKey) throw new Error('Set NOCALL_API_KEY');
const response = await fetch('https://api.nocall.io/v2/mx-lookup', {
method: 'POST',
headers: {
Authorization: 'Bearer ' + apiKey,
'Content-Type': 'application/json',
'Idempotency-Key': requestId,
},
body: JSON.stringify({ domain: 'example.com' }),
});
const result = await response.json();
if (!response.ok) throw new Error(result.error?.code ?? 'request_failed');
console.log(result.data.result, result.meta.unitsCharged);Exemple de réponse (200)
Il s’agit de l’exemple documenté dans la référence de l’API. Les recherches utilisent un numéro fictif ; les agrégats et les réponses de l’IA montrent la structure du résultat, pas des données réelles.
{
"data": {
"tool": "mx-lookup",
"result": {
"domain": "example.com",
"domainAscii": "example.com",
"found": true,
"records": [
{
"priority": 1,
"host": "aspmx.l.google.com"
},
{
"priority": 5,
"host": "alt1.aspmx.l.google.com"
}
],
"nullMx": false,
"implicitMx": false,
"acceptsMail": true,
"provider": "google",
"signals": [],
"attention": false
}
},
"meta": {
"requestId": "req_example",
"unitsCharged": 1,
"usage": {
"periodStart": "2026-10-01",
"unitLimit": 20,
"unitsUsed": 3,
"unitsRemaining": 17
}
}
}Champs du résultat (data.result)
| Champ | Type | Description |
|---|---|---|
| domain | string | Le domaine en Unicode. |
| domainAscii | string | Le même domaine en ASCII (punycode), tel que le voit le DNS. |
| found | boolean | Indique si le domaine existe dans le DNS. false reste un résultat abouti. |
| records | array<object> | Les serveurs MX sous forme de priority et host, la valeur de priorité la plus basse (essayée en premier) en premier. Vide avec un null MX. |
| nullMx | boolean | Indique si le domaine publie « MX 0 . » (RFC 7505) : il ne reçoit aucun e-mail. |
| implicitMx | boolean | Aucun enregistrement MX, mais le domaine a une adresse : les e-mails y sont donc remis (RFC 5321). |
| acceptsMail | boolean | Indique si le domaine peut recevoir des e-mails : des serveurs MX ou un MX implicite, et aucun null MX. |
| provider | string (enum, 20) | null | Qui gère les serveurs de messagerie, d’après leurs noms : google, microsoft, yahoo, icloud, zoho, proton, fastmail, gmx, ionos, ovh, yandex, mailru, qq, netease, naver, mimecast, proofpoint, barracuda, cisco ou amazon_ses ; null s’il n’est pas reconnu. |
| signals | array<"domain_not_found" | "no_mx" | "null_mx" | "implicit_mx" | "single_mx" | "mx_without_address" | "mx_ip_literal"> | domain_not_found, no_mx, null_mx, implicit_mx, single_mx, mx_without_address ou mx_ip_literal. |
| attention | boolean | Indique si le résultat mérite un examen : le domaine ne reçoit pas d’e-mails, ou un serveur est mal configuré. |
Questions fréquentes
Qu’est-ce qu’un enregistrement MX ?
C’est l’enregistrement DNS qui indique aux autres serveurs où remettre les e-mails d’un domaine. Un domaine peut en avoir plusieurs, chacun avec une priorité : le numéro le plus bas est essayé en premier et les autres servent de secours.
Que se passe-t-il si un domaine n’a pas d’enregistrements MX ?
En général, il ne reçoit pas d’e-mails. Certains serveurs essaient quand même l’adresse du domaine lui-même, ce qui fonctionne mais reste rare pour un domaine qui utilise vraiment l’e-mail. Un domaine peut aussi publier un « null MX » pour dire qu’il n’accepte aucun e-mail.
Puis-je savoir qui gère les e-mails d’une entreprise ?
Souvent, oui : les noms des serveurs MX révèlent le fournisseur (Google, Microsoft 365, Zoho…) ou le service de sécurité qui filtre les e-mails avant leur arrivée. C’est une information publique que tout le monde peut consulter.
Est-ce que cela m’indique si une adresse e-mail existe ?
Non. Cela vous indique si le domaine reçoit des e-mails. Seul son serveur de messagerie sait si une boîte mail précise existe, et nous ne le lui demandons pas. Pour vérifier comment une adresse est écrite, son domaine et son type, utilisez « Vérifier une adresse e-mail ».
