Un domaine ne doit publier qu'un seul enregistrement SPF. S'il en publie deux, la norme (RFC 7208, section 4.5) impose aux serveurs de réception de renvoyer une erreur permanente, appelée permerror : le SPF échoue alors pour tous les emails du domaine, y compris les légitimes. La panne passe souvent inaperçue, parce que la signature DKIM continue de faire passer DMARC. Pour corriger, fusionnez les deux enregistrements en un seul, qui regroupe tous les services d'envoi.
Le cas : un e-commerçant et deux SPF
Le scénario est banal. Un e-commerçant français envoie ses emails transactionnels avec Brevo et utilise des boîtes mail chez OVH. Son domaine publie un SPF :
v=spf1 include:spf.sendinblue.com mx ~all
Plus tard, il ajoute Mailjet pour ses newsletters. La documentation demande d'« ajouter un enregistrement TXT ». Il crée donc un second enregistrement, au lieu de modifier le premier :
v=spf1 include:spf.mailjet.com include:spf.sendinblue.com mx ~all
Les deux enregistrements cohabitent dans la zone DNS. Le site fonctionne, les commandes partent, aucun message d'erreur n'apparaît. Pourtant, depuis ce jour, plus aucun de ses emails ne passe le contrôle SPF.
Pourquoi deux SPF valent zéro SPF
Quand un serveur de messagerie reçoit un email, il cherche les enregistrements TXT du domaine expéditeur qui commencent par v=spf1. La RFC 7208 est explicite : s'il en trouve plus d'un, il ne choisit pas. Il arrête l'évaluation et renvoie permerror.
| Enregistrements v=spf1 publiés | Résultat SPF | Effet |
|---|
| Aucun | none | Rien n'indique quels serveurs peuvent envoyer |
| Un seul | pass, fail ou softfail | Évaluation normale |
| Deux ou plus | permerror | SPF en échec pour tous les emails, légitimes compris |
Les deux enregistrements ne s'additionnent donc pas. Ils s'annulent.
Pourquoi personne ne s'en aperçoit
Si le SPF échoue pour tous les emails, pourquoi les clients reçoivent-ils encore leurs confirmations de commande ? Parce que DMARC accepte un email si SPF ou DKIM est valide et aligné sur le domaine.
Brevo et Mailjet signent leurs envois avec DKIM, au nom du domaine du client. La signature DKIM reste valide, DMARC passe, et l'email arrive. Le SPF cassé reste invisible tant que DKIM tient.
Le problème réapparaît dès que DKIM fait défaut :
- un email envoyé depuis une boîte OVH ou Google sans DKIM activé ;
- un formulaire du site qui envoie directement depuis le serveur web ;
- un email transféré, dont la signature est cassée par une modification en route ;
- un passage de DMARC en
quarantine ou reject : les emails sans DKIM valide partent alors en spam ou sont refusés.
Autre raison du silence : beaucoup d'outils de vérification ne lisent que le premier enregistrement v=spf1 trouvé. Ils l'analysent, le jugent correct, et annoncent « SPF OK ». Le second enregistrement, qui casse tout, n'est jamais examiné.
Le piège caché du mécanisme mx
Dans notre cas, les deux enregistrements contenaient un deuxième défaut : le mécanisme mx. Il autorise les serveurs listés dans les enregistrements MX du domaine, c'est-à-dire les serveurs qui reçoivent le courrier.
Chez OVH, les serveurs de réception (mx3.mail.ovh.net, mx4.mail.ovh.net…) ne sont pas ceux qui envoient. Les emails sortants des boîtes OVH partent d'autres serveurs, déclarés dans include:mx.ovh.com. Avec mx seul, les emails envoyés depuis les boîtes OVH ne sont pas couverts, même avec un SPF unique et valide.
La correction : un seul enregistrement fusionné
Supprimez les deux enregistrements existants et publiez-en un seul, qui reprend tous les services :
v=spf1 include:spf.mailjet.com include:spf.sendinblue.com include:mx.ovh.com ~all
- Listez tous les services qui envoient des emails avec votre domaine : outil d'emailing, messagerie, site web, CRM, facturation.
- Regroupez leurs mécanismes
include: dans un seul enregistrement, sans doublon.
- Gardez une seule terminaison
~all ou -all, à la fin.
- Restez sous 10 résolutions DNS : chaque
include, a, mx en coûte au moins une, et au-delà de 10 le SPF tombe aussi en permerror.
Le générateur SPF assemble l'enregistrement à partir des services cochés et compte les résolutions.
Comment vérifier votre domaine
Une seule commande suffit :
dig +short TXT votredomaine.fr | grep -i "v=spf1"
Comptez les lignes. Une ligne : tout va bien. Deux lignes ou plus : vous êtes dans le cas décrit ici. Sans terminal, la recherche DNS en ligne affiche tous les enregistrements TXT du domaine, et la vérification de sécurité email signale les doublons.
Même règle pour DMARC
DMARC obéit à la même logique. Un domaine doit publier un seul enregistrement TXT v=DMARC1 sur _dmarc.votredomaine.fr. S'il en publie plusieurs, la RFC 7489 (section 6.6.3) prévoit que le serveur de réception abandonne DMARC pour ce domaine. Votre politique, même en p=reject, ne s'applique plus.
dig +short TXT _dmarc.votredomaine.fr
La cause est la même que pour SPF : un service (Brevo, un outil de rapports DMARC) demande d'« ajouter » un enregistrement, et l'ancien reste en place. La correction aussi : gardez un seul enregistrement, en regroupant les adresses de rapport dans la balise rua, séparées par des virgules.
Pour aller plus loin sur le rôle de chaque mécanisme, voir SPF, DKIM et DMARC expliqués. Avant de durcir votre politique DMARC, lisez notre méthode pour passer de p=none à p=reject sans bloquer vos propres emails.
Éviter que ça se reproduise
Le doublon naît presque toujours au même moment : l'ajout d'un nouveau service d'envoi. Les guides d'installation des outils d'emailing disent « ajoutez cet enregistrement TXT », parce qu'ils ne savent pas ce que votre zone contient déjà. Quelques réflexes évitent le problème :
- Avant d'ajouter, cherchez l'existant. Ouvrez la zone DNS et filtrez les enregistrements TXT. S'il existe déjà une ligne qui commence par
v=spf1, modifiez-la au lieu d'en créer une autre.
- Notez qui envoie quoi. Une simple liste des services qui envoient avec votre domaine, tenue à jour, permet de reconstruire le SPF sans rien oublier.
- Revérifiez après chaque changement. Relancez la commande
dig ci-dessus, ou un audit gratuit du domaine, le jour même.
- Surveillez le SPF dans la durée. Un doublon peut aussi apparaître lors d'une migration DNS ou de l'intervention d'un prestataire. Une surveillance qui compare les enregistrements d'un jour à l'autre le repère avant que DMARC ne soit durci.
Enfin, si vous changez d'outil d'emailing, retirez l'ancien include:. Un service qui n'envoie plus rien ne doit plus être autorisé, et chaque include inutile consomme une des 10 résolutions DNS permises.
Questions fréquentes
Puis-je garder deux SPF si chacun est valide ?
Non. La validité de chaque enregistrement ne change rien : dès que deux enregistrements v=spf1 sont publiés, le résultat est permerror. Il faut les fusionner.
Un enregistrement TXT sans rapport avec SPF pose-t-il problème ?
Non. Les vérifications Google, Microsoft ou Brevo (google-site-verification=…, MS=…) sont des TXT différents. Seuls les enregistrements qui commencent par v=spf1 comptent.
Combien de temps faut-il pour que la correction soit prise en compte ?
Le temps que l'ancien enregistrement expire des caches DNS, selon son TTL : souvent une heure, parfois jusqu'à 24 heures. Revérifiez avec dig après ce délai.
Faut-il terminer par ~all ou -all ?
Les deux sont valides. ~all (échec souple) est plus prudent pendant que vous vérifiez vos envois ; -all (échec strict) protège davantage une fois la liste des services complète.
Mes emails arrivent quand même, faut-il corriger ?
Oui. Ils arrivent grâce à DKIM. Le jour où un email part sans DKIM, ou où vous durcissez DMARC, il n'y aura plus de filet.