Sur cette page

E-mails et domaines

Vérifier le SPF

API · Pro

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’outil
Sur 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

  1. Saisissez le domaine que vous voulez vérifier, ou collez une adresse e-mail ou un lien : nous n’utilisons que son domaine.

  2. Appuyez sur « Vérifier le SPF ». Nous lisons l’enregistrement SPF et suivons chaque include, comme le ferait un serveur de réception.

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

Remarque

Exemple inventé, pas une recherche réelle. N’appelez pas et n’ouvrez pas ses liens.

Exemple fictif
v=spf1 include:_spf.example.com ~all

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

Attention

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

Attention

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.

Remarque

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.

Endpoint
POST https://api.nocall.io/v2/spf-check
POST https://api.nocall.io/v2/tools  {"tool":"spf-check","domain":"example.com"}

Paramètres

NomTypeObligatoireDescription
domainstring (1–320)OuiUn 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.
bash
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"}'

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.

JSON
{
  "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)

ChampTypeDescription
domainstringLe domaine en Unicode.
domainAsciistringLe même domaine en ASCII (punycode), tel que le voit le DNS.
foundbooleanIndique si le domaine publie un enregistrement SPF.
recordstring | nullL’enregistrement SPF tel qu’il est publié ; null s’il n’y en a aucun ou plus d’un.
recordCountintegerLe nombre d’enregistrements SPF que le domaine publie ; plus d’un est une erreur.
termsarray<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" | nullCe 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.
lookupsintegerMé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).
includesarray<object>Chaque cible d’include et de redirect dans l’ordre de lecture, et si elle publie un SPF.
signalsarray<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.
validbooleanIndique 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.
attentionbooleanIndique 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.