Nous avons élaboré ce guide complet afin d'améliorer votre compréhension du SPF et de vous aider à résoudre les problèmes que notre application a pu porter à votre attention. Le fait d'avoir un enregistrement SPF valide, précis et aligné permettra d'améliorer la couverture d'authentification, la délivrabilité et contribuera à promouvoir le niveau de sécurité que vous souhaitez pour vos domaines.
Vous n'avez pas de compte dmarcian ? Vous pouvez toujours demander le contenu de votre enregistrement SPF en utilisant notre outil SPF Survey.
Vous trouverez des informations supplémentaires sur le SPF dans les articles liés au bas de ce document. Si vous êtes novice en matière de SPF, nous vous montrons comment créer et ajouter un enregistrement SPF.
Créez un compte gratuit maintenant pour que dmarcian surveille automatiquement vos enregistrements SPF, DKIM et DMARC pour vous. Obtenez une visibilité instantanée des erreurs de livraison, des tentatives de phishing et d'usurpation d'identité avec la plateforme SaaS de dmarcian.
Si un mécanisme donne lieu à une réussite, la valeur de son qualificatif est utilisée. Le qualificatif par défaut est "+", c'est-à-dire "réussite". Les mécanismes sont évalués dans l'ordre. Si aucun mécanisme ou modificateur ne correspond, le résultat par défaut est "Neutre".
Si un domaine n'a pas du tout d'enregistrement SPF, le résultat est "None". Si un domaine a une erreur temporaire pendant le traitement DNS, vous obtenez le résultat "TempError" (appelé "error" dans les versions précédentes). 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 envisagée |
|---|---|---|
| Passez | L'enregistrement SPF désigne l'hôte à autoriser à envoyer | Accepter |
| Échec | L'enregistrement SPF a désigné l'hôte comme N'étant PAS 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 sur la validité. | Accepter |
| Aucun | Le domaine n'a pas d'enregistrement SPF ou l'enregistrement SPF ne donne pas de résultat. | Accepter |
| PermError | Une erreur permanente s'est produite (par exemple, un enregistrement SPF mal formaté). | Non spécifié |
| TempError | Une erreur transitoire s'est produite | 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 du courrier pour le domaine, interdire tous les autres.
v=SPF1 -all
Le domaine n'envoie aucun courrier.
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 de réseau IPv4. Si aucune longueur de préfixe n'est donnée, /32 est supposé (en isolant une adresse hôte individuelle). Faites attention à inclure une longueur de préfixe supérieure à /16, car la livraison à certains petits récepteurs peut être affectée.
v=spf1 ip4:192.168.0.1/16 ~all
Autorise toute adresse IP comprise 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 donnée, /128 est supposé (isolant 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'IP du client est trouvée parmi elles, ce mécanisme correspond. 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, sauf si une longueur de préfixe est fournie, auquel cas chaque adresse IP renvoyée par la recherche A sera étendue à son préfixe CIDR correspondant, et l'IP du client sera recherchée dans 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 que example.com a choisi de répertorier explicitement tous les expéditeurs de courrier sortant dans un enregistrement A spécial sous mailers.example.com.
v=spf1 a/24 a:offsite.example.com/24 ~all
Si exemple.com se résout en 192.0.2.1, la classe C entière de 192.0.2.0/24 sera recherchée pour l'IP du client. De même pour offsite.example.com. Si plus d'un enregistrement A est retourné, chacun d'entre eux sera é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'IP du client est trouvé parmi eux, ce mécanisme correspond.
Si le domaine n'est pas spécifié, le domaine actuel est utilisé.
Les enregistrements A doivent correspondre exactement à l'adresse IP du client, sauf si une longueur de préfixe est fournie, auquel cas chaque adresse IP renvoyée par la recherche A sera étendue à son préfixe CIDR correspondant, et l'IP du client sera recherchée dans ce sous-réseau.
v=spf1 mx mx:deferrals.domain.com ~all
Il se peut qu'un domaine envoie du courrier par l'intermédiaire de ses serveurs MX et d'un autre ensemble de serveurs dont le rôle est de relancer le courrier pour les domaines en différé.
v=spf1 mx/24 mx:offsite.domain.com/24 ~all
Il se peut que les serveurs MX d'un domaine reçoivent du courrier sur une adresse IP, mais en envoient sur une adresse IP différente mais proche.
Le ou les noms d'hôtes de l'IP du client sont recherchés à l'aide de requêtes PTR. Les noms d'hôtes sont ensuite validés : au moins un des enregistrements A d'un nom d'hôte PTR doit correspondre à l'adresse IP originale du client. Les noms d'hôtes non valides sont rejetés. Si un nom d'hôte valide se termine par domain, ce mécanisme correspond.
En savoir plus sur les enregistrements PTR.
Si le domaine n'est pas spécifié, le domaine actuel est utilisé.
Dans la mesure du possible, vous devriez éviter d'utiliser ce mécanisme dans votre enregistrement SPF, car il entraînera un plus grand nombre de recherches DNS coûteuses.
v=spf1 ptr ~all
Un domaine qui contrôle directement toutes ses machines (à la différence d'un FAI à accès commuté ou à large bande) autorise tous ses serveurs à envoyer du courrier. Par exemple, hotmail.com ou paypal.com peuvent faire cela.
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é, cela constitue une correspondance. Le résultat de la recherche n'a pas d'importance - il peut s'agir de 127.0.0.2.
Lorsque vous utilisez des macros avec ce mécanisme, vous pouvez effectuer des recherches d'adresses IP inversées de type RBL, ou configurer des exceptions par utilisateur.
Dans l'exemple suivant, l'IP du client est 1.2.3.4 et le domaine actuel est exemple.com.
v=spf1 existe:exemple.com ~all
Si exemple.com n'est pas résolu, le résultat est un échec. S'il est résolu, ce mécanisme aboutit à une correspondance.
Le domaine spécifié est recherché pour une correspondance. Si la recherche ne renvoie pas de correspondance ou une erreur, le traitement passe à la directive suivante. Avertissement : Si le domaine ne possède pas d'enregistrement SPF valide, le résultat est une erreur permanente. Certains récepteurs de courrier rejetteront le message en raison d'une PermError.
Dans l'exemple suivant, l'IP du client est 1.2.3.4 et le domaine actuel est exemple.com.
v=spf1 include:example.com ~all
Si exemple.com n'a pas d'enregistrement SPF, le résultat est PermError.
Supposons que l'enregistrement SPF de exemple.com soit v=spf1 a ~all.
Recherchez l'enregistrement A de exemple.com. S'il correspond à 1.2.3.4, le résultat est 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 à partir de la directive externe définie dans cet exemple.
Relations de confiance - Le mécanisme "include :" est censé traverser les frontières administratives. Il faut faire très attention à ce que les mécanismes "include :" n'exposent pas les domaines au risque de donner des résultats SPF Pass aux messages résultant d'une falsification entre utilisateurs. À moins que des mécanismes techniques ne soient en place dans l'autre domaine spécifié pour empêcher la falsification entre utilisateurs, les mécanismes "include :" devraient donner un résultat Neutre plutôt que Pass. Pour ce faire, il suffit d'ajouter " ?" 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 pour le domaine remplace l'enregistrement actuel. Le domaine macro-étendu remplace également le domaine actuel dans ces recherches.
Si un modificateur "redirect" est utilisé, l'enregistrement SPF ne doit pas inclure le mécanisme "all". Si les deux sont présents, le modificateur "redirect" est ignoré. Tous les modificateurs "redirect" autres que le premier seront ignorés.
Par exemple, cet enregistrement SPF est publié sur exemple.com :
v=spf1 redirect=exemple.com
Si exemple.com n'a pas d'enregistrement SPF, c'est une erreur ; le résultat est inconnu.
Supposons que l'enregistrement SPF de exemple.com soit v=spf1 a ~all.
Recherchez l'enregistrement A de exemple.com. S'il correspond à 1.2.3.4, renvoyer Pass.
S'il n'y a pas de correspondance, l'exécution échoue 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 développé ; une recherche TXT est effectuée. Le résultat de la recherche TXT est ensuite développé en macro et montré à 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 exemple.com :
v=spf1 mx -all exp=explain._spf.%{d}
et il y a un enregistrement TXT à explain._spf.example.com avec cette chaîne :
Les courriers électroniques d'exemple.com ne doivent être envoyés que par ses propres serveurs de messagerie.
Au cours de la dernière décennie, il est devenu de plus en plus facile d'envoyer des e-mails. 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 du courrier électronique, en particulier le SPF, est devenue une question de plus en plus complexe à gérer.
Dans la spécification SPF RFC (essentiellement la loi Internet), il existe une limite pratique du nombre de "mécanismes d'interrogation du DNS" qu'un seul enregistrement SPF peut contenir. Cette limite est de dix. La limite de dix vérifications stipule qu'un administrateur de domaine (c'est-à-dire vous !) n'exigera pas que Gmail ou d'autres récepteurs effectuent plus de dix vérifications DNS consécutives pour savoir si vous autorisez une adresse IP particulière à envoyer du courrier en votre nom.
Comme il est devenu assez courant pour une seule organisation d'autoriser un grand nombre de blocs réseau disparates (en raison de la nature externalisée de l'infrastructure de messagerie), il reste ce qui semble être un empiètement constant et inutile sur la recherche maximale de dix. Cette limite reste cependant tout à fait pratique et doit être respectée pour garantir une livraison en temps voulu et des taux de réception favorables. En outre, la solution permettant d'éviter cette limite est parfaitement prise en compte par d'autres bonnes pratiques courantes en matière de courrier électronique, encouragées depuis longtemps par les principaux destinataires de courrier entrant tels que Gmail et Yahoo.
La solution la plus pratique pour éviter le problème du "trop grand nombre de consultations" est d'utiliser des sous-domaines. Comme chaque sous-domaine distinct bénéficie de son propre maximum de dix consultations, SPF est effectivement illimité. Exemple : hello.com a droit à dix consultations + sub.hello.com a droit à dix consultations. En clair, vous ne devriez jamais vous heurter à la condition des dix consultations maximales si vous segmentez correctement les différents flux de courrier (par exemple, transactionnel, d'entreprise, de marketing, etc.
Dans cette sous-rubrique 'conseils de livraison' du site Gmail postmaster, il est recommandé de ;
En résumé, vous ne devriez pas vous heurter au maximum de 10 consultations. Si c'est le cas, nous avons décrit quelques stratégies supplémentaires et des matériaux de base de connaissances sur la façon de naviguer.
