Un devis qui arrive dans les spams peut faire perdre une opportunité commerciale. SPF, DKIM et DMARC aident les serveurs destinataires à vérifier l’origine des messages envoyés au nom de votre domaine. Ce guide explique comment les déployer progressivement, sans interrompre les emails légitimes.
Comprendre les trois mécanismes
SPF : autoriser les serveurs d’envoi
SPF publie dans le DNS les infrastructures autorisées à émettre pour un domaine. Le contrôle porte sur le domaine de l’enveloppe SMTP (Return-Path), pas nécessairement sur l’adresse visible dans le champ From. Un domaine ne doit publier qu’un seul enregistrement SPF valide, même si plusieurs prestataires envoient des messages.
DKIM : signer les messages
DKIM ajoute une signature cryptographique vérifiable à l’aide d’une clé publique publiée dans le DNS. La signature doit être activée chez chaque fournisseur concerné et utiliser un domaine cohérent avec l’adresse d’expédition.
DMARC : aligner et définir une politique
DMARC vérifie qu’au moins SPF ou DKIM réussit avec un domaine aligné sur celui du From visible. Il permet de demander aux destinataires une politique de surveillance (p=none), de quarantaine ou de rejet. Ce n’est pas un filtre antispam universel.
Étape 1 : inventorier tous les expéditeurs
Recensez Microsoft 365, Google Workspace, CRM, newsletter, facturation, formulaires WordPress, applications métier et prestataires transactionnels. Notez pour chacun le domaine From, le Return-Path, les sélecteurs DKIM, les volumes et le responsable technique. Un oubli peut provoquer des rejets après durcissement de DMARC.
Étape 2 : publier SPF sans dépasser les limites
Récupérez la syntaxe exacte auprès de chaque fournisseur. Exemple purement illustratif, à ne pas copier sans adaptation : v=spf1 include:_spf.example.net ~all. Consolidez les mécanismes dans un seul TXT SPF et surveillez la limite de dix consultations DNS imposée par SPF ; les sous-requêtes et redirections comptent. Évitez de passer directement à -all tant que l’inventaire n’est pas fiable.
Étape 3 : activer DKIM chez chaque prestataire
Générez les clés dans l’interface du service, ajoutez les enregistrements TXT ou CNAME demandés puis lancez sa vérification. Le sélecteur forme généralement un nom tel que selector1._domainkey.example.com. Vérifiez que les signatures survivent aux relais et modifications du corps du message. Prévoyez une procédure de rotation des clés.
Étape 4 : démarrer DMARC en observation
Exemple illustratif : _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com". Créez d’abord une boîte ou un service capable de recevoir et traiter les rapports agrégés XML ; certains destinataires n’en transmettent pas. Le paramètre rua peut exposer des informations sur les infrastructures d’envoi : définissez un accès limité et une durée de conservation.
Étape 5 : tester l’alignement de bout en bout
Envoyez des messages de test depuis chaque outil vers plusieurs messageries. Examinez les en-têtes Authentication-Results : SPF, DKIM et DMARC doivent être évalués séparément. Testez les réponses aux formulaires, devis, relances et notifications de commande. Une réussite SPF isolée ne garantit pas DMARC si le domaine n’est pas aligné.
Étape 6 : renforcer progressivement la politique
Analysez plusieurs cycles de rapports et corrigez les flux non alignés. Passez ensuite, selon votre tolérance au risque, à p=quarantine puis p=reject. Les sous-domaines et les services tiers méritent des tests spécifiques. Conservez un plan de retour arrière DNS et documentez chaque changement.
Checklist de validation
- Un seul SPF par domaine, fournisseurs autorisés recensés et limite DNS contrôlée.
- DKIM actif pour chaque service, signatures vérifiées.
- DMARC publié et rapports suivis.
- Envois réels testés, alignement vérifié dans les en-têtes.
- Politique renforcée seulement après analyse des flux légitimes.
- Propriétaire, journal des modifications et procédure de retour arrière définis.
Erreurs fréquentes
Publier plusieurs SPF, copier un include obsolète, confondre réussite SPF et alignement DMARC, oublier les emails envoyés par un site WordPress, ou activer p=reject avant les tests. La propagation DNS varie selon les TTL et caches : ne concluez pas à un échec immédiat.
Sources techniques et accompagnement
Références : RFC 7208 (SPF), RFC 6376 (DKIM) et RFC 7489 (DMARC). Pour un audit des formulaires, notifications et intégrations de votre site, consultez notre guide de surveillance WordPress et notre page de maintenance de site web. Pour faire analyser votre configuration et planifier les corrections, contactez 3Vision Group.
