Outil gratuit
Générateur SPF gratuit
Créez votre enregistrement SPF en quelques minutes
Créez un enregistrement TXT SPF valide pour autoriser vos expéditeurs et protéger votre délivrabilité. Choisissez vos fournisseurs, ajoutez vos propres IP et copiez un enregistrement correct du premier coup.
Sans inscription. Validation en temps réel.
Sélectionnez vos fournisseurs d'email
Commencez par les fournisseurs qui exigent clairement des includes SPF sur le domaine racine. Beaucoup d'autres dépendent de votre configuration : les modes par défaut reposent généralement sur DKIM, tandis qu'un Return-Path ou un MAIL FROM personnalisé peut nécessiter SPF sur un sous-domaine d'envoi.
Includes SPF courants sur le domaine racine
Ces fournisseurs nécessitent généralement des includes SPF dans l'enregistrement de votre domaine principal.
Avancé : ajouter des includes personnalisés
Utilisez ceci uniquement quand la documentation du fournisseur exige explicitement un include SPF pour votre configuration (par exemple un Return-Path ou un MAIL FROM personnalisé).
Séparés par des virgules. Les includes comptent dans la limite des 10 requêtes DNS et peuvent concerner un sous-domaine d'envoi.
Fournisseurs dépendant de la configuration
Les configurations par défaut utilisent souvent un domaine Return-Path appartenant au fournisseur et DKIM. Si vous activez un Return-Path ou un MAIL FROM personnalisé, SPF peut devenir nécessaire (souvent sur un sous-domaine).
Email transactionnel
Le MAIL FROM par défaut utilise amazonses.com ; un MAIL FROM personnalisé nécessite SPF sur ce sous-domaine
Le mode CNAME automatique gère généralement SPF ; le mode Return-Path personnalisé ou manuel peut nécessiter SPF
SPF généralement nécessaire sur votre domaine ou sous-domaine d'envoi
Return-Path du fournisseur par défaut ; un Return-Path personnalisé permet l'alignement SPF
Configuration DKIM d'abord ; certains modes de domaine nécessitent encore un include SPF
Marketing, ventes et support
Généralement basé sur DKIM ; consultez la documentation si un domaine de bounce personnalisé est activé
Généralement basé sur DKIM ; les besoins SPF dépendent du plan et du mode d'envoi
La configuration du domaine d'envoi peut comporter des exigences SPF
Ajoutez include:_spf.salesforce.com quand Salesforce envoie des emails pour votre domaine
Peut nécessiter un include SPF lors d'un envoi au nom de votre domaine
SPF peut être nécessaire selon la configuration de la boîte mail ou de l'authentification
SPF du fournisseur en général ; l'option Return-Path personnalisé peut affecter l'alignement SPF
Ajouter des adresses IP personnalisées (Facultatif)
Séparées par des virgules. Prend en charge la notation CIDR (ex. 192.0.2.0/24).
Séparées par des virgules. Prend en charge la notation CIDR (ex. 2001:db8::/32).
Choisissez votre politique SPF
Avertissement RFC 7208 : Ces mécanismes sont déconseillés car ils consomment des requêtes DNS et peuvent causer des problèmes de fiabilité. Utilisez ip4/ip6 à la place lorsque c'est possible.
Enregistrement SPF généré
TXTv=spf1 ~all
Avertissement : Les enregistrements SPF sont limités à 10 requêtes DNS. Réduisez les includes ou utilisez directement des adresses IP.
Comment déployer
- 1 Connectez-vous à votre fournisseur DNS (GoDaddy, Cloudflare, Namecheap, etc.).
- 2 Créez un enregistrement TXT.
-
3
Hôte :
@ou laissez vide - 4 Valeur : collez l'enregistrement ci-dessus.
Vérification
Vérifier votre configuration SPFVotre enregistrement SPF n'est que la première étape
Publier SPF ne vous dit pas s'il fonctionne vraiment. Les rapports DMARC vous montrent chaque source qui envoie au nom de votre domaine, lesquelles passent et lesquelles échouent, pour corriger les problèmes avant qu'ils n'atteignent la boîte de réception.
Qu'est-ce qu'un enregistrement SPF ?
Sender Policy Framework (SPF) est une norme d'authentification email qui nomme les serveurs autorisés à envoyer pour votre domaine. Vous publiez cette liste sous la forme d'un seul enregistrement TXT DNS commençant par v=spf1, et les serveurs destinataires la lisent pour décider si un serveur qui se connecte est autorisé à utiliser votre domaine.
Quand un serveur reçoit votre email, il lit l'enregistrement SPF du domaine de l'expéditeur d'enveloppe et vérifie si l'IP qui se connecte figure dans la liste. Une correspondance fait passer SPF. C'est l'un des signaux que les destinataires utilisent pour lutter contre l'usurpation et décider si votre email atteint la boîte de réception.
Pourquoi notre générateur SPF surveille le budget de requêtes →
Format et syntaxe d'un enregistrement SPF
Un enregistrement SPF tient sur une seule ligne de texte, à la forme fixe. Il commence par le terme de version v=spf1, suivi d'une liste de termes séparés par des espaces. Le serveur destinataire lit les termes de gauche à droite et s'arrête au premier qui correspond à l'IP qui se connecte ; l'ordre compte donc. Chaque terme est un qualificateur optionnel suivi d'un mécanisme. Par exemple, ~all est le qualificateur ~ appliqué au mécanisme all.
Deux termes ont un rôle particulier. Le terme de version v=spf1 vient en premier. Le mécanisme all vient en dernier, car il correspond à tout ce que les termes précédents n'ont pas couvert. Tout ce qui se trouve au milieu, les includes, les plages d'IP et les autres mécanismes, sert à lister qui est autorisé à envoyer.
Un seul enregistrement par domaine. Un domaine doit publier exactement un enregistrement TXT commençant par v=spf1. Avec deux enregistrements, le serveur destinataire ne peut pas savoir lequel utiliser : SPF renvoie une PermError et la vérification échoue (RFC 7208 §4.5). Si une chaîne dépasse 255 caractères, répartissez la valeur sur plusieurs chaînes entre guillemets dans le même enregistrement TXT ; le serveur les concatène sans ajouter d'espace (RFC 7208 §3.3).
La grammaire complète figure dans RFC 7208, la norme qui définit SPF.
Référence des mécanismes SPF
SPF définit huit mécanismes (RFC 7208 §5). La colonne de droite est celle que la plupart des enregistrements défectueux oublient : chaque mécanisme qui déclenche une requête consomme une part de votre budget de 10 requêtes, et dépasser ce budget fait échouer SPF. Le générateur ci-dessus compte cette colonne en direct à mesure que vous construisez.
| Mécanisme | Formes de syntaxe | Ce qu'il autorise | Requêtes DNS |
|---|---|---|---|
all |
all | Correspond toujours. Placé en dernier pour fixer le résultat par défaut des expéditeurs non listés au-dessus. | 0 |
include |
include:domaine | Autorise tous les expéditeurs de l'enregistrement SPF d'un autre domaine. La façon habituelle d'ajouter un fournisseur comme Google ou SendGrid. | 1 |
a |
a a/préfixe a:domaine a:domaine/préfixe | L'adresse A ou AAAA du domaine (le domaine courant si rien n'est précisé), éventuellement une plage CIDR entière. | 1 |
mx |
mx mx/préfixe mx:domaine mx:domaine/préfixe | Les adresses des serveurs de messagerie du domaine (ses hôtes MX), éventuellement une plage CIDR entière. | 1+ |
ptr |
ptr ptr:domaine | L'IP qui se connecte si son nom DNS inverse se termine par votre domaine. La RFC 7208 §5.5 indique que ce mécanisme NE DEVRAIT PAS être publié. | 1 |
ip4 |
ip4:adresse ip4:plage/préfixe | Une adresse IPv4 ou une plage CIDR. Aucune requête DNS, donc rien à dépenser sur le budget. | 0 |
ip6 |
ip6:adresse ip6:plage/préfixe | Une adresse IPv6 ou une plage CIDR. Comme ip4, rien à dépenser sur le budget. | 0 |
exists |
exists:domaine | Correspond si une requête DNS pour le domaine (généralement construit par macro) renvoie un enregistrement A. Utilisé pour les configurations avancées avec macros. | 1 |
Le mécanisme mx affiche « 1+ » parce que le serveur destinataire interroge l'enregistrement MX puis résout chaque hôte de messagerie nommé, et chacune de ces résolutions compte. Préférez ip4 et ip6 pour les adresses fixes. Elles correspondent exactement et ne coûtent rien sur le budget.
Qualificateurs SPF : + - ~ ?
Un qualificateur est le caractère unique placé devant un mécanisme. Il décide du résultat lorsque ce mécanisme correspond à l'IP qui se connecte. Omettez-le et SPF suppose + (pass), donc include:_spf.google.com signifie la même chose que +include:_spf.google.com (RFC 7208 §4.6.2).
| Qualificateur | Résultat | Ce qu'il indique au serveur |
|---|---|---|
+ |
Pass | L'expéditeur est autorisé. C'est la valeur par défaut, vous ne l'écrivez donc presque jamais. En général, vous ne placez un qualificateur que sur le mécanisme all à la fin. |
- |
Échec | L'expéditeur n'est pas autorisé ; rejeter l'email. Écrit -all, c'est un échec strict (hardfail). |
~ |
Softfail | L'expéditeur n'est probablement pas autorisé ; accepter l'email mais le traiter comme suspect. Écrit ~all. |
? |
Neutre | Aucune position dans un sens ou dans l'autre, comme si aucune politique n'existait. Écrit ?all. |
~all contre -all : commencez par ~all (softfail) pendant que vous lisez vos rapports DMARC et confirmez que chaque expéditeur légitime est listé. Passez à -all (échec) une fois la liste complète. Un -all prématuré rejette tout expéditeur oublié, et peut aussi casser le courrier transféré, car le transfert change le serveur d'envoi.
Modificateurs : redirect et exp
La plupart des générateurs ignorent ces deux-là, mais ils font partie de la norme et vous les rencontrerez dans de vrais enregistrements (RFC 7208 §6). Un modificateur s'écrit sous la forme nom=valeur et, contrairement à un mécanisme, apparaît au plus une fois.
redirect=domaine
Confie l'évaluation à l'enregistrement SPF d'un autre domaine et utilise son résultat, y compris son mécanisme all. Utile quand de nombreux domaines partagent une même politique. Il compte pour une requête DNS sur votre budget, et il est ignoré si l'enregistrement contient déjà un mécanisme all (RFC 7208 §6.1).
exp=domaine
Pointe vers un enregistrement TXT contenant une explication lisible que le serveur destinataire peut afficher en cas d'échec SPF. Il ne change pas le résultat, et sa requête ne compte pas dans la limite de 10 requêtes (RFC 7208 §6.2, §4.6.4).
La limite de 10 requêtes DNS
SPF plafonne le travail DNS qu'un serveur destinataire effectue pour votre enregistrement. Au plus 10 termes déclenchant une requête peuvent s'exécuter pendant l'évaluation (RFC 7208 §4.6.4). Les mécanismes include, a, mx, ptr et exists, ainsi que le modificateur redirect, comptent chacun. Les termes ip4, ip6, all et exp ne comptent pas.
Le piège est qu'un include tire un autre enregistrement, et que les includes de cet enregistrement comptent aussi. Ainsi, trois ou quatre includes de fournisseurs sur votre propre ligne peuvent discrètement dépasser dix. Au-delà de la limite, SPF renvoie une PermError. Les serveurs destinataires la traitent comme un échec, ce qui veut dire que SPF ne peut pas passer et que votre alignement DMARC sur SPF échoue avec lui.
Requêtes vides. Il existe une seconde limite, plus discrète. Un serveur destinataire DEVRAIT s'arrêter après deux requêtes « vides », c'est-à-dire qui ne renvoient aucun enregistrement (RFC 7208 §4.6.4). Une faute de frappe dans un include ou un fournisseur ayant supprimé son enregistrement SPF peut la déclencher même si votre total reste sous dix.
Comment nous comptons ces requêtes en production
Le générateur de cette page compte la colonne des requêtes en direct à mesure que vous cochez des fournisseurs et ajoutez des IP, pour rester sous le budget avant même de publier. Nous appliquons la même logique sur de vrais domaines. Notre analyseur met en œuvre la RFC 7208 §4.6.4, compte le total imbriqué complet auquel un include se déploie, suit les requêtes vides face à la limite de deux, et exclut exp du décompte comme l'exige la norme. Quand un enregistrement dépasse déjà la limite, les corrections habituelles, par ordre d'effort, sont : supprimer les includes de fournisseurs que vous n'utilisez plus, remplacer les includes stables par des plages ip4 et ip6 explicites, et n'en venir à l'aplatissement SPF qu'ensuite, que notre offre Pro exécute automatiquement toutes les 30 minutes pour garder l'enregistrement aplati à jour.
Comment SPF, DKIM et DMARC fonctionnent ensemble
SPF agit rarement seul. C'est l'un des trois enregistrements qui travaillent de concert, et le serveur destinataire lit les trois. Voici la répartition des rôles :
SPF autorise le serveur d'envoi
Il répond à la question « cette IP est-elle autorisée à envoyer pour le domaine d'enveloppe ? » SPF vérifie l'expéditeur d'enveloppe (le Return-Path ou MAIL FROM) et le nom HELO, pas l'adresse From que votre lecteur voit (RFC 7208 §2.4).
DKIM signe le message
Votre serveur ajoute une signature cryptographique dans un en-tête, et le serveur destinataire la vérifie avec une clé publique publiée dans votre DNS. Une signature valide prouve que le message n'a pas été modifié en transit et qu'il provient bien de votre domaine.
DMARC les relie au From visible
DMARC passe lorsque SPF ou DKIM se vérifie ET s'aligne avec le domaine de l'en-tête From que votre lecteur voit. Il indique aussi aux serveurs destinataires quoi faire en cas d'échec (none, quarantine ou reject) et où envoyer les rapports.
SPF est la première brique. Construisez la deuxième avec notre générateur d'enregistrement DMARC, puis suivez la checklist de configuration DMARC pour faire passer votre domaine d'aucune protection à une politique de rejet sans casser la délivrabilité.
À quoi ressemble un vrai enregistrement SPF
Voici un enregistrement pour un domaine qui envoie via Google Workspace, SendGrid et un serveur qui lui appartient :
v=spf1
Indique qu'il s'agit d'un enregistrement SPF. Chaque enregistrement commence par cette balise, et un domaine ne peut en publier qu'un seul.
include:_spf.google.com
Importe la liste publiée des IP d'envoi de Google. Chaque include est une requête DNS prélevée sur le budget de 10 requêtes.
include:sendgrid.net
Autorise SendGrid de la même manière. Deux includes jusqu'ici, donc deux requêtes utilisées.
ip4:198.51.100.10
Autorise par son adresse un serveur que vous gérez directement. Un mécanisme ip4 ou ip6 ne coûte aucune requête, alors privilégiez-le pour les IP fixes.
~all
Capture tout expéditeur non listé ci-dessus et lui applique un softfail. Les mécanismes sont lus de gauche à droite, donc le terme all vient toujours en dernier.
Comment fonctionne l'authentification SPF
Les destinataires exécutent SPF pendant la conversation SMTP, avant d'accepter le message :
Un serveur se connecte
Votre serveur de messagerie ouvre une connexion vers le serveur du destinataire et présente une adresse d'expéditeur d'enveloppe et une IP source.
Le destinataire consulte SPF
Il prend le domaine du Return-Path (l'expéditeur d'enveloppe) et interroge le DNS pour l'enregistrement SPF de ce domaine.
L'IP est vérifiée
Il parcourt les mécanismes de l'enregistrement dans l'ordre et demande si l'IP qui se connecte est autorisée par l'un d'eux.
Un résultat est attribué
La correspondance et votre qualificateur final produisent un verdict : pass, fail, softfail ou neutral.
Le verdict alimente le filtrage
SPF rejoint DKIM et DMARC parmi les éléments qui nourrissent la décision anti-spam et d'authentification du destinataire.
Pourquoi votre domaine a besoin de SPF
Un domaine sans SPF est plus facile à usurper et plus difficile à délivrer. Ce que vous gagnez en en publiant un :
Plus difficile à usurper
SPF nomme les serveurs autorisés à envoyer pour vous. Sans lui, n'importe qui peut falsifier votre adresse depuis n'importe quel serveur et les destinataires n'ont aucun moyen de le détecter.
Meilleure délivrabilité
Gmail, Microsoft et Yahoo lisent tous SPF. Les emails d'un domaine sans SPF risquent davantage d'atterrir en spam ou d'être refusés.
Conforme aux règles des expéditeurs en volume
Depuis février 2024, Google et Yahoo exigent des expéditeurs en volume (environ 5 000 messages par jour ou plus) qu'ils publient SPF, DKIM et un enregistrement DMARC. SPF est l'un des piliers de cette exigence.
Alimente l'alignement DMARC
DMARC passe quand SPF ou DKIM s'aligne avec votre domaine From. SPF est l'une des deux voies, il influence donc directement la protection offerte par DMARC.
Protège votre réputation
Quand quelqu'un usurpe votre domaine, les destinataires qui reçoivent le phishing blâment votre marque. SPF participe à fermer cette porte.
Erreurs SPF courantes à éviter
La plupart des enregistrements SPF défaillants échouent pour l'une de ces raisons :
Dépasser les 10 requêtes DNS
Chaque include, a, mx, ptr, exists et redirect compte dans la limite de 10. Au-delà, SPF renvoie un PermError. Remplacez les includes par ip4/ip6 quand les IP sont stables.
Publier deux enregistrements SPF
Un domaine ne doit avoir qu'un seul enregistrement commençant par v=spf1. En publier deux est un PermError automatique. Fusionnez tout dans un enregistrement unique.
Ajouter des includes inutiles
Beaucoup de fournisseurs envoient depuis leur propre Return-Path, donc un include sur le domaine racine ne fait que consommer une requête. N'en ajoutez un que si la documentation du fournisseur le demande, généralement pour un Return-Path ou un MAIL FROM personnalisé.
Passer à -all trop tôt
Le hardfail rejette tout expéditeur que vous avez oublié de lister, y compris les vôtres. Restez sur ~all avec la surveillance DMARC jusqu'à ce que vos rapports montrent toutes vos sources légitimes.
Oublier vos propres serveurs
Formulaires de contact, notifications applicatives et scripts de surveillance envoient aussi des emails. Si un de vos serveurs envoie, son IP a sa place dans l'enregistrement.
Les sous-domaines ont besoin de leur propre enregistrement
SPF ne se transmet pas en cascade. Un enregistrement sur exemple.com ne dit rien des emails envoyés depuis mail.exemple.com ou news.exemple.com. Chaque sous-domaine qui envoie des emails a besoin de son propre enregistrement SPF, à son propre nom.
Pour un sous-domaine qui n'envoie jamais d'emails, publiez un enregistrement qui n'autorise rien : v=spf1 -all. Cela applique un hardfail à quiconque falsifie un email depuis ce sous-domaine, et ferme une voie que les attaquants aiment exploiter.
Testez-le après publication
Les changements DNS mettent du temps à se propager, de quelques minutes à quelques heures. Une fois l'enregistrement en ligne, relisez-le depuis la ligne de commande avant de vous y fier :
macOS ou Linux
Windows
Un résultat correct renvoie la chaîne exacte que vous avez publiée, par exemple :
Vous préférez un navigateur ? Lancez la même vérification sur notre vérificateur de domaine gratuit pour un verdict en langage clair sur SPF, DKIM et DMARC.
Comment créer un enregistrement SPF pour votre domaine
Cochez les fournisseurs qui exigent un include sur le domaine racine, ajoutez les IP des serveurs que vous gérez, ajoutez les includes des fournisseurs depuis leur documentation si nécessaire, et choisissez une politique. L'outil construit un SPF valide au fur et à mesure et vous copiez le résultat dans votre DNS.
Pour beaucoup de fournisseurs transactionnels et marketing, un include sur le domaine racine est facultatif. Ils envoient depuis leur propre Return-Path et s'appuient sur DKIM pour l'alignement DMARC. N'ajoutez un include que si vous activez un Return-Path ou un MAIL FROM personnalisé, et il a alors généralement sa place sur le sous-domaine d'envoi.
SPF n'est qu'une étape. Suivez la checklist de configuration DMARC pour faire passer votre domaine d'aucune protection à une politique de rejet sans casser la délivrabilité.
Questions fréquentes
Qu'est-ce qu'un enregistrement SPF et pourquoi en ai-je besoin pour mes emails ?
Un enregistrement SPF (Sender Policy Framework) est un enregistrement TXT DNS qui liste les serveurs autorisés à envoyer des emails pour votre domaine. Sans lui, des destinataires comme Gmail et Outlook sont plus enclins à marquer vos emails comme spam ou à les refuser. Depuis février 2024, Google et Yahoo exigent SPF pour les expéditeurs en volume.
Comment générer un enregistrement SPF pour mon domaine ?
Saisissez votre domaine dans l'outil ci-dessus, sélectionnez les fournisseurs qui envoient des emails pour vous (Google Workspace, Microsoft 365, etc.), ajoutez vos adresses IP personnalisées, choisissez une politique et copiez. Le générateur assemble une syntaxe SPF correcte à votre place.
Où ajouter mon enregistrement SPF dans le DNS ?
Ajoutez-le en tant qu'enregistrement TXT à la racine de votre domaine (hôte @ ou vide). Connectez-vous à votre fournisseur DNS (GoDaddy, Cloudflare, Namecheap, Route 53, etc.), créez un enregistrement TXT et collez la valeur générée. Ne publiez qu'un seul enregistrement commençant par v=spf1.
Qu'est-ce que la limite de 10 requêtes DNS en SPF ?
Un enregistrement SPF peut déclencher au maximum 10 requêtes DNS lorsqu'un destinataire l'évalue. Les mécanismes include, a, mx, ptr, exists et redirect comptent ; ip4, ip6 et all ne comptent pas. Au-delà de 10, SPF renvoie un PermError, que les destinataires traitent comme un échec. Le compteur de cette page suit votre total en direct.
Quelle est la différence entre ~all et -all en SPF ?
~all (softfail) : les destinataires acceptent les emails qui échouent au SPF mais les traitent comme suspects. C'est le bon réglage pendant que vous surveillez vos rapports DMARC, car DMARC tranche en dernier ressort.
-all (fail) : les destinataires rejettent les emails qui échouent au SPF. L'option la plus stricte, à adopter une fois chaque expéditeur légitime listé. Elle peut casser certains transferts.
?all (neutral) : le résultat n'a aucun poids, comme si vous n'aviez aucune politique. À éviter en production.
Pourquoi SPF vérifie-t-il le Return-Path plutôt que l'adresse From ?
SPF authentifie l'expéditeur d'enveloppe, le Return-Path ou MAIL FROM, ainsi que le nom HELO. Il ne regarde pas l'en-tête "From" visible que lisent vos destinataires. De nombreux fournisseurs placent leur propre domaine dans le Return-Path (par exemple mcsv.net pour Mailchimp), donc la vérification SPF s'exécute sur leurs serveurs, pas sur les vôtres.
DMARC a besoin de l'alignement pour passer. Les configurations par défaut des fournisseurs y parviennent généralement via la signature DKIM avec votre domaine, ce qui évite tout include SPF supplémentaire sur votre racine.
Cela dépend de la configuration. Activez un Return-Path ou un MAIL FROM personnalisé sur votre propre domaine ou sous-domaine, et SPF devient nécessaire pour ce domaine d'envoi.
En savoir plus sur le Return-Path et les exigences SPF des fournisseurs →
Comment vérifier quel Return-Path utilise mon fournisseur ?
Envoyez-vous un email de test via le fournisseur et lisez les en-têtes :
- Gmail : ouvrez l'email, cliquez sur le menu à trois points, choisissez "Afficher l'original".
- Outlook : ouvrez l'email, puis Fichier → Propriétés → "En-têtes Internet".
Repérez la ligne Return-Path. Si elle affiche votre domaine ou un sous-domaine que vous contrôlez (par exemple [email protected]), ce domaine d'envoi a besoin de SPF. Si elle affiche le domaine du fournisseur (par exemple [email protected]), le fournisseur gère SPF et DKIM est votre voie d'alignement.
Où trouver la documentation SPF officielle de chaque fournisseur ?
Chaque fournisseur documente sa propre configuration SPF. Liens directs :
Plateformes email
Email transactionnel
Email marketing
Qu'est-ce qu'un PermError SPF ?
Un PermError (erreur permanente) signifie qu'un destinataire n'a pas pu évaluer votre enregistrement SPF. La cause habituelle est le dépassement de la limite de 10 requêtes ; une seconde cause est la publication de deux enregistrements commençant par v=spf1. Les destinataires traitent un PermError comme un échec, donc l'alignement DMARC sur SPF échoue avec lui.
Corrigez-le par ordre d'effort :
- Supprimez les includes des fournisseurs que vous n'utilisez plus.
- Remplacez les includes stables par des mécanismes
ip4/ip6explicites. - Utilisez l'aplatissement SPF pour les fournisseurs aux plages d'IP dynamiques. Notre plan Pro l'automatise.
Comment corriger l'erreur SPF « trop de requêtes DNS » ?
SPF renvoie un PermError dès que l'enregistrement nécessite plus de 10 requêtes DNS. Pour repasser sous la limite :
- Comptez chaque
include,a,mx,ptr,existsetredirectde votre enregistrement. Chacun vaut une requête. - Retirez les expéditeurs que vous n'utilisez plus.
- Remplacez les includes lourds par
ip4/ip6là où les IP restent stables. - Pour les fournisseurs aux IP changeantes, utilisez l'aplatissement SPF pour que l'enregistrement soit reconstruit automatiquement.
Quelle est la différence entre softfail (~all), neutral (?all) et hardfail (-all) ?
~all (softfail) : les destinataires acceptent les emails non autorisés mais les marquent comme suspects. À utiliser pendant que vous surveillez avec DMARC.
-all (hardfail) : les destinataires rejettent purement les emails non autorisés. Passez-y une fois chaque expéditeur légitime présent dans votre enregistrement.
?all (neutral) : les destinataires agissent comme si aucun enregistrement SPF n'existait. Cela annule l'intérêt d'en publier un.
Comment lire un enregistrement SPF ?
Lisez-le de gauche à droite. L'enregistrement commence par v=spf1, puis chaque terme séparé par un espace est un qualificateur optionnel suivi d'un mécanisme. Le serveur destinataire compare l'IP qui se connecte à chaque terme dans l'ordre et s'arrête à la première correspondance. Ainsi v=spf1 include:_spf.google.com ip4:198.51.100.10 ~all signifie : autoriser les serveurs de Google, autoriser cette IP, et softfail tous les autres.
Quelle est la différence entre un mécanisme, un qualificateur et un modificateur SPF ?
Un mécanisme indique qui peut envoyer (include, ip4, a, mx et les autres). Un qualificateur est le + - ~ ? placé devant un mécanisme pour fixer son résultat. Un modificateur (redirect, exp) s'écrit sous la forme nom=valeur et change la façon dont l'enregistrement entier est évalué plutôt que de correspondre à une IP.
Finalisez l'authentification de vos emails
SPF n'est qu'une partie de l'authentification email. Combinez-le avec DKIM et DMARC pour une protection complète contre l'usurpation et le phishing.