N’importe qui peut saisir votre domaine dans le champ De (From) d’un e-mail. SPF, DKIM et DMARC permettent au serveur destinataire de vérifier si un message vient réellement de vous, et lui indiquent que faire dans le cas contraire. Bien configurés, ils rendent l’usurpation de votre domaine exact beaucoup plus difficile. Déployés dans la précipitation, ils peuvent bloquer vos propres factures.
Ce que fait chaque mécanisme
SPF (Sender Policy Framework, RFC 7208) est un enregistrement DNS TXT qui liste les serveurs autorisés à envoyer des e-mails pour un domaine. Le destinataire compare l’adresse IP du serveur qui se connecte à cette liste. SPF vérifie l’expéditeur d’enveloppe (les identités MAIL FROM et HELO), et non l’adresse From que voit le destinataire.
DKIM (DomainKeys Identified Mail, RFC 6376) ajoute une signature cryptographique à chaque message. La balise d= indique le domaine signataire et s= un sélecteur. La clé publique est publiée dans le DNS sous selector._domainkey.domain. Une signature valide montre que les parties signées du message n’ont pas changé depuis que ce domaine l’a signé.
DMARC relie les deux au domaine From visible. Une version révisée a été publiée en mai 2026 sous la forme de la RFC 9989, un document de la voie de normalisation (Standards Track) qui remplace la RFC 7489. Un enregistrement DMARC énonce votre politique et demande aux destinataires de vous envoyer des rapports.
| Mécanisme | Ce qu’il prouve | Publié sur | Limite s’il est utilisé seul |
|---|---|---|---|
| SPF | L’IP d’envoi est autorisée pour le domaine d’enveloppe | Le domaine lui-même | Ne dit rien de l’adresse From que lisent les gens |
| DKIM | Un domaine se porte garant du message | selector._domainkey.domain | Le domaine signataire peut être n’importe quel domaine |
| DMARC | SPF ou DKIM a réussi pour un domaine qui correspond au domaine From | _dmarc.domain | Suppose que SPF et DKIM soient d’abord correctement configurés |
L’alignement, le point que l’on oublie
Un message passe DMARC lorsque SPF ou DKIM réussit et que le domaine authentifié est aligné sur le domaine From. L’alignement souple, par défaut, accepte une correspondance au niveau du domaine organisationnel : mail.example.eu est donc aligné sur example.eu. L’alignement strict (adkim=s ou aspf=s) exige une correspondance exacte.
C’est généralement avec les expéditeurs tiers que les choses se gâtent. Une plateforme d’envoi de newsletters peut utiliser un domaine d’enveloppe comme bounces.platform.example. SPF réussit pour le domaine de la plateforme, mais ce domaine n’est pas aligné sur example.eu : il n’apporte donc rien à votre résultat DMARC.
La solution consiste à faire signer la plateforme avec DKIM sous d=example.eu, ou à configurer une adresse de retour (return-path) personnalisée sur l’un de vos propres sous-domaines. La RFC 9989 recommande aux propriétaires de domaines d’utiliser à la fois SPF et DKIM. Ainsi, l’un peut encore porter le résultat lorsque l’autre échoue, par exemple après un transfert.
À quoi ressemblent les enregistrements
Les exemples ci-dessous utilisent une adresse IP réservée à la documentation et un fournisseur fictif. Remplacez-les par vos propres valeurs.
example.eu. TXT "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"L’enregistrement DMARC ci-dessus est en mode surveillance. Il demande des rapports agrégés, mais aucune action sur les e-mails en échec. Les rapports agrégés, désormais spécifiés dans la RFC 9990, montrent quels serveurs envoient des e-mails avec votre domaine et s’ils réussissent les contrôles.
Pour les clés DKIM, la RFC 6376 impose des clés RSA d’au moins 1024 bits pour les clés de longue durée. Google exige au moins 1024 bits pour les e-mails destinés aux comptes Gmail personnels et recommande 2048 bits lorsque votre fournisseur le permet.
Passer sans risque de p=none à p=reject
- Recensez tous les expéditeurs. Incluez votre plateforme de messagerie, votre CRM, vos systèmes de facturation et de paie, votre support client, les formulaires de votre site web et les appareils comme les scanners qui envoient des documents par e-mail.
- Configurez SPF et DKIM pour chacun. Demandez à chaque service de signer avec DKIM sous votre propre domaine, partout où il le permet.
- Publiez
p=noneavec une adresserua. La RFC 9989 présente ce réglage comme le point de départ habituel, afin de repérer les expéditeurs oubliés lors de la configuration. - Lisez les rapports et comblez les lacunes. Comptez au moins plusieurs semaines, et davantage si vous avez des envois mensuels ou trimestriels comme la paie ou les relevés annuels.
- Passez à
p=quarantine, puis àp=reject. La RFC 9989 a supprimé l’ancienne balisepct. Elle est remplacée par le mode test :t=ydemande aux destinataires d’appliquer la politique un niveau en dessous, si bien quep=reject; t=yest traité comme une mise en quarantaine. - Couvrez les sous-domaines et les domaines inutilisés. La balise
spfixe la politique des sous-domaines existants, et la nouvelle balisenpcouvre les sous-domaines qui n’existent pas.
Considérez t=y comme un assouplissement, pas comme une garantie. La RFC 7489 comme la RFC 9989 demandent aux destinataires d’ignorer les balises qu’ils ne reconnaissent pas. Un destinataire qui n’a pas encore adopté la nouvelle spécification peut donc appliquer votre politique publiée en totalité.
Pour l’étape 6, un domaine qui n’envoie jamais d’e-mails doit le dire explicitement. Publiez un enregistrement SPF qui n’autorise personne et une politique de rejet :
parked-example.eu. TXT "v=spf1 -all"
_dmarc.parked-example.eu. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu. TXT "v=DMARC1"Le troisième enregistrement est important, car les rapports sont envoyés vers un autre domaine. La RFC 9990 impose aux destinataires de vérifier, avant d’envoyer des rapports, que le domaine de destination a accepté de les recevoir pour le domaine concerné.
Les grands fournisseurs de messagerie attendent déjà ce travail. Depuis le 1er février 2024, Google exige des expéditeurs en masse (plus de 5 000 messages par jour vers Gmail) qu’ils utilisent SPF, DKIM et DMARC avec alignement. Une politique p=none satisfait ce minimum, mais ne protège pas votre domaine.
Les erreurs courantes
Deux enregistrements SPF
Un domaine ne peut publier qu’un seul enregistrement SPF. Si un destinataire en trouve plusieurs, le résultat SPF est permerror au lieu de pass. Lorsque vous ajoutez un nouveau service, intégrez son include à l’enregistrement existant au lieu d’en créer un second.
Plus de dix requêtes DNS
La RFC 7208 limite l’évaluation SPF à 10 termes qui déclenchent des requêtes DNS : include, a, mx, ptr, exists et le modificateur redirect. Les include imbriqués dans vos include comptent aussi. Au-delà de la limite, le résultat est permerror.
Les termes ip4, ip6 et all ne comptent pas : lister vos propres serveurs par adresse aide donc. Supprimez les include des services que vous n’utilisez plus. La RFC suggère aussi de limiter à deux les « requêtes vides » (void lookups), c’est-à-dire celles qui ne renvoient aucune réponse.
+all et ?all
Le mécanisme all correspond toujours, et c’est son qualificateur qui détermine le résultat. +all autorise donc tous les serveurs d’Internet : ne le publiez jamais. ?all renvoie un résultat neutre, qui, selon la RFC 7208, doit être traité exactement comme une absence de résultat SPF. Utilisez ~all (softfail) ou -all (fail).
Lequel des deux ? La spécification DMARC d’origine (RFC 7489, section 6.7) relève que rejeter un message sur un échec SPF empêche le destinataire d’évaluer DKIM. Cela peut pénaliser les e-mails transférés, pour lesquels SPF échoue alors que la signature DKIM reste valide. Une fois DMARC appliqué, ~all laisse DMARC prendre la décision finale.
Ignorer les transferts et les listes de diffusion
Un message transféré arrive depuis l’adresse IP du serveur de transfert, qui ne figure pas dans votre enregistrement SPF. Une signature DKIM survit généralement au transfert si le message n’est pas modifié. Les listes de diffusion qui modifient l’objet ou ajoutent un pied de page peuvent toutefois la casser. C’est pourquoi une signature DKIM fiable sous votre propre domaine compte davantage que SPF lorsque vous passez à p=reject.
Utiliser ptr
La RFC 7208 indique que le mécanisme ptr ne devrait pas être publié. Il est lent, moins fiable, et compte quand même dans la limite de requêtes.
Appliquer la politique sans lire les rapports
Passer directement à p=reject est un moyen sûr de bloquer vos propres réinitialisations de mot de passe, factures ou réponses du support. Les rapports vous indiquent les expéditeurs oubliés. Lisez-les avant d’appliquer la politique, et continuez ensuite, car de nouveaux services s’ajoutent.
Par où commencer
- Vérifiez ce que publie aujourd’hui votre domaine avec notre contrôle de sécurité e-mail.
- Créez ou remettez en ordre vos enregistrements avec le générateur SPF et DMARC.
- Notez chaque système qui envoie des e-mails au nom de votre domaine. Vous aurez besoin de cette liste avant d’appliquer la politique.
- Publiez dès maintenant
p=noneavec une adresse de rapport, et fixez une date pour examiner les premiers rapports. - Ajoutez
v=spf1 -allet un enregistrement DMARCp=rejectà chaque domaine qui vous appartient et n’envoie pas d’e-mails.
Si vous préférez confier l’analyse des rapports et le passage à l’application de la politique, notre service de sécurité managée peut vous aider sur ces deux points.
