Authentification des emails : comprendre SPF, DKIM et DMARC

L'authentification des emails avec SPF, DKIM et DMARC est désormais une tâche essentielle. Si votre domaine envoie des messages professionnels en 2025 ou 2026, ces enregistrements influencent leur traitement avec de nombreux autres signaux. Pour choisir d'abord l'ensemble adapté, consultez la messagerie professionnelle des petites entreprises.

Beaucoup d'équipes pensent que les problèmes viennent uniquement du contenu. C'est parfois vrai, mais le domaine est souvent mal configuré : un SPF incorrect, une clé DKIM absente ou une politique DMARC jamais publiée. Les incidents peuvent alors apparaître : rejets dans Outlook, limitation de débit dans Gmail, campagne classée comme indésirable par Yahoo et difficultés de transfert.

La solution est simple en théorie, mais exigeante en pratique. SPF indique quelles IP peuvent envoyer pour le domaine d'enveloppe réel. DKIM atteste que le message a été signé et que les données signées n'ont pas subi de modification incompatible avec leur canonicalisation. DMARC demande un traitement en cas d'échec et vérifie si le domaine From visible est aligné avec le domaine authentifié. Une configuration correcte renforce la base technique sans garantir la distribution ni la boîte de réception.

Ce que font réellement SPF, DKIM et DMARC

Ces trois couches font partie des signaux utilisés par les hébergeurs de boîtes. SPF contrôle le parcours, DKIM la signature, et DMARC l'alignement et la politique. Lorsque les règles applicables aux envois en nombre l'imposent, publiez les trois ; pour réussir DMARC, il suffit qu'un résultat SPF ou DKIM soit positif et aligné.

Retenez ceci : DMARC n'exige pas que SPF et DKIM réussissent ensemble. Il faut que l'un des deux réussisse et soit aligné avec le domaine From visible pour le destinataire.

SPF : qui peut envoyer pour votre domaine

La première couche est SPF, une liste d'autorisation. Le serveur destinataire examine le domaine MAIL FROM, ou domaine d'enveloppe, consulte son enregistrement TXT SPF et détermine si l'IP connectée est autorisée. Ce mécanisme est rapide et utile, mais fragile : le transfert et les chaînes include trop longues peuvent le faire échouer.

SPF est publié dans le DNS sous forme de TXT. Exemple :

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Cette ligne signifie :

1. v=spf1 déclare le type d'enregistrement.
2. include: renvoie vers l'infrastructure d'envoi publiée par un autre domaine.
3. -all indique que tout le reste doit échouer.

De nombreuses configurations rencontrent ici la limite de 10 recherches de la RFC 7208. Le calcul comprend les mécanismes et modificateurs qui provoquent des recherches ainsi que les évaluations imbriquées derrière un include. Au-delà, le destinataire peut renvoyer PermError : l'évaluation SPF n'est pas valide.

Vous avez résilié un CRM il y a deux ans sans retirer son include:. La plateforme marketing en a ajouté trois et l'assistance un autre. Tout semblait correct jusqu'à l'évaluation complète de la chaîne.

SPF peut aussi échouer après un transfert. Si une université transfère le message à Gmail, Gmail peut voir le serveur de l'université comme source. Un SPF correct sur le parcours direct peut donc échouer après le transfert. SPF seul ne suffit pas.

Si vous envoyez avec TrekMail, sa documentation montre l'include requis et son intégration sans doublon : Enregistrements DNS requis.

DKIM : qui a signé le message et s'il a changé

La deuxième couche est DKIM. Il signe le message avec une clé privée et permet de vérifier la signature avec une clé publique dans le DNS. Contrairement à SPF, DKIM peut rester valide après un transfert si la signature est conservée et si les données signées respectent la canonicalisation. Une modification trop importante du corps ou des en-têtes signés le fait échouer.

Les enregistrements DKIM se trouvent sous un sélecteur tel que selector1._domainkey.example.com ou dkim._domainkey.example.com. L'expéditeur signe avec le sélecteur correspondant et le destinataire récupère la clé publique dans le DNS.

Une valeur DNS type ressemble à ceci :

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

Les erreurs opérationnelles sont souvent simples :

1. Les clés ont été renouvelées, mais le serveur utilise encore l'ancien sélecteur.
2. Vous avez changé de prestataire sans publier sa nouvelle clé publique.
3. L'hébergeur DNS a altéré la longue valeur TXT.
4. Une liste de diffusion a réécrit le corps et invalidé la signature.

Dans une configuration solide, utilisez par défaut des clés de 2048 bits lorsque le service et le DNS sont compatibles, sauf raison précise de faire autrement. Des systèmes anciens utilisent encore 1024 bits, mais il est préférable de planifier une migration compatible en 2026.

Sur les offres payantes TrekMail, les messages du domaine sont signés avec sa clé DKIM lors de l'utilisation du SMTP géré, selon la configuration actuelle. Cela peut maintenir une voie DMARC alignée après certains transferts si la signature reste valide. Pour diagnostiquer les échecs, consultez Mes emails arrivent dans les indésirables.

DMARC : les règles qui orientent les destinataires

La dernière couche est la politique DMARC. Elle s'appuie sur SPF et DKIM, demande un traitement en cas d'échec et contrôle l'alignement entre From visible et les domaines utilisés par SPF ou DKIM. Sans voie réussie et alignée, DMARC échoue.

Publiez l'enregistrement sur _dmarc.example.com. Commencez prudemment :

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Progressez après avoir recueilli suffisamment d'éléments :

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

p=none ne demande aucune restriction DMARC, mais le filtrage local continue. p=quarantine demande de traiter les échecs comme suspects. p=reject demande leur rejet. Il s'agit de politiques demandées, pas de garanties d'action ou de distribution.

L'autre difficulté est l'alignement. Exemple :

Visible From: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
DKIM domain: vendor.com

SPF peut réussir. DKIM peut réussir. DMARC échoue tout de même, car aucun ne s'aligne avec yourcompany.com.

C'est un problème courant avec Mailchimp, HubSpot, Zendesk et les CRM : le tableau du service est au vert, mais le domaine n'est pas aligné dans les messages réels. Les consignes actuelles de Google pour les expéditeurs en nombre vers les comptes Gmail personnels exigent SPF et DKIM, avec au moins un aligné sur From pour le courrier direct. Elles demandent aussi un enregistrement DMARC minimal, même avec p=none : FAQ Google pour les expéditeurs. Vérifiez la version et l'applicabilité actuelles.

SPF, DKIM ou DMARC : lequel compte le plus ?

Chaque protocole a un rôle distinct et aucun ne remplace les autres. Une signature DKIM valide résiste souvent mieux à certains transferts, SPF reste demandé par de nombreuses règles et DMARC ajoute politique et alignement. La configuration appropriée dépend des parcours et exigences applicables.

Dans une configuration simple, les trois mécanismes sont faciles à gérer. Avec un seul serveur sans expéditeur SaaS, SPF et DKIM sont généralement directs. Avec assistance, newsletter, CRM et transfert sur le même domaine, les rapports DMARC aident à voir ce qui est réellement aligné.

Pourquoi les transferts et listes provoquent encore des échecs étranges

Le transfert peut casser SPF, car le serveur intermédiaire transmet le message. DKIM peut conserver une voie valide, mais échoue aussi si un intermédiaire modifie le corps ou un en-tête signé de façon incompatible. Le résultat dépend du parcours et de la signature.

Une configuration parfaite sur le papier peut donc échouer chez de vrais destinataires. SPF échoue après le changement d'IP, DKIM parce qu'une liste ajoute un pied de page, puis DMARC faute de voie alignée restante.

Lorsque les trois échouent après un transfert, ARC permet aux intermédiaires de consigner l'historique observé. Le destinataire peut en tenir compte localement, mais ARC ne préserve ni ne transforme automatiquement un résultat DMARC. Les consignes Google traitent spécifiquement l'alignement DMARC du trafic indirect et recommandent des en-têtes ARC. L'expéditeur ne configure généralement pas ARC lui-même : maintenez DKIM valide et évitez les chaînes fragiles. Si le transfert est central, consultez le transfert de courrier.

Les contrôles cachés qui nuisent encore à la distribution

Des enregistrements valides ne garantissent pas la boîte de réception. Les fournisseurs examinent aussi DNS inverse, TLS, plaintes et désabonnement. SPF, DKIM et DMARC constituent un socle, pas l'ensemble du système.

1. DNS inverse validé par résolution directe : l'IP doit avoir un PTR et ce nom doit résoudre vers la même IP. Google inclut des DNS direct et inverse valides parmi ses exigences applicables.
2. TLS : les grands fournisseurs attendent un transport TLS ; Google cite l'absence de TLS parmi les causes possibles d'échec temporaire ou permanent.
3. Plaintes pour spam : les consignes actuelles de Google pour le trafic concerné recommandent un taux inférieur à 0.1% et de ne pas atteindre 0.3%.
4. Désabonnement en un clic : pour le courrier promotionnel soumis à ces règles, les fournisseurs attendent des en-têtes conformes à RFC 8058 en plus du lien visible.

Ces signaux comptent davantage pour un nouveau domaine. Une campagne brusque et une liste médiocre peuvent dégrader une réputation encore sans historique.

Configurer SPF, DKIM et DMARC sans perturber la production

Inventoriez d'abord tous les expéditeurs, publiez des enregistrements cohérents, vérifiez-les sur des messages réels et passez progressivement de l'observation à l'application. Sans inventaire, vous risquez d'interrompre un outil SaaS oublié.

1. Recensez chaque service utilisant le domaine : boîtes, CRM, assistance, newsletter, formulaires, facturation et serveurs.
2. Regroupez les expéditeurs dans un seul SPF. Ne publiez jamais deux TXT SPF.
3. Publiez DKIM pour chaque expéditeur qui nécessite son propre sélecteur.
4. Publiez d'abord DMARC avec p=none et étudiez plusieurs périodes représentatives.
5. Corrigez l'alignement de chaque expéditeur externe en activant le domaine personnalisé et testez des messages réels.
6. Passez par étapes à p=quarantine, puis p=reject après validation des routes courantes et rares, avec un plan de retour.

Pour un domaine TrekMail utilisant l'envoi géré, les enregistrements de base peuvent prendre cette forme selon la configuration actuelle :

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

La documentation détaille l'organisation et la vérification dans Enregistrements DNS requis et Vérification de l'état DNS. Pour une étape antérieure, lisez configurer la messagerie sur mon domaine.

Ancienne méthode et approche actuelle

L'ancienne méthode consistait à payer chaque utilisateur d'une suite étendue ou à exploiter son propre serveur tout en gérant DNS, TLS, sélecteurs et réputation. Une autre approche sépare les boîtes de l'envoi et utilise une plateforme qui facilite enregistrements, validation et migration sans tout lier au nombre d'utilisateurs. Sa pertinence dépend de l'environnement.

TrekMail peut s'inscrire dans ce modèle. D'après les conditions décrites par la source, Nano permet jusqu'à 10 domaines, 5 Go mutualisés et un SMTP personnel. Les offres payantes commencent à $3.50 par mois, incluent le SMTP géré et sont proposées sans tarification par boîte selon les conditions actuelles. Selon l'offre actuelle, domaines personnalisés, IMAP, catch-all, transfert, migration IMAP et accès API aux niveaux supérieurs peuvent aussi être disponibles. Les offres payantes ont un essai gratuit de 14 jours avec carte obligatoire. Nano est présenté comme gratuit et sans carte. Vérifiez les tarifs, fonctions et limites actuels.

Ce modèle peut simplifier l'exploitation de plusieurs domaines : un tableau, du stockage mutualisé, des enregistrements à copier et une migration côté serveur selon l'offre. La migration IMAP copie les messages, pas le DNS, les applications ou les routes. Consultez l'hébergement multidomaine et les chiffres actuels sur les tarifs TrekMail.

Conclusion : SPF, DKIM et DMARC forment désormais un socle

Ces contrôles ne sont plus réservés aux configurations avancées. SPF autorise l'IP pour le domaine d'enveloppe, DKIM valide la signature et DMARC lie une voie authentifiée au domaine From tout en publiant une politique demandée.

Si vous ne pouvez effectuer qu'une tâche cette semaine, publiez un SPF unique et valide, un DKIM opérationnel et DMARC avec p=none. Vérifiez ensuite chaque expéditeur avec des messages réels, étudiez les rapports partiels sur plusieurs périodes, testez les routes rares et avancez progressivement avec un plan de retour. Vous réduirez ainsi les incidents évitables sans promettre de résultat de distribution.