SPF, DKIM et DMARC : pourquoi les voyants verts ne suffisent pas

Authentification des e-mails : pourquoi SPF, DKIM et DMARC ne suffisent pas

Vous avez fait le nécessaire. Vous avez passé des heures dans le DNS à copier les chaînes de caractères obscures fournies par vos prestataires d'envoi. Vous avez lancé les outils de validation et obtenu des voyants verts partout. Alors pourquoi les taux d'ouverture s'effondrent-ils ? Pourquoi les e-mails transactionnels, comme les réinitialisations de mot de passe, les factures et les alertes, arrivent-ils dans les indésirables ou disparaissent-ils complètement ?

Voici la dure réalité de l'authentification des e-mails avec SPF, DKIM et DMARC : une configuration valide ne garantit pas une bonne réputation. Une pièce d'identité en règle ne permet pas à une personne ivre de passer le videur. Depuis février 2024, des fournisseurs comme Google, Yahoo et Microsoft appliquent des exigences techniques plus strictes en plus d'évaluer si un message ressemble à du spam. Si votre tableau de bord affiche des voyants verts tandis que vos revenus passent au rouge, vous butez probablement sur l'un des contrôles cachés au-delà des acronymes de base.

Le piège de l'expéditeur de masse : un seuil plus bas qu'on ne le croit

L'idée reçue la plus dangereuse est la suivante : « J'envoie moins de 5,000 e-mails par jour, les règles applicables aux expéditeurs de masse ne me concernent donc pas. »

C'est faux pour deux raisons, et une configuration SPF, DKIM et DMARC correcte ne vous protège pas de ce piège. Premièrement, Google comptabilise le volume au niveau du domaine principal. Si vous envoyez 2,000 messages marketing depuis news.example.com, 2,000 messages transactionnels depuis app.example.com et 1,500 alertes internes depuis corp.example.com, vous êtes considéré comme un expéditeur de masse. Le volume des sous-domaines est agrégé au domaine racine.

Deuxièmement, il existe un niveau maximal historique. Si vous franchissez une seule fois le seuil de 5,000 e-mails, par exemple lors d'une campagne Black Friday ou d'une mise à jour ponctuelle de la base de données, Google peut classer définitivement votre domaine parmi les expéditeurs de masse selon ses règles en vigueur. Cette qualification reste applicable même si votre volume redescend à 50 messages par jour, et vous demeurez soumis aux exigences de conformité les plus strictes.

Microsoft applique des critères différents. Vos enregistrements SPF, DKIM et DMARC peuvent être impeccables, mais l'ancienneté de l'adresse IP compte également. Si vous lancez un nouveau domaine et une nouvelle IP, puis envoyez immédiatement 2,000 messages, Microsoft peut limiter le débit avec des erreurs 4xx même si SPF est valide. Le fournisseur ne connaît pas encore votre trafic, ce qui peut suffire à déclencher cette limitation.

Les modes d'échec de SPF, DKIM et DMARC : le triangle de fer

La plupart des administrateurs configurent SPF, DKIM et DMARC, vérifient la syntaxe, puis passent à autre chose. Pourtant, une syntaxe correcte ne garantit pas le bon fonctionnement. Voici où le mécanisme déraille.

SPF : le trou noir du transfert

SPF fonctionne comme une liste blanche d'adresses IP : il indique que « l'IP 1.2.3.4 est autorisée à envoyer pour example.com ». Tout marche jusqu'à ce qu'une personne active le transfert automatique.

Vous envoyez une facture à client@smallbiz.com. Ce client transfère tous ses messages vers client@gmail.com. Gmail voit la connexion depuis l'IP de smallbiz.com, pas depuis la vôtre. Il consulte votre enregistrement SPF, n'y trouve pas smallbiz.com et la vérification échoue. Si vous comptez uniquement sur SPF, le message transféré risque d'arriver dans les indésirables ou d'être rejeté. DKIM est indispensable pour que l'authentification survive à ce relais. Pour une configuration SPF complète, consultez notre guide des enregistrements SPF.

DKIM : le problème de l'alignement

DMARC vérifie deux éléments : si SPF ou DKIM, conformément à la RFC 6376, a réussi, et si les domaines sont alignés. L'alignement signifie que le domaine de l'en-tête From correspond aux domaines des en-têtes techniques, à savoir Return-Path pour SPF et d= pour DKIM.

Voici le scénario redouté des services d'assistance. Vous utilisez un CRM comme Zendesk ou HubSpot pour envoyer des messages sous l'adresse support@yourcompany.com. Le CRM gère les rebonds, donc Return-Path contient bounces.zendesk.com et l'alignement SPF échoue. Vous n'avez pas configuré de CNAME personnalisé, alors DKIM signe avec d=zendesk.com et l'alignement DKIM échoue lui aussi. Le message est techniquement authentifié, puisqu'il vient de Zendesk et porte sa signature, mais DMARC ne voit aucun protocole aligné avec votre domaine. Si votre politique est p=reject, le message est rejeté.

La limite de 10 requêtes

SPF, tel que défini par la RFC 7208, impose un plafond strict de 10 requêtes DNS par enregistrement. Si vous travaillez dans une agence dont les clients utilisent de nombreux outils SaaS, vous connaissez sans doute le problème. Google Workspace peut consommer à lui seul 4 requêtes. Ajoutez Mailchimp, HubSpot, un outil de gestion des tickets et un logiciel RH :

Chaque include: impose une requête DNS, et ces inclusions peuvent en contenir d'autres. Au-delà de 10 requêtes au total, le serveur destinataire renvoie PermError, interprété comme une absence d'enregistrement SPF. En cherchant à être exhaustif, vous finissez donc par priver vos messages d'authentification.

Les contrôles cachés au-delà de SPF, DKIM et DMARC

En plus des trois grands protocoles, certains impératifs techniques dépourvus de nom commercial accrocheur peuvent bloquer vos messages tout aussi rapidement.

FCrDNS (DNS inverse confirmé par résolution directe)

Chaque IP d'envoi doit avoir un enregistrement PTR, ou DNS inverse, qui se résout en nom d'hôte. Ce nom doit à son tour posséder un enregistrement A pointant vers l'IP d'origine. Cette vérification en boucle aide à prouver que vous contrôlez l'infrastructure. Si vous créez une machine virtuelle dans le cloud, installez Postfix et envoyez des messages sans enregistrement PTR, Gmail peut assimiler votre serveur à un botnet et renvoyer immédiatement 550 5.7.1.

RFC 8058 : désabonnement en un clic

Depuis juin 2024, un lien en pied de page ne suffit plus pour les messages marketing concernés par les exigences actuelles des grands fournisseurs. Vous devez inclure deux en-têtes précis :

Le point de terminaison HTTPS doit accepter une requête POST et non GET. Les robots antispam analysent les e-mails en « cliquant » sur les liens. Si le désabonnement utilise GET, ces robots risquent de désinscrire de vrais utilisateurs par erreur. Et si les destinataires ne trouvent pas de sortie simple, ils choisissent plutôt « Signaler comme spam », ce qui vous rapproche du seuil de plaintes de 0.3%.

Le seuil de 0.3% : l'économie de la réputation

Une authentification SPF, DKIM et DMARC parfaite, un FCrDNS irréprochable et des en-têtes impeccables ne servent à rien si les destinataires détestent votre contenu.

La mesure qui domine toutes les autres est le taux de plaintes pour spam. D'après les politiques décrites au moment de la publication, le seuil critique est de 0.3%, soit 3 plaintes pour 1,000 e-mails. Au-delà, Google peut aller jusqu'à bloquer entièrement votre domaine.

Le piège du dénominateur de la boîte de réception chez Yahoo

Yahoo peut calculer le taux de spam à partir des messages qui atteignent la boîte de réception plutôt que du nombre total envoyé. Vous envoyez 1,000 e-mails. La réputation de votre domaine est déjà fragile, donc 900 arrivent dans les indésirables et 100 dans la boîte de réception. Une personne se plaint. Le calcul donne 1/100 = 1.0%, soit un taux 3x supérieur au seuil d'application. Une seule plainte peut alors déclencher une spirale dont il est extrêmement difficile de sortir.

Le problème du voisin bruyant

Même avec SPF, DKIM et DMARC correctement configurés, un hébergement partagé classique ou une plateforme de messagerie « illimitée » bon marché fait partir vos messages depuis la même IP que ceux de milliers d'autres clients. Si l'un d'eux diffuse une escroquerie aux cryptomonnaies, Spamhaus peut inscrire l'IP sur une liste de blocage. Vos messages sont alors bloqués bien que vous n'ayez rien fait de mal. Vous partagez l'immeuble avec la source du problème, et les conséquences touchent tout le monde.

La liste du vendredi pour corriger SPF, DKIM et DMARC

1. Vérifiez les en-têtes : Envoyez un message vers une adresse Gmail personnelle. Ouvrez-le, cliquez sur les trois points, puis sur « Afficher l'original ». Cherchez Authentication-Results. SPF réussit-il ? DKIM réussit-il ? Le domaine de dkim= correspond-il au domaine de header.from ? Dans le cas contraire, vous avez un problème d'alignement.

2. Vérifiez le FCrDNS : Exécutez dig -x <your-sending-ip>. La commande renvoie-t-elle un nom d'hôte ? Exécutez dig <that-hostname>. Renvoie-t-elle l'IP ? Si la boucle échoue, arrêtez l'envoi et corrigez le DNS.

3. Séparez le trafic : N'envoyez jamais de marketing depuis votre domaine professionnel principal. Utilisez team@company.com pour les échanges entre personnes et newsletter@marketing.company.com pour les campagnes. Si le marketing atteint le seuil de 0.3%, la direction peut encore écrire aux investisseurs depuis le domaine principal.

4. Approfondissez : Pour comprendre la remise en état de la réputation, consultez notre guide sur la réputation de l'expéditeur et notre analyse détaillée de la réputation du domaine de messagerie.

Offres TrekMail

Selon les conditions actuelles, toutes les offres payantes comprennent un essai de 14-day (carte requise). Free ne demande pas de carte.

Conclusion

L'authentification des e-mails avec SPF, DKIM et DMARC n'est pas une tâche à configurer une fois pour toutes. C'est une exigence opérationnelle continue. Réussir les contrôles ne constitue que le droit d'entrée. Pour rester réellement dans la boîte de réception, il faut un alignement strict, une hygiène réseau irréprochable, notamment FCrDNS et les en-têtes de désabonnement en un clic, ainsi qu'une stratégie de réputation qui vous protège des autres expéditeurs. Ne vous contentez pas des réglages par défaut. Gardez le contrôle de votre infrastructure.

Obtenir des voyants verts pour SPF, DKIM et DMARC est le prix d'entrée, pas la ligne d'arrivée. Essayez TrekMail gratuitement et prenez vraiment le contrôle de l'authentification de vos e-mails.