Une PME de services ajoute un nouvel outil de facturation. Comme le demande l’éditeur, l’équipe informatique ajoute un include: à l’enregistrement SPF du domaine. Le lendemain, les relances clients envoyées par le CRM commencent à arriver en spam, et le formulaire du site ne délivre plus ses accusés de réception chez certains destinataires. Les emails envoyés depuis Microsoft 365, eux, continuent de passer.
Derrière ces symptômes dispersés se cache une seule cause : spf=permerror. Le SPF du domaine est devenu invalide pour tous les expéditeurs, parce que son évaluation dépasse la limite de 10 requêtes DNS. Cette étude de cas déroule le diagnostic complet et la correction.
Scénario reconstitué. Ce cas combine des situations fréquentes observées en audit. Les domaines et prestataires sont fictifs, à l’exception de l’include Microsoft 365, dont le coût a été mesuré.
Les symptômes
- Les relances du CRM et les emails du formulaire web arrivent en spam chez plusieurs clients.
- Les emails des salariés, envoyés depuis Microsoft 365, ne sont pas touchés.
- Le problème est apparu juste après l’ajout de l’outil de facturation dans le SPF.
- Le domaine publie DMARC en
p=quarantinedepuis plusieurs mois.
Le contraste entre les flux est le premier indice. Microsoft 365 signe ses messages avec DKIM pour le domaine : DMARC passe grâce à DKIM, même si SPF échoue. Le CRM et le site, eux, n’ont pas de DKIM aligné. Ils ne comptaient que sur SPF. Quand SPF tombe, DMARC tombe avec.
Étape 1 : lire le résultat SPF dans les en-têtes
Un message du CRM, reçu sur une boîte de test, montre :
Authentication-Results: mx.example-client.com;
spf=permerror smtp.mailfrom=example.fr;
dkim=none;
dmarc=fail action=quarantine header.from=example.frpermerror n’est pas un fail. Le serveur n’a pas jugé l’IP non autorisée : il n’a pas pu évaluer l’enregistrement. Pour DMARC, le résultat est le même : SPF ne passe pas. Les rapports DMARC agrégés confirment le phénomène sur toutes les sources qui utilisent example.fr comme domaine d’enveloppe :
<spf><domain>example.fr</domain><result>permerror</result></spf>Étape 2 : compter les requêtes, includes compris
L’enregistrement du domaine ne paraît pas excessif :
dig +short TXT example.fr | grep spf1
"v=spf1 include:spf.protection.outlook.com include:spf.mkt-platform.example
include:_spf.crm.example include:mail.support.example
include:spf.invoices.example mx -all"Six mécanismes seulement. Mais la limite de la RFC 7208 porte sur les termes qui déclenchent une requête DNS pendant toute l’évaluation, y compris à l’intérieur des includes. Il faut donc ouvrir chaque include :
dig +short TXT spf.protection.outlook.com
# v=spf1 ip4:40.92.0.0/15 ... -all → 1 requête (l'include lui-même)
dig +short TXT spf.mkt-platform.example
# v=spf1 include:a.mkt... include:b.mkt... → 1 + 2 = 3 requêtesLe décompte complet donne :
| Source | Coût en requêtes |
|---|---|
Microsoft 365 (spf.protection.outlook.com) |
1 |
| Plateforme marketing | 3 |
| CRM | 3 |
| Outil de support | 2 |
| Outil de facturation (ajouté) | 2 |
mx |
1 |
| Total | 12 |
Avant l’ajout, le total était de 10 : le domaine était exactement à la limite, sans que personne ne le sache. L’include de facturation l’a fait basculer. La RFC est explicite : au-delà de 10, l’implémentation doit renvoyer permerror.
Étape 3 : chercher les autres causes de permerror
Le dépassement n’est pas la seule cause possible. Pendant l’audit, deux autres points sont vérifiés, car ils produisent le même résultat :
Un include vers un domaine sans SPF. D’après le tableau de la section 5.2 de la RFC 7208, si la cible d’un include: ne publie aucun SPF (résultat none), l’évaluation renvoie permerror. C’est le piège des anciens prestataires : leur domaine disparaît ou cesse de publier SPF, et votre enregistrement casse sans que vous ayez rien modifié.
Les requêtes « vides ». Une requête qui ne renvoie aucune réponse (domaine inexistant ou absence d’enregistrement) est une void lookup. La RFC recommande de les limiter à deux ; au-delà, le résultat est aussi permerror.
Deux enregistrements SPF. Deux TXT commençant par v=spf1 sur le même nom invalident SPF.
Dans ce cas, l’audit trouve en plus un include résiduel vers un ancien routeur d’emailing, retiré depuis l’enregistrement mais toujours présent dans une zone DNS secondaire. Ce n’est pas lui qui casse le domaine principal, mais il est supprimé au passage.
Étape 4 : corriger sans aplatir à l’aveugle
La tentation est de remplacer tous les includes par des adresses IP (flattening). Cela fait baisser le compteur, mais crée un risque de panne silencieuse quand un fournisseur change ses IP. Notre article sur la syntaxe SPF et le flattening détaille ce compromis. Ici, la correction suit un ordre plus durable :
- Retirer
mx. Les MX du domaine pointent vers Microsoft 365, déjà couvert par son include : le mécanisme est redondant. Gain : 1 requête. - Déplacer le marketing sur un sous-domaine. Les campagnes partent désormais de
news.example.fr, avec son propre SPF et une signature DKIM alignée. Gain : 3 requêtes sur le domaine principal. Voir notre guide pour créer un sous-domaine d’envoi. - Activer DKIM aligné sur le CRM et l’outil de facturation. Ces flux ne dépendent plus du seul SPF pour passer DMARC.
- Mesurer à nouveau. Le domaine principal tombe à 8 requêtes, avec une marge pour un futur outil.
example.fr. TXT "v=spf1 include:spf.protection.outlook.com include:_spf.crm.example include:mail.support.example include:spf.invoices.example -all"
news.example.fr. TXT "v=spf1 include:spf.mkt-platform.example -all"Étape 5 : vérifier
- Un message de chaque flux (CRM, site, facturation, Microsoft 365) est envoyé vers une adresse Gmail et une adresse Microsoft 365 : chaque en-tête doit afficher
spf=passetdmarc=pass. - Les rapports DMARC sont suivis pendant deux semaines :
permerrordoit disparaître de toutes les sources. - Une règle est documentée : tout ajout d’include est mesuré avant publication. Notre vérificateur de domaine gratuit affiche le coût de chaque terme SPF en requêtes DNS.
Les leçons à retenir
- Un SPF « court » peut être coûteux : seul l’arbre complet des includes compte.
- Un permerror touche tous les flux, pas seulement l’outil ajouté.
- Les flux sans DKIM aligné sont les premiers à tomber. DKIM aligné partout est la meilleure assurance contre un SPF fragile.
- La marge compte. Un domaine à 10 requêtes fonctionne, jusqu’au prochain outil ou jusqu’à ce qu’un fournisseur ajoute un include chez lui.
FAQ
Quelle différence entre SPF fail et SPF permerror ?
fail signifie que l’IP n’est pas autorisée. permerror signifie que l’enregistrement n’a pas pu être évalué : syntaxe invalide, plus de 10 requêtes, include vers un domaine sans SPF ou trop de requêtes vides.
Un SPF en permerror bloque-t-il tous mes emails ?
Pas forcément. Les flux signés DKIM pour votre domaine peuvent encore passer DMARC. Ceux qui ne comptent que sur SPF échouent, et sont mis en quarantaine ou rejetés si votre politique DMARC le prévoit.
Les mécanismes ip4 et ip6 comptent-ils dans la limite ?
Non. Seuls include, a, mx, ptr, exists et redirect déclenchent des requêtes comptées.
Comment savoir combien coûte un include ?
Il faut lire son enregistrement, puis ceux de ses propres includes, récursivement. Un outil de vérification SPF fait ce calcul automatiquement.
Le flattening est-il une bonne solution ?
C’est un dernier recours. Il réduit le compteur mais doit être surveillé, car les IP des fournisseurs changent. Simplifier l’architecture d’envoi est plus durable.
Conclusion
Un permerror SPF est une panne silencieuse : rien ne prévient au moment de la modification DNS, et les symptômes apparaissent ailleurs, chez les destinataires. Le diagnostic tient en trois gestes : lire les en-têtes, compter l’arbre complet des includes et vérifier les causes annexes. La correction durable passe par la séparation des flux et DKIM aligné, pas par un aplatissement précipité. Notre prestation d’audit et de configuration SPF, DKIM et DMARC inclut cette mesure et la documentation qui évite la rechute.