Guide : authentification
Configurer SPF
SPF permet à un serveur destinataire de vérifier si le serveur qui lui remet un message est autorisé à envoyer pour le domaine de son enveloppe. Un seul enregistrement DNS suffit, et les petites erreurs y sont fréquentes.
Dernière vérification : 4 novembre 2026
Ce que vérifie SPF
Sender Policy Framework (SPF, RFC 7208) est un enregistrement TXT de votre domaine qui liste les serveurs autorisés à envoyer du courrier pour lui. À l’arrivée d’un message, le serveur destinataire lit l’enregistrement du domaine de l’expéditeur d’enveloppe (le MAIL FROM de SMTP, aussi appelé Return-Path) et le compare à l’adresse IP qui s’est connectée.
SPF ne regarde pas l’adresse From que voient vos destinataires. C’est pourquoi SPF seul n’empêche personne d’afficher votre domaine dans le From : DMARC comble ce manque en exigeant que le domaine vérifié soit aligné avec le domaine du From.
Un enregistrement pour tous les expéditeurs
Un domaine ne peut publier qu’un seul enregistrement SPF. Deux enregistrements commençant tous deux par v=spf1 font échouer la vérification avec une erreur permanente ; lorsque vous ajoutez un service, ajoutez donc son include à l’enregistrement existant au lieu d’en créer un second.
Un enregistrement commence par v=spf1, liste des mécanismes et se termine en général par un mécanisme all qui indique quoi faire de tous les autres. L’exemple ci-dessous est illustratif : il conserve un fournisseur existant (remplacez _spf.example.com par l’include de votre fournisseur) et ajoute Mail.Land.
- include:domaine ajoute les serveurs qu’autorise un autre domaine ; c’est la façon habituelle d’ajouter un service d’e-mail.
- ip4: et ip6: listent directement vos propres adresses ou plages.
- a et mx autorisent les hôtes des enregistrements A ou MX de votre domaine.
- ~all (soft fail) signale les autres expéditeurs comme suspects ; -all (fail) indique qu’ils ne sont pas autorisés. Ne terminez jamais par +all, qui autorise n’importe qui.
v=spf1 include:_spf.example.com include:spf.mlnd.net ~allRester sous la limite de requêtes
Les mécanismes include, a, mx, ptr et exists et le modificateur redirect comptent chacun dans une limite de 10 termes nécessitant une requête DNS par évaluation, et les termes d’un enregistrement inclus comptent aussi. Au-delà, le résultat est une erreur permanente et les destinataires considèrent l’enregistrement comme cassé.
Retirez les services que vous n’utilisez plus, préférez des plages ip4 ou ip6 pour vos propres serveurs et évitez le mécanisme ptr, que le standard demande de ne pas utiliser.
Vérifier le résultat
Après publication, envoyez un message vers une boîte que vous contrôlez et lisez l’en-tête Authentication-Results : il indique spf=pass, fail, softfail, neutral, none, permerror ou temperror, ainsi que le domaine vérifié.
Le transfert casse souvent SPF, car le serveur qui transfère ne figure pas dans votre enregistrement. C’est normal ; DKIM résiste en général à un transfert qui ne modifie pas le contenu signé, et c’est une raison de publier les deux.
Ce que demandent les fournisseurs de messagerie
Google demande à tout expéditeur de configurer SPF ou DKIM, et à ceux qui envoient près de 5 000 messages ou plus par jour vers des comptes Gmail personnels de configurer SPF, DKIM et DMARC. Yahoo demande aux expéditeurs en masse de mettre en place SPF et DKIM. Publier les deux est le choix sûr pour tout domaine qui envoie du courrier.
Comment Mail.Land gère SPF
Ajoutez include:spf.mlnd.net à l’unique enregistrement SPF de votre domaine d’envoi, avant le mécanisme all. SPF, DKIM et DMARC doivent tous être vérifiés avant que le domaine puisse envoyer.
Les nouveaux domaines reçoivent aussi un Return-Path personnalisé : un CNAME de bounce.yourdomain vers bounce.mlnd.net. Une fois cet enregistrement vérifié, le domaine d’enveloppe est votre propre sous-domaine et SPF est aligné avec votre domaine From en alignement relaxed, la valeur par défaut de DMARC ; d’ici là, Mail.Land utilise son Return-Path par défaut. Laissez l’enregistrement en DNS seul (sans proxy), sinon les serveurs de messagerie ne le voient pas.
Sources
- RFC 7208, Sender Policy Framework (SPF) (consultée le 4 novembre 2026)
- Google, consignes pour les expéditeurs d’e-mails (consultée le 4 novembre 2026)
- Yahoo, bonnes pratiques pour les expéditeurs (consultée le 4 novembre 2026)
Passez à la pratique
Ajoutez votre domaine à Mail.Land et le tableau de bord affiche exactement les enregistrements SPF, DKIM et DMARC à publier.