Guide
SPF, DKIM et DMARC : le guide pour les agences web
Trois enregistrements DNS, une demi-heure de travail, et deux problèmes réglés d'un coup : vos clients cessent de partir en indésirable, et personne ne peut plus écrire en leur nom. Voici comment les poser, dans le bon ordre, sans les casser.
8 min de lectureMis à jour le 25 août 2026
1. Pourquoi c'est devenu votre problème
Pendant quinze ans, l'authentification des e-mails a été l'affaire de l'hébergeur. Puis, en février 2024, Google et Yahoo ont durci leurs exigences pour les expéditeurs réguliers : SPF, DKIM et DMARC correctement posés, désabonnement en un clic, et un taux de plainte tenu bas. Un domaine mal configuré ne se voit pas refuser ses e-mails du jour au lendemain — il les voit simplement arriver de moins en moins souvent.
Le second problème est plus ancien et plus grave : sans ces réglages, n'importe qui peut envoyer un e-mail qui semble venir du domaine de votre client. C'est le point de départ de l'écrasante majorité des fraudes au virement. Le comptable reçoit un message de son patron, avec la bonne adresse d'expéditeur, et paie.
Vous n'êtes ni leur hébergeur ni leur prestataire de messagerie. Mais c'est vous qui avez la main sur leur zone DNS, et c'est vous qu'on appellera si leurs devis n'arrivent plus. Autant s'en occuper une fois, correctement.
2. SPF : qui a le droit d'écrire en votre nom
SPF est un simple enregistrement TXT posé à la racine du domaine, qui liste les serveurs autorisés à envoyer du courrier pour lui. Il commence toujours par « v=spf1 » et se termine par un mécanisme « all » qui dit quoi faire de tous les autres : « -all » les refuse, « ~all » les accepte en les marquant, « ?all » n'exprime aucun avis, et « +all » autorise le monde entier — celui-là est une faute, jamais une option.
Trois règles à ne pas oublier. Un seul enregistrement SPF par domaine : deux enregistrements font échouer le contrôle entier, et c'est l'erreur la plus fréquente quand on ajoute un nouvel outil d'envoi sans toucher à l'existant. Dix résolutions DNS au maximum : chaque « include », « a », « mx » ou « redirect » en consomme une, et au-delà de dix, la norme impose l'échec. Et le SPF ne protège que l'enveloppe technique du message, pas l'adresse que voit le destinataire — d'où DKIM et DMARC.
En pratique, commencez par « ~all » : les messages non autorisés sont acceptés puis marqués, ce qui vous laisse le temps de repérer un service d'envoi que vous auriez oublié. Vous passerez à « -all » une fois que les rapports DMARC ne remontent plus de surprise.
3. DKIM : la signature qui prouve que rien n'a bougé
DKIM signe chaque message avec une clé privée détenue par le serveur d'envoi. La clé publique correspondante est publiée dans le DNS, sous un nom de la forme « selecteur._domainkey.example.com ». Le destinataire recalcule la signature : si elle correspond, le message n'a pas été modifié en route et vient bien de qui il prétend.
Le sélecteur est choisi par votre prestataire de messagerie, et il peut porter n'importe quel nom. C'est la limite honnête de tous les outils publics, le nôtre compris : ils sondent une liste de sélecteurs courants, et ne rien trouver ne prouve pas qu'il n'y a rien. Pour en avoir le cœur net, la seule source fiable est l'interface de votre fournisseur — chez Google Workspace, c'est « Authentifier l'e-mail » dans la console d'administration.
Rien à écrire à la main ici : le fournisseur vous donne l'enregistrement, vous le collez dans la zone. La seule erreur possible est de l'activer côté fournisseur avant que le DNS ait propagé, ou l'inverse.
4. DMARC : ce qui se passe quand les deux échouent
DMARC est le troisième enregistrement TXT, posé sur « _dmarc.example.com ». Il fait deux choses. D'abord il vérifie l'ALIGNEMENT : que le domaine authentifié par SPF ou DKIM soit bien celui que le destinataire voit dans le champ « De ». Ensuite il donne une consigne : « p=none » observe sans rien bloquer, « p=quarantine » envoie les messages douteux en indésirable, « p=reject » les refuse purement.
La deuxième moitié de DMARC est celle qu'on oublie : la balise « rua » indique une adresse à laquelle les serveurs destinataires envoient des rapports quotidiens. C'est le seul moyen de savoir qui envoie du courrier au nom de votre domaine — y compris les services légitimes que le client a mis en place sans vous le dire.
Poser un DMARC en « p=none » ne protège de rien mais ne casse rien : c'est la bonne première étape. Le danger est de l'y laisser trois ans. Un DMARC en « none » indéfiniment, c'est une caméra de surveillance dont personne ne regarde les images.
Vérifiez sur votre domaine, tout de suite
Entrez le domaine d'un client : nous lisons ses trois enregistrements et vous disons en français ce qui manque et ce qui cloche. Aucun compte à créer.
5. Dans quel ordre les poser
SPF d'abord, DKIM ensuite, DMARC en dernier et en « p=none ». Cet ordre n'est pas une préférence : un DMARC posé avant que SPF et DKIM soient corrects et alignés commence immédiatement à faire échouer du courrier légitime.
Laissez tourner deux à quatre semaines en « p=none » et lisez les rapports. Vous y découvrirez à peu près toujours un service d'envoi que personne ne vous avait signalé : un formulaire de contact, un outil de facturation, une plateforme d'e-mailing installée par le client. Ajoutez-les au SPF, faites-leur signer en DKIM, et attendez que les rapports soient propres.
Passez alors à « p=quarantine », attendez encore deux semaines, puis à « p=reject ». Au total, comptez un à deux mois entre le premier enregistrement et la protection réelle. C'est long, et c'est la raison pour laquelle presque personne ne va au bout — c'est aussi ce qui rend le service intéressant à vendre.
6. Les cinq erreurs qu'on voit le plus
Deux enregistrements SPF sur le même domaine — souvent parce qu'on a ajouté une ligne au lieu de compléter l'existante. Plus de dix résolutions DNS dans le SPF, généralement à force d'empiler des « include ». Un SPF terminé par « +all », qui donne l'illusion d'une protection tout en autorisant la terre entière.
Un DMARC laissé en « p=none » pour toujours, sans adresse « rua », donc sans que personne ne lise jamais rien. Et un DKIM activé chez le fournisseur mais dont l'enregistrement DNS n'a jamais été collé — le plus sournois, parce que tout semble fonctionner jusqu'au jour où un destinataire strict refuse le message.
Aucune de ces cinq erreurs ne provoque de panne visible. Elles dégradent, lentement, la délivrabilité d'un domaine — et quand le client s'en aperçoit, il attribue le problème à autre chose.
Une fois posés, ils se dégradent quand même.
Un enregistrement SPF se casse le jour où quelqu'un ajoute un outil d'envoi. Une clé DKIM est retirée lors d'une migration. Un DMARC est écrasé par un copier-coller. DomainVigil relit ces trois enregistrements en continu sur tous vos domaines et vous prévient quand l'un d'eux change.
Cinq domaines gratuits, pour toujours. Sans carte bancaire.