Validez votre enregistrement Sender Policy Framework
DNS et enregistrements
Lookup DNS Tous les enregistrements DNS d'un domaine Lookup d'enregistrement A Adresses IPv4 d'un domaine Lookup d'enregistrement AAAA Adresses IPv6 d'un domaine Lookup MX Serveurs de messagerie d'un domaine Lookup NS Serveurs de noms faisant autorité Lookup TXT Enregistrements TXT, SPF, vérification Lookup CNAME Enregistrements de nom canonique (alias) Lookup SOA Enregistrement Start of Authority Lookup SRV Enregistrements de localisation de service Lookup CAA Quelles CA peuvent émettre des certificats DNS inversé (PTR) Adresse IP vers nom d'hôte Vérification DNSSEC Le domaine est-il signé et validé ? Diagnostic DNS Un bilan complet de délégation et de DNSDélivrabilité des e-mails
Vérification SPF Validez votre enregistrement Sender Policy Framework Vérification DMARC Inspectez et évaluez votre politique DMARC Vérification DKIM Trouvez et validez votre clé publique DKIM Vérification de liste noire Vérifiez une IP face aux listes de blocage e-mail (DNSBL) Test SMTP Connectez-vous à un serveur de messagerie et vérifiez STARTTLS Vérification MTA-STS Politique TLS imposée pour le courrier entrant Vérification BIMI Enregistrement de logo de marque pour l'e-mail Vérification TLS-RPT Politique de rapport TLS SMTPRéseau et web
Vérification de certificat SSL Inspectez le certificat TLS d'un site et son expiration Vérification des en-têtes HTTP Inspectez les en-têtes de réponse, redirections et sécurité Ping (TCP) Accessibilité et latence via TCP Vérification de ports Quels ports courants sont ouvertsDomaine
Lookup WHOIS Données d'enregistrement pour domaines, IP et ASNLe SPF (Sender Policy Framework) indique aux serveurs de messagerie destinataires quels hôtes sont autorisés à envoyer des e-mails au nom de votre domaine. Un enregistrement SPF défaillant — dupliqué, comportant trop de requêtes DNS ou dépourvu d'un mécanisme « all » — fait basculer les e-mails légitimes dans les spams. IPeek localise votre enregistrement SPF, analyse chaque mécanisme et signale les problèmes qui nuisent à la délivrabilité.
Le SPF se publie sous la forme d'un enregistrement TXT sur votre domaine racine, commençant par v=spf1. Lorsqu'un serveur reçoit un e-mail prétendument envoyé par vous, il interroge cet enregistrement et vérifie si l'IP d'envoi est autorisée. Un enregistrement tel que v=spf1 include:_spf.google.com ip4:198.51.100.10 -all signifie « autoriser les hôtes de Google et cette seule IP, rejeter tout le reste ». Les mécanismes sont évalués de gauche à droite ; la première correspondance l'emporte. Le mécanisme all en fin de chaîne est le « attrape-tout » qui décide du résultat par défaut pour tout hôte non explicitement listé.
Le mécanisme all définit votre politique : -all est un hardfail (rejet des expéditeurs non listés), ~all est un softfail (acceptation, mais marquage comme suspect) et +all autorise n'importe qui — à ne jamais utiliser. Le SPF plafonne également les mécanismes générant des requêtes DNS (include, a, mx, ptr, exists, redirect) à 10 requêtes au total ; au-delà, le résultat est un permerror, traité comme un échec. Les include imbriqués comptent eux aussi, si bien qu'ajouter plusieurs prestataires épuise discrètement le quota. IPeek comptabilise chaque requête et vous avertit avant que vous n'atteigniez le plafond.
Le SPF ne suffit pas à lui seul. Il authentifie l'expéditeur d'enveloppe (le return-path), et non l'adresse From visible par les utilisateurs : un usurpateur peut donc passer le SPF tout en falsifiant votre marque. DMARC comble cette faille en exigeant l'alignement entre le domaine SPF et le domaine From, et en associant le SPF à DKIM afin que l'un ou l'autre puisse authentifier un message. Considérez le SPF comme l'une des trois couches : le SPF autorise les hôtes, DKIM signe le contenu, et DMARC les relie à votre domaine From et applique la politique.
Le SPF autorise un maximum de 10 mécanismes générant des requêtes DNS par évaluation. Les mécanismes include, a, mx, ptr, exists et redirect consomment chacun des requêtes, et les include imbriqués comptent dans la même limite. Dépasser 10 produit un permerror, que les destinataires interprètent comme un échec d'authentification. Aplatissez ou regroupez vos include pour rester sous le plafond.
La différence tient à l'application. -all est un hardfail demandant aux destinataires de rejeter les e-mails de tout hôte absent de votre enregistrement, tandis que ~all est un softfail leur demandant de les accepter mais de les traiter comme suspects. Utilisez ~all pendant vos tests, puis passez à -all une fois que vous avez confirmé que chaque expéditeur légitime est autorisé. Évitez +all, qui autorise n'importe qui.
Un enregistrement SPF ne garantit pas à lui seul l'arrivée en boîte de réception. Les causes fréquentes incluent le dépassement de la limite des 10 requêtes (permerror), un mécanisme all absent ou trop permissif, un hôte d'envoi qui n'est pas réellement autorisé, ou des enregistrements SPF en double sur le même domaine. Le SPF ne protège pas non plus votre adresse From visible — il vous faut DKIM et DMARC à ses côtés pour une délivrabilité solide.
Non. Un domaine doit publier exactement un enregistrement TXT SPF (v=spf1). Deux enregistrements SPF ou plus provoquent un permerror, et les destinataires peuvent rejeter vos e-mails ou échouer leur authentification. Si vous devez autoriser plusieurs expéditeurs, regroupez-les dans un seul enregistrement à l'aide de mécanismes include ou ip4/ip6 supplémentaires plutôt que d'ajouter un second enregistrement.
Non. Le SPF authentifie l'expéditeur d'enveloppe (le return-path ou MAIL FROM), et non l'en-tête From que vos destinataires voient réellement. C'est pourquoi le SPF seul ne peut pas empêcher l'usurpation de votre marque. DMARC ajoute l'alignement SPF, exigeant que le domaine SPF corresponde au domaine From visible, ce qui comble l'écart entre les vérifications au niveau du protocole et ce que lisent les utilisateurs.