Ces trois sigles reviennent dès qu'on parle d'e-mails qui n'arrivent pas, et ils sont presque toujours expliqués de façon interchangeable. Ils font pourtant trois choses différentes, et c'est justement pour cela qu'il faut les trois.
Le plus simple est de raisonner comme si votre domaine était une entreprise dont on essaie de vérifier le courrier.
SPF : la liste des expéditeurs autorisés
SPF répond à une question : ce serveur a-t-il le droit d'envoyer du courrier au nom de ce domaine ?
Vous publiez, dans les réglages publics de votre domaine, la liste des services autorisés à écrire en votre nom : votre messagerie professionnelle, votre site, votre logiciel de facturation, votre outil d'infolettre. Le serveur qui reçoit votre message consulte cette liste et vérifie que l'expéditeur y figure.
Concrètement, c'est une ligne de texte qui ressemble à ceci :
v=spf1 include:_spf.google.com include:sendgrid.net -all
Deux services autorisés, et -all qui signifie « tout le reste est illégitime ».
Ses deux limites, à connaître :
- Un seul enregistrement SPF par domaine. Deux enregistrements rendent l'ensemble invalide c'est-à-dire pire que rien. C'est ce qui arrive quand un prestataire ajoute le sien sans regarder l'existant.
- Dix consultations maximum. Chaque
include:déclenche une recherche. Au-delà de dix, la vérification échoue, même si tout est correctement listé.
DKIM : le sceau sur l'enveloppe
DKIM répond à une autre question : ce message est-il bien celui qui a été envoyé, sans modification en route ?
Votre serveur d'envoi signe chaque message avec une clé privée. La clé publique correspondante est publiée dans les réglages de votre domaine, ce qui permet au destinataire de vérifier la signature. Si le message a été altéré pendant le transport, la signature ne correspond plus.
C'est complémentaire de SPF, et pas redondant : SPF valide le serveur qui envoie, DKIM valide le message lui-même. DKIM a d'ailleurs un avantage pratique : la signature survit à une redirection automatique, là où SPF échoue souvent.
DMARC : la consigne, et les rapports
Voilà la pièce qu'on oublie, et sans laquelle les deux premières ne servent pas à grand-chose.
SPF et DKIM produisent un résultat : réussi, ou échoué. Mais ils ne disent pas ce qu'il faut faire en cas d'échec. Sans instruction, chaque serveur destinataire décide seul et beaucoup livrent quand même le message, faute de consigne.
DMARC apporte deux choses :
- Une consigne : que faire d'un message qui échoue ? Le laisser passer et m'en informer (
p=none), le mettre en quarantaine (p=quarantine), ou le refuser (p=reject). - Des rapports quotidiens, envoyés à l'adresse que vous indiquez, listant qui envoie du courrier en votre nom et ce que ça a donné.
v=DMARC1; p=none; rua=mailto:rapports@votredomaine.fr
C'est ce second point qu'on sous-estime le plus : DMARC est le seul mécanisme qui vous informe. Sans lui, vous n'avez aucun moyen de savoir qu'un de vos outils légitimes échoue à l'authentification, ni que quelqu'un usurpe votre domaine pour envoyer des factures frauduleuses à vos clients.
L'alignement, la subtilité qui fait échouer les configurations correctes
Un détail technique aux conséquences très concrètes : DMARC n'exige pas seulement que SPF ou DKIM réussisse, il exige que le domaine validé soit le même que celui affiché au destinataire.
Le cas typique : votre outil d'infolettre envoie depuis ses propres serveurs, SPF réussit mais pour son domaine, pas pour le vôtre. Résultat : SPF est vert, DMARC échoue quand même. C'est pour cela qu'un outil d'envoi tiers doit toujours être configuré avec une signature DKIM à votre nom.
Ce que ça donne ensemble
| Question posée | Ce qui est validé | Sans lui | |
|---|---|---|---|
| SPF | Ce serveur est-il autorisé ? | le serveur d'envoi | n'importe qui peut envoyer en votre nom |
| DKIM | Le message est-il intact ? | le contenu du message | un message peut être altéré en route |
| DMARC | Que faire si ça échoue ? | la cohérence des deux, et la consigne | les échecs passent quand même, et vous n'en savez rien |
Comment savoir où vous en êtes
Le plus rapide est de tester : notre outil SPF et DMARC lit les enregistrements publics de votre domaine et affiche ce qui est présent, ce qui est incomplet et ce qui manque. C'est une lecture passive, rien n'est envoyé ni modifié.
Ensuite, dans l'ordre : mettre en place les trois enregistrements voir la configuration pas à pas chez OVH puis choisir la bonne politique DMARC, ce qui mérite d'être fait progressivement et non d'un coup : p=none, quarantine ou reject.
Et si vos messages finissent malgré tout en indésirables, la cause est peut-être ailleurs : les sept causes, dans l'ordre à vérifier.
SPF et DKIM répondent à des questions. DMARC est le seul qui écoute la réponse.