// comment corriger
« 550 5.7.23 The message was rejected because of Sender Policy Framework violation » (échec SPF) : comment le corriger
Le destinataire a refusé votre email car votre enregistrement SPF n'autorise pas le serveur qui l'a envoyé. Trouvez ce serveur et mettez à jour votre SPF.
Ce que ça veut dire
Le serveur destinataire a consulté l'enregistrement SPF de votre domaine et a constaté que le serveur qui a envoyé l'email n'est pas autorisé à envoyer pour votre domaine. Avec Microsoft 365 et Exchange, le message d'erreur ressemble à ceci :
550 5.7.23 The message was rejected because of Sender Policy Framework violation
D'autres serveurs utilisent des formulations plus courtes. Le message ressemble généralement à l'un de ceux-ci :
550 5.7.1 SPF fail - not authorized 550 5.7.1 Rejected by SPF
Le SPF (Sender Policy Framework) est un enregistrement TXT dans le DNS de votre domaine qui liste les serveurs autorisés à envoyer des emails pour lui. Quand un serveur absent de la liste envoie un email, le SPF « échoue ». Si l'enregistrement se termine par -all (« refuser tout le reste »), beaucoup de destinataires refusent l'email immédiatement.
Pourquoi cela arrive
- Un expéditeur manque dans le SPF. Vous avez commencé à utiliser un outil de newsletter, un CRM, une boutique en ligne, un outil de facturation ou un nouveau fournisseur de messagerie, sans l'ajouter.
- L'IP de votre serveur a changé (nouvel hébergement, nouveau VPS) et le SPF indique toujours l'ancienne.
- Deux enregistrements SPF existent pour le domaine. C'est invalide, et le SPF échoue pour tous les expéditeurs.
- Trop de requêtes. Le SPF n'autorise que 10 requêtes DNS (chaque
include:,aoumxcompte). Au-delà, le SPF renvoie une erreur que certains destinataires traitent comme un échec. - Le transfert. L'email a été envoyé à une adresse qui le transfère vers Microsoft 365 ou une autre boîte. Le serveur qui transfère n'est pas dans votre SPF, donc la vérification échoue à cette étape.
- Quelqu'un d'autre usurpe votre domaine. Dans ce cas, le refus signifie que le SPF fait son travail.
Comment vérifier
- Lancez un test Delivmail. Depuis l'application ou le serveur qui a reçu l'erreur, envoyez un email à l'adresse unique de la page d'accueil (
/). Le rapport affiche l'IP d'envoi, le domaine vérifié par le SPF (l'expéditeur d'enveloppe, ou Return-Path) et le résultat SPF avec sa raison. - Scannez votre domaine. Utilisez
/domain-scannerpour lire votre enregistrement SPF. Il indique s'il y a deux enregistrements, une erreur de syntaxe ou trop de requêtes. - Lisez les en-têtes du message d'erreur. Il contient souvent une ligne comme
Received-SPF: Failavec l'IP qui a été vérifiée.
Comment corriger
- Identifiez le service d'envoi. Le rapport Delivmail affiche l'IP. La documentation du service indique son include SPF, par exemple
include:spf.protection.outlook.compour Microsoft 365 ouinclude:_spf.google.compour Google Workspace. - Ajoutez-le à votre unique enregistrement SPF. Modifiez l'enregistrement existant, n'en créez pas un second :
v=spf1 include:spf.protection.outlook.com include:spf.newsletter-example.com ip4:203.0.113.10 -all
- Fusionnez les doublons. Si vous avez deux enregistrements
v=spf1, regroupez-les en un seul. - Restez sous les 10 requêtes. Retirez les services que vous n'utilisez plus. Remplacez
aetmxparip4:quand vous connaissez l'IP. - Envisagez
~allpendant vos tests. Il marque les expéditeurs inconnus comme suspects au lieu de les refuser. Revenez à-allune fois que tout passe. - Configurez aussi le DKIM. Le DKIM signe l'email et résiste au transfert. Avec le DKIM et le DMARC en place, les destinataires s'appuient moins sur le SPF seul.
Si le transfert est en cause
Demandez à la personne de transférer autrement (une règle de boîte qui redirige avec SRS, ou une récupération directe du courrier), ou assurez-vous que vos emails sont signés en DKIM pour que le DMARC puisse quand même passer.
Vérifiez que c'est corrigé
Attendez que la modification DNS se propage (souvent quelques minutes, jusqu'au TTL de l'enregistrement, parfois quelques heures). Lancez le scanner de domaine pour confirmer qu'il n'y a qu'un seul enregistrement SPF valide, puis envoyez un nouveau test Delivmail depuis le même service : le SPF doit afficher pass. Enfin, renvoyez l'email à l'adresse qui l'avait refusé.
Vérifiez que c'est corrigé
Une modification DNS peut prendre de quelques minutes à quelques heures. Ensuite, envoyez un nouvel email de test ou scannez à nouveau votre domaine.
Fiches liées
- Aucun enregistrement SPF sur votre domaineVotre domaine n'indique pas quels serveurs ont le droit d'envoyer des emails en son nom. Ajoutez un enregistrement TXT et les destinataires sauront distinguer vos vrais emails des faux.
- Erreur SPF : trop de requêtes DNS (permerror)Le SPF autorise au maximum 10 requêtes DNS. Au-delà, tout l'enregistrement est cassé et les destinataires le considèrent comme invalide. Voici comment l'alléger.
- Plusieurs enregistrements SPF sur un même domaineUn domaine ne doit avoir qu'un seul enregistrement SPF. Avec deux ou plus, le SPF échoue pour tous vos emails. Fusionnez-les en une seule ligne.
- Échec SPF : le serveur d'envoi n'est pas autoriséVotre domaine a un enregistrement SPF, mais le serveur qui a envoyé votre email n'y figure pas. Trouvez quel service a envoyé l'email et ajoutez-le.
- Aucune signature DKIM sur vos emailsLe DKIM ajoute une signature numérique qui prouve qu'un email vient bien de votre domaine. Activez-le chez votre fournisseur de messagerie et publiez sa clé dans le DNS.