Si vos envois n’atteignent plus la boîte de réception, l’origine est souvent une mauvaise configuration DNS. Depuis 2024 et 2025, les filtres des fournisseurs exigent des preuves d’authentification email formelles pour accepter les messages.
Ce guide pratique présente les étapes concrètes pour configurer SPF DKIM DMARC sur Outlook et Microsoft 365. Consultez la section A retenir : pour connaître les priorités techniques à appliquer immédiatement.
A retenir :
- SPF DKIM DMARC configurés pour la messagerie principale
- DMARC en p=none puis montée progressive vers p=reject
- SPF sans plus de dix lookups DNS contrôlés
- DKIM 2048 bits et rotation régulière des clés
Face à ces priorités, SPF pour Outlook et Microsoft 365 : configurer l’enregistrement DNS
SPF : principe et mise en place pour Microsoft 365
Sur SPF, l’objectif est de déclarer les serveurs autorisés pour votre domaine. Selon Google, la présence d’un enregistrement TXT correct réduit les rejets et améliore la délivrabilité. Commencez par lister tous vos services d’envoi avant de publier l’enregistrement racine.
Liste des services : Identifiez chaque plateforme qui envoie au nom du domaine. Cette vérification inclut Microsoft 365, outils transactionnels, plateformes de cold email et CRM externes.
- Microsoft 365 (Exchange Online)
- Google Workspace
- SendGrid ou équivalent
- Outils de prospection externes
SPF : pièges courants et diagnostic
À présent, comprendre les pièges permet d’éviter les erreurs fatales sur SPF. La limite des 10 lookups DNS provoque souvent une erreur PermError si elle est dépassée. Si nécessaire, utilisez un service de SPF flattening pour aplatir les includes en adresses IP.
Date
Acteur
Mesure
Février 2024
Google / Yahoo
Exigence d’authentification pour gros expéditeurs
Juin 2024
Google
SPF et DKIM obligatoires pour tous les expéditeurs
Mai 2025
Microsoft
Rejet des envois non conformes vers Outlook
Novembre 2025
Google
Renforcement des rejets permanents pour emails non authentifiés
« J’ai vu une campagne entière rejetée avant de corriger notre SPF, la perte était immédiate. »
Jean N.
Une fois SPF maîtrisé, DKIM pour Outlook et Microsoft 365 : signatures cryptographiques et clés
DKIM : génération de clé et publication dans la zone DNS
Sur DKIM, il faut générer une paire de clés et publier la clé publique au sélecteur indiqué. Selon Microsoft, l’utilisation d’une clé 2048 bits est aujourd’hui la recommandation pour une meilleure résistance. Activez la signature dans l’interface du fournisseur après vérification DNS.
Points DKIM : Vérifiez chaque sélecteur publié et planifiez une rotation régulière des clés. La rotation toutes les six à douze mois limite la fenêtre de risque en cas de fuite de clé privée.
- Clé 2048 bits recommandée
- Rotation régulière des sélecteurs
- Validation après propagation DNS
- Multi-sélecteurs pour plusieurs services
Selon RFC 6376, DKIM fournit l’intégrité du message signée par la clé privée. Contrairement à SPF, DKIM survit au forwarding tant que le contenu reste inchangé. Ce comportement en fait un pilier de l’authentification email moderne.
« J’ai activé DKIM 2048 bits sur nos boîtes, et le forwarding de clients est revenu fiable. »
Claire N.
Élément
Description
Recommandation
Taille de clé
Longueur de la clé publique DKIM
2048 bits
Sélecteur
Identifiant pour la paire de clés
Nom unique par service
Rotation
Période de remplacement des clés
6 à 12 mois
Propagation
Temps DNS avant validation
5 à 60 minutes
Après DKIM, DMARC pour Outlook et Microsoft 365 : politiques, rapports et passage progressif
DMARC : politique initiale, rapports RUA et analyse
Après DKIM, DMARC apporte la gouvernance et la visibilité sur les envois au nom du domaine. Selon RFC 7489, DMARC repose sur l’alignement entre le From et les identifiants vérifiés par SPF ou DKIM. Démarrez en p=none pour collecter les rapports sans impacter la livraison.
Étapes DMARC : Publiez un enregistrement DMARC avec rua vers une adresse dédiée au monitoring. Analysez quotidiennement les rapports RUA pour identifier les sources non déclarées ou les échecs d’alignement.
- Publier DMARC en p=none pour surveillance
- Analyser les rapports RUA quotidiennement
- Passer à p=quarantine puis p=reject progressivement
- Utiliser des outils d’analyse pour parser XML
« Après six semaines en p=none, nous avons corrigé des envois oubliés et sécurisé notre domaine. »
Marc N.
DMARC : erreurs fréquentes et bonnes pratiques opérationnelles
Pour éviter les erreurs, ne publiez pas plusieurs enregistrements SPF et ne passez pas trop vite en p=reject. Selon Microsoft, une montée graduelle vers p=reject après validation protège contre les blocages intempestifs. Isoler la prospection sur un domaine dédié limite l’impact sur la réputation du domaine principal.
« À mon avis, la surveillance DMARC a transformé notre gestion des envois et réduit le phishing. »
Anne N.