Nous avons élaboré ce guide complet pour améliorer votre compréhension du SPF et vous aider à résoudre les problèmes que notre application aurait pu porter à votre attention. Disposer d'un enregistrement SPF valide, précis et aligné améliorera la couverture d'authentification, la délivrabilité et contribuera à promouvoir le niveau de sécurité souhaité pour vos domaines.
Vous n'avez pas de compte dmarcian ? Vous pouvez toujours interroger le contenu de votre enregistrement SPF à l'aide de notre outil d'analyse SPF.
Des informations supplémentaires sur SPF sont disponibles dans les articles liés au bas de ce document. Si vous débutez avec SPF, nous vous montrons comment Créer et ajouter un enregistrement SPF.
Créez un compte gratuit dès maintenant pour que dmarcian surveille automatiquement vos enregistrements SPF, DKIM et DMARC. Obtenez une visibilité instantanée sur les erreurs de livraison, les tentatives de phishing et d'usurpation d'identité grâce à la plateforme SaaS de dmarcian.
Si un mécanisme correspond, la valeur de son qualificatif est utilisée. Le qualificatif par défaut est « + », c'est-à-dire « Pass ». Les mécanismes sont évalués dans l'ordre. Si aucun mécanisme ou modificateur ne correspond, le résultat par défaut est « Neutral ».
Si un domaine n'a aucun enregistrement SPF, le résultat est « None ». Si un domaine rencontre une erreur temporaire lors du traitement DNS, le résultat est « TempError » (appelé « error » dans les versions antérieures). Si une erreur de syntaxe ou d'évaluation se produit (par exemple, le domaine spécifie un mécanisme non reconnu), le résultat est « PermError » (anciennement « unknown »).
v=spf1 -all
v=spf1 a -all
v=spf1 a mx -all
v=spf1 +a +mx -all
| Résultat | Explication | Action prévue |
|---|---|---|
| Pass | L'enregistrement SPF désigne l'hôte comme autorisé à envoyer | Accepter |
| Fail | L'enregistrement SPF a désigné l'hôte comme NON autorisé à envoyer | Rejeter |
| SoftFail | L'enregistrement SPF a désigné l'hôte comme NON autorisé à envoyer, mais il est en transition | Accepter mais marquer |
| Neutre | L'enregistrement SPF spécifie explicitement que rien ne peut être dit concernant la validité | Accepter |
| Aucun | Le domaine n'a pas d'enregistrement SPF ou l'évaluation de l'enregistrement SPF ne produit pas de résultat | Accepter |
| PermError | Une erreur permanente est survenue (par ex. un enregistrement SPF mal formaté) | Non spécifié |
| TempError | Une erreur transitoire est survenue | Rejeter |
Ce mécanisme correspond toujours. Il doit toujours être placé à la fin de l'enregistrement SPF.
v=spf1 mx ~all
Autoriser les MX du domaine à envoyer des e-mails pour le domaine, interdire tous les autres.
v=SPF1 -all
Le domaine n'envoie aucun e-mail.
v=spf1 +all
Le domaine permet à toutes les adresses IP de l'internet d'envoyer du courrier. Cette approche est fortement déconseillée.
L'argument du mécanisme « ip4: » est une plage réseau IPv4. Si aucune longueur de préfixe n'est spécifiée, /32 est assumé (désignant une adresse d'hôte individuelle). Veillez à inclure une longueur de préfixe supérieure à /16, car la livraison à certains destinataires plus petits pourrait être impactée.
v=spf1 ip4:192.168.0.1/16 ~all
Autorise toute adresse IP entre 192.168.0.1 et 192.168.255.255.
L'argument du mécanisme « ip6: » est une plage de réseau IPv6. Si aucune longueur de préfixe n'est spécifiée, /128 est assumé (désignant une adresse d'hôte individuelle).
v=spf1 ip6:1080::8:800:200C:417A/96 ~all
Autorise toute adresse IPv6 comprise entre 1080::8:800:0000:0000 et 1080::8:800:FFFF:FFFF.
v=spf1 ip6:1080::8:800:68.0.3.1/96 ~all
Autorise toute adresse IPv6 comprise entre 1080::8:800:0000:0000 et 1080::8:800:FFFF:FFFF.
Tous les enregistrements A du domaine sont testés. Si l'adresse IP du client est trouvée parmi eux, ce mécanisme est validé. Si la connexion est établie via IPv6, une recherche AAAA est effectuée à la place.
Si le domaine n'est pas spécifié, le domaine actuel est utilisé.
Les enregistrements A doivent correspondre exactement à l'adresse IP du client, à moins qu'une longueur de préfixe ne soit fournie, auquel cas chaque adresse IP renvoyée par la recherche A sera étendue à son préfixe CIDR correspondant, et l'adresse IP du client sera recherchée au sein de ce sous-réseau.
v=spf1 a ~all
Le domaine actuel est utilisé.
v=spf1 a:example.com ~all
Équivalent si le domaine actuel est example.com.
v=spf1 a:mailers.example.com ~all
Peut-être example.com a-t-il choisi de lister explicitement tous les serveurs de messagerie sortants dans un enregistrement A spécial sous mailers.example.com.
v=spf1 a/24 a:offsite.example.com/24 ~all
Si example.com se résout en 192.0.2.1, l'ensemble de la classe C de 192.0.2.0/24 serait recherché pour l'adresse IP du client. De même pour offsite.example.com. Si plusieurs enregistrements A étaient renvoyés, chacun serait étendu à un sous-réseau CIDR.
Tous les enregistrements A de tous les enregistrements MX du domaine sont testés par ordre de priorité MX. Si l'adresse IP du client est trouvée parmi eux, ce mécanisme est validé.
Si le domaine n'est pas spécifié, le domaine actuel est utilisé.
Les enregistrements A doivent correspondre exactement à l'adresse IP du client, à moins qu'une longueur de préfixe ne soit fournie, auquel cas chaque adresse IP renvoyée par la recherche A sera étendue à son préfixe CIDR correspondant, et l'adresse IP du client sera recherchée au sein de ce sous-réseau.
v=spf1 mx mx:deferrals.domain.com ~all
Peut-être qu'un domaine envoie du courrier via ses serveurs MX et un autre ensemble de serveurs dont le rôle est de retenter l'envoi de courrier pour les domaines en attente.
v=spf1 mx/24 mx:offsite.domain.com/24 ~all
Peut-être que les serveurs MX d'un domaine reçoivent le courrier sur une adresse IP, mais l'envoient sur une adresse IP différente mais proche.
Le ou les noms d'hôte de l'adresse IP du client sont recherchés à l'aide de requêtes PTR. Les noms d'hôte sont ensuite validés : au moins un des enregistrements A pour un nom d'hôte PTR doit correspondre à l'adresse IP d'origine du client. Les noms d'hôte invalides sont ignorés. Si un nom d'hôte valide se termine par le domaine, ce mécanisme est validé.
En savoir plus sur les enregistrements PTR.
Si le domaine n'est pas spécifié, le domaine actuel est utilisé.
Si possible, vous devriez éviter d'utiliser ce mécanisme dans votre enregistrement SPF, car cela entraînera un plus grand nombre de recherches DNS coûteuses.
v=spf1 ptr ~all
Un domaine qui contrôle directement toutes ses machines (contrairement à un FAI par ligne commutée ou haut débit) autorise tous ses serveurs à envoyer du courrier. Par exemple, hotmail.com ou paypal.com pourraient le faire.
v=spf1 ptr:otherdomain.com ~all
Tout serveur dont le nom d'hôte se termine par otherdomain.com est désigné.
Effectuer une requête A sur le domaine fourni. Si un résultat est trouvé, une correspondance est établie. Peu importe le résultat de la recherche, il pourrait s'agir de 127.0.0.2.
Lorsque vous utilisez des macros avec ce mécanisme, vous pouvez effectuer des recherches d'IP inversées de type RBL ou configurer des exceptions par utilisateur.
Dans l'exemple suivant, l'adresse IP du client est 1.2.3.4 et le domaine actuel est example.com.
v=spf1 exists:example.com ~all
Si example.com ne se résout pas, le résultat est un échec. S'il se résout, ce mécanisme aboutit à une correspondance.
Le domaine spécifié est recherché pour une correspondance. Si la recherche ne retourne pas de correspondance ou d'erreur, le traitement passe à la directive suivante. Attention : Si le domaine ne possède pas d'enregistrement SPF valide, le résultat est une erreur permanente. Certains récepteurs de courrier rejetteront en se basant sur une PermError.
Dans l'exemple suivant, l'adresse IP du client est 1.2.3.4 et le domaine actuel est example.com.
v=spf1 include:example.com ~all
Si example.com n'a pas d'enregistrement SPF, le résultat est PermError.
Supposons que l'enregistrement SPF d'example.com soit v=spf1 a ~all.
Recherchez l'enregistrement A pour example.com. S'il correspond à 1.2.3.4, renvoyez Pass.
S'il n'y a pas de correspondance, autre que le "~all" du domaine inclus, l'inclusion dans son ensemble ne correspond pas ; le résultat final est toujours Fail de la directive externe définie dans cet exemple
Relations de confiance – Le mécanisme "include:" est destiné à traverser les frontières administratives. Une grande prudence est nécessaire pour s'assurer que les mécanismes "include:" ne mettent pas les domaines en danger en attribuant des résultats SPF Pass à des messages résultant d'une usurpation d'identité inter-utilisateurs. À moins que des mécanismes techniques ne soient en place sur l'autre domaine spécifié pour empêcher l'usurpation d'identité inter-utilisateurs, les mécanismes "include:" devraient donner un résultat Neutre plutôt que Pass. Cela se fait en ajoutant "?" devant "include:".
v=spf1 ?include:example.com ~all
Les modificateurs sont facultatifs. Un modificateur ne peut apparaître qu'une seule fois par enregistrement. Les modificateurs inconnus sont ignorés.
L'enregistrement SPF du domaine remplace l'enregistrement actuel. Le domaine étendu par macro est également substitué au domaine actuel dans ces recherches.
Si un modificateur 'redirect' est utilisé, l'enregistrement SPF ne doit pas non plus inclure le mécanisme 'all'. Si les deux sont présents, le modificateur 'redirect' est ignoré. Tout modificateur 'redirect' au-delà du premier sera ignoré.
Par exemple, cet enregistrement SPF est publié sur example.com :
v=spf1 redirect=example.com
Si example.com n'a pas d'enregistrement SPF, c'est une erreur ; le résultat est inconnu.
Supposons que l'enregistrement SPF d'example.com soit v=spf1 a ~all.
Recherchez l'enregistrement A pour example.com. S'il correspond à 1.2.3.4, renvoyez Pass.
S'il n'y a pas de correspondance, l'exécution échoue à correspondre, et la valeur ~all est utilisée.
Si un récepteur SMTP rejette un message, il peut inclure une explication. Un éditeur SPF peut spécifier la chaîne d'explication que les expéditeurs voient. De cette façon, un FAI peut diriger les utilisateurs non conformes vers une page web qui fournit des instructions supplémentaires sur la façon de configurer SASL.
Le domaine est étendu ; une recherche TXT est effectuée. Le résultat de la requête TXT est ensuite étendu par macro et affiché à l'expéditeur. D'autres macros peuvent être utilisées pour fournir une explication personnalisée.
Le modificateur exp ne peut contenir que des caractères ASCII imprimables.
Par exemple, cet enregistrement SPF est publié sur example.com :
v=spf1 mx -all exp=explain._spf.%{d}
et il existe un enregistrement TXT à explain._spf.example.com avec cette chaîne :
Les e-mails provenant d'example.com ne doivent être envoyés que par ses propres serveurs de messagerie.
Au cours de la dernière décennie, l'envoi d'e-mails est devenu de plus en plus facile. D'innombrables sources sont apparues sur le marché, chacune offrant un ensemble d'outils spécialisés adaptés aux besoins actuels des spécialistes du marketing, des développeurs et des petites entreprises. Parallèlement à cette expansion, l'authentification des e-mails, en particulier le SPF, est devenue une question de plus en plus complexe à gérer.
Dans la spécification RFC du SPF (essentiellement une loi d'Internet), il existe une limite pratique quant au nombre de « mécanismes d'interrogation DNS » qu'un enregistrement SPF unique peut contenir. Cette limite est de dix. Le maximum de dix recherches stipule qu'un administrateur de domaine (c'est vous !) ne demandera pas à des services comme Gmail ou d'autres récepteurs d'effectuer plus de dix recherches DNS consécutives pour vérifier si vous autorisez une adresse IP particulière à envoyer des e-mails en votre nom.
Comme il est devenu assez courant pour toute organisation d'autoriser un grand nombre de blocs réseau disparates (en raison de la nature externalisée de l'infrastructure de messagerie), il subsiste ce qui semble être un empiètement constant et inutile sur la limite des dix recherches maximales. Cependant, cette limite reste tout à fait pratique et doit être respectée pour garantir une livraison rapide et des taux de réception favorables. De plus, la solution pour éviter cette limite est directement abordée par d'autres bonnes pratiques de messagerie courantes, longtemps encouragées par les principaux récepteurs entrants tels que Gmail et Yahoo.
La solution la plus pratique pour éviter le problème des « trop nombreuses recherches » est d'utiliser des sous-domaines. Comme chaque sous-domaine distinct bénéficie de son propre maximum de dix recherches, le SPF est effectivement illimité. Exemple : hello.com est autorisé à dix recherches + sub.hello.com est autorisé à dix recherches. En clair, vous ne devriez jamais rencontrer la condition de dix recherches maximales si vous segmentez correctement les différents flux de courrier (par exemple, transactionnel, d'entreprise, marketing, etc.) sur des espaces de noms distincts.
Dans cette sous-section « conseils de livraison » du site Postmaster de Gmail, il est recommandé de ;
En résumé, vous ne devriez pas atteindre le maximum de 10 recherches. Si cela se produit, nous avons décrit des stratégies supplémentaires et des ressources de la base de connaissances pour vous aider à y remédier.
