E-mails et domaines
Vérifier le SPF
Couverture: Fonctionne avec les domaines de tous les pays. Nous lisons l’enregistrement comme le font les serveurs de réception (RFC 7208) : ses mécanismes, la façon dont il se termine, chaque include et redirect jusqu’à 30 requêtes, et son nombre de requêtes DNS par rapport à la limite de 10.
Ouvrir l’outilSur cette page
Objectif
Vérifiez l’enregistrement SPF d’un domaine : quels serveurs peuvent envoyer des e-mails en son nom, ce qui arrive à tous les autres (« -all », « ~all », « +all »), combien de requêtes DNS il nécessite par rapport à la limite de 10, et chaque include.
Prérequis
Tout le monde peut lire ces guides, sans compte. Certains outils nécessitent Pro, comme indiqué dans chaque guide.
Le SPF est l’enregistrement DNS dans lequel un domaine liste les serveurs autorisés à envoyer ses e-mails. Sans lui, ou avec un SPF cassé ou trop ouvert, il est plus facile d’envoyer de faux e-mails au nom de ce domaine. Saisissez un domaine, une adresse e-mail ou un lien et nous lirons son SPF pour vous l’expliquer.
Mode d’emploi
Saisissez le domaine que vous voulez vérifier, ou collez une adresse e-mail ou un lien : nous n’utilisons que son domaine.
Appuyez sur « Vérifier le SPF ». Nous lisons l’enregistrement SPF et suivons chaque include, comme le ferait un serveur de réception.
Regardez comment se termine l’enregistrement et le nombre de requêtes : ce que vous voulez voir, c’est « -all » ou « ~all » et 10 requêtes ou moins.
Exemple fictif
Exemple inventé, pas une recherche réelle. N’appelez pas et n’ouvrez pas ses liens.
v=spf1 include:_spf.example.com ~allInterpréter le résultat
Ce domaine n’a pas de SPF: Il n’indique pas quels serveurs peuvent envoyer ses e-mails, ce qui facilite l’usurpation de son identité. Si c’est votre domaine, publiez un enregistrement SPF.
L’enregistrement SPF contient des erreurs: Les serveurs de réception ne peuvent pas l’appliquer : pour eux, le domaine n’a pas de SPF. Les signaux ci-dessous indiquent ce qui ne va pas.
N’importe qui peut envoyer des e-mails au nom de ce domaine: L’enregistrement se termine par « +all », qui autorise tous les serveurs du monde. Configuré ainsi, le SPF ne protège rien.
Le SPF ne protège pas complètement le domaine: L’enregistrement ne dit pas quoi faire des serveurs qui ne figurent pas sur sa liste : les faux e-mails au nom du domaine ne sont donc pas signalés.
Le SPF est bien configuré: Le domaine liste les serveurs qui peuvent envoyer ses e-mails et demande aux serveurs de réception de signaler ou de rejeter les autres. Le SPF seul n’empêche pas l’usurpation : c’est le DMARC qui indique aux serveurs de réception quoi faire.
+all : n’importe quel serveur peut envoyer (dangereux)
?all : l’enregistrement ne dit rien à leur sujet
~all : marqués comme suspects
-all : rejetés
Pas de « all » : l’enregistrement ne dit rien à leur sujet
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.
Lit l’enregistrement SPF d’un domaine comme le font les serveurs de réception (RFC 7208) : ses termes, ce par quoi il se termine, les requêtes DNS de tout l’arbre d’include par rapport à la limite de 10, chaque include et s’il publie un SPF, ainsi que les problèmes de l’enregistrement sous forme de signaux. 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/spf-check
POST https://api.nocall.io/v2/tools {"tool":"spf-check","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/spf-check' \
--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/spf-check',
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/spf-check', {
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": "spf-check",
"result": {
"domain": "example.com",
"domainAscii": "example.com",
"found": true,
"record": "v=spf1 include:_spf.google.com ~all",
"recordCount": 1,
"terms": [
{
"qualifier": "pass",
"mechanism": "include",
"value": "_spf.google.com"
},
{
"qualifier": "softfail",
"mechanism": "all",
"value": null
}
],
"allResult": "softfail",
"lookups": 1,
"includes": [
{
"domain": "_spf.google.com",
"found": true
}
],
"signals": [
"softfail_all"
],
"valid": true,
"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 publie un enregistrement SPF. |
| record | string | null | L’enregistrement SPF tel qu’il est publié ; null s’il n’y en a aucun ou plus d’un. |
| recordCount | integer | Le nombre d’enregistrements SPF que le domaine publie ; plus d’un est une erreur. |
| terms | array<object> | Les mécanismes et modificateurs de l’enregistrement dans l’ordre, chacun avec son qualificateur (pass, fail, softfail ou neutral ; null pour redirect et exp) et sa valeur. |
| allResult | "pass" | "fail" | "softfail" | "neutral" | null | Ce par quoi l’enregistrement se termine (son all, ou celui de la cible de son redirect) : pass, fail, softfail ou neutral ; null s’il n’en a pas. |
| lookups | integer | Mécanismes et modificateurs qui interrogent le DNS, dans tout l’arbre d’include. Les serveurs de réception s’arrêtent au-delà de 10 (permerror). |
| includes | array<object> | Chaque cible d’include et de redirect dans l’ordre de lecture, et si elle publie un SPF. |
| signals | array<string (enum, 12)> | no_spf, multiple_records, syntax_error, too_many_lookups, include_not_found, include_loop, plus_all, neutral_all, softfail_all, no_all, ptr_mechanism ou macros. |
| valid | boolean | Indique si un serveur de réception peut évaluer l’enregistrement : un seul enregistrement, aucune erreur de syntaxe, 10 requêtes au maximum, chaque include trouvé et aucune boucle. |
| attention | boolean | Indique si le résultat mérite un examen : pas de SPF, un enregistrement invalide, ou un enregistrement qui se termine par +all, ?all ou sans all. |
Questions fréquentes
Qu’est-ce que le SPF ?
Sender Policy Framework : un enregistrement DNS dans lequel un domaine liste les serveurs autorisés à envoyer ses e-mails. Le serveur qui reçoit un message vérifie si le serveur qui le lui a remis figure sur cette liste.
Lequel est le meilleur, « -all » ou « ~all » ?
« -all » demande aux serveurs de réception de rejeter les e-mails des serveurs qui ne sont pas listés ; « ~all » leur demande de les marquer comme suspects. Les deux protègent, et beaucoup de domaines utilisent « ~all » et laissent le DMARC décider quoi faire. « +all » et « ?all » ne protègent pas.
Pourquoi la limite de 10 requêtes est-elle importante ?
Chaque include, a, mx, ptr, exists et redirect oblige le serveur de réception à interroger le DNS. Si l’enregistrement complet en nécessite plus de 10, il est traité comme une erreur et le SPF cesse de fonctionner. Supprimez les services que vous n’utilisez plus ou demandez à votre fournisseur un include plus simple.
Le SPF arrête-t-il à lui seul les faux e-mails ?
Non. Le SPF vérifie l’expéditeur caché de l’enveloppe, pas l’adresse que vous voyez dans « De ». C’est le DMARC qui relie les deux et demande aux serveurs de réception de mettre en quarantaine ou de rejeter les e-mails qui échouent. Vérifiez aussi le DMARC du domaine.
