SPF, DKIM et DMARC expliqués : pourquoi les messages sont refusés

Trois mécanismes aux responsabilités différentes

SPF publie les systèmes autorisés à envoyer pour un domaine et se vérifie par rapport au domaine technique Envelope-From. DKIM ajoute une signature cryptographique dont la clé publique est publiée dans le DNS. DMARC relie l’authentification au domaine From visible et publie une politique demandée en cas d’échec.

Un message satisfait DMARC lorsqu’au moins l’un des contrôles SPF ou DKIM réussit et que le domaine ainsi authentifié est aligné avec le domaine de l’expéditeur visible. L’alignement empêche un attaquant d’utiliser un expéditeur visible sans rapport simplement parce qu’il contrôle un autre domaine d’envoi authentifié.

Lire ces exemples d’enregistrements DNS

Ces enregistrements example.com illustrent la syntaxe, et non une configuration à copier aveuglément. La clé DKIM abrégée n’est pas une clé fonctionnelle. Les enregistrements réels doivent correspondre aux services et aux clés autorisés pour le domaine.

• SPF : example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all"
• DKIM : default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
• DMARC : _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
• p=none demande une observation sans politique de quarantaine ni de rejet fondée sur DMARC ; p=quarantine demande un traitement comme message suspect ; p=reject demande le rejet.

Ne pas choisir reject sans vérifier les expéditeurs

Un déploiement contrôlé commence généralement par p=none et une boîte de réception des rapports. Les rapports révèlent les sources légitimes, les systèmes de newsletter oubliés et les abus. Corrigez les sources et la configuration DKIM, puis introduisez progressivement quarantine ou reject, éventuellement sur un pourcentage limité. Ne durcissez la politique que lorsque le trafic légitime est aligné de manière fiable.

Publiez un seul enregistrement SPF par domaine et respectez sa limite de recherches DNS. Les longues chaînes include constituent un risque d’exploitation. Utilisez des clés DKIM suffisamment robustes et planifiez leur rotation. Sous-domaines, transferts et expéditeurs tiers exigent une conception délibérée plutôt que des modifications DNS isolées. Des enregistrements SPF multiples, des include incorrects et un alignement absent sont des erreurs fréquentes.

L’authentification contribue à la confiance sans être un filtre antispam

SPF, DKIM et DMARC renforcent les bases de la confiance du destinataire. L’authentification accompagne des habitudes d’envoi cohérentes, des listes entretenues et un faible taux de plaintes. Réussir les contrôles ne garantit pas l’arrivée dans la boîte de réception, tandis qu’une mauvaise configuration peut fortement perturber le courrier légitime.

Surveillez les modifications DNS, les signatures DKIM et les rapports DMARC. Un nouveau service d’envoi ne doit entrer en production qu’après vérification du domaine expéditeur, du Return-Path, de DKIM et des messages de non-remise. Une signature invalide ou absente exige une enquête contextualisée, plutôt que supposer que tout message sans DKIM a nécessairement été modifié.