Configurer SPF, DKIM et DMARC pour Microsoft 365 (guide pratique 2026)

En 2026, Gmail, Yahoo, Outlook.com et la quasi-totalité des serveurs email B2B vérifient systématiquement SPF, DKIM et DMARC avant d'accepter un message. Un email sans ces records peut atterrir directement en spam — ou, pire, être silencieusement rejeté (soft fail ou hard fail selon la politique côté receveur). Pour une PME qui envoie des devis, des factures, ou des contrats par email, un taux de délivrabilité dégradé se traduit directement par du chiffre d'affaires perdu.

Les trois mécanismes remplissent des rôles distincts mais complémentaires :

• SPF (Sender Policy Framework) : publie la liste des serveurs autorisés à envoyer depuis votre domaine. Si quelqu'un tente d'envoyer un email « de votre part » depuis un serveur non listé, le check SPF échoue. Microsoft 365 impose que include:spf.protection.outlook.com figure dans votre enregistrement TXT.
• DKIM (DomainKeys Identified Mail) : ajoute une signature cryptographique à chaque email sortant. Le serveur destinataire vérifie la signature via une clé publique publiée dans vos DNS. Même si un email est réexpédié via un relais, la signature reste vérifiable. Microsoft 365 utilise deux sélecteurs DKIM (selector1 et selector2) publiés sous forme de CNAME.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) : orchestre les deux précédents. Il définit ce qu'un serveur destinataire doit faire si SPF ou DKIM échoue (ignorer, mettre en quarantaine, ou rejeter), et à quelle adresse envoyer les rapports d'incidents. Sans DMARC, SPF et DKIM n'ont aucun effet dissuasif sur le spoofing : un attaquant peut toujours envoyer un email dont le SPF échoue et qui atterrira peut-être en spam plutôt qu'en inbox, mais sans garantie de rejet.

Google a rendu DMARC obligatoire pour les expéditeurs de plus de 5 000 emails/jour depuis février 2024 — et a étendu la contrainte progressivement aux volumes plus faibles. Yahoo a suivi immédiatement. En pratique, si votre PME n'a pas de DMARC à p=quarantine minimum, vous êtes exposé au spoofing de votre propre domaine : un concurrent, un escroc ou un ransomware peut envoyer des emails se réclamant de votre_domaine.com, et certains destinataires les recevront en inbox.

La bonne nouvelle : une fois correctement configurés, ces trois records ne demandent aucune maintenance. Les quelques heures de mise en place initiale sont un investissement à ROI immédiat en sécurité et en délivrabilité.

Remplacez yourdomain.com par votre domaine réel. Ces valeurs sont standard pour Microsoft 365 ; les seules valeurs personnalisées à votre tenant sont les deux CNAME DKIM (récupérables dans le Centre d'admin M365 → Paramètres → Domaines → votre domaine → Records DNS).

1. MX — Réception email
   Type : MX | Hôte : @ | Valeur : yourdomain-com.mail.protection.outlook.com | Priorité : 0 | TTL : 3600
   La valeur exacte est fournie par le Centre d'admin M365 pour votre domaine.
2. SPF — Authentification des expéditeurs
   Type : TXT | Hôte : @ | Valeur : v=spf1 include:spf.protection.outlook.com -all | TTL : 3600
   Si vous utilisez des expéditeurs tiers (ex: Mailchimp, Brevo, votre ERP), ajoutez leurs includes AVANT -all. Ne créez qu'un seul enregistrement SPF par domaine — plusieurs TXT SPF se neutralisent.
3. DKIM sélecteur 1 — Signature sortante
   Type : CNAME | Hôte : selector1._domainkey | Valeur : selector1-yourdomain-com._domainkey.VOTRE_TENANT.onmicrosoft.com | TTL : 3600
4. DKIM sélecteur 2 — Signature sortante (rotation)
   Type : CNAME | Hôte : selector2._domainkey | Valeur : selector2-yourdomain-com._domainkey.VOTRE_TENANT.onmicrosoft.com | TTL : 3600
5. DMARC — Politique et reporting
   Type : TXT | Hôte : _dmarc | Valeur : v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1; adkim=r; aspf=r | TTL : 3600
   Démarrer à p=none (monitoring seul) — voir section "Stratégie DMARC progressive" plus bas.
6. Autodiscover — Configuration automatique Outlook
   Type : CNAME | Hôte : autodiscover | Valeur : autodiscover.outlook.com | TTL : 3600
7. SRV Teams/Skype (optionnel mais recommandé)
   Type : SRV | Service : _sip | Protocole : _tls | Hôte : @ | Valeur : sipdir.online.lync.com | Port : 443 | Priorité : 100 | Poids : 1 | TTL : 3600

Ordre de publication recommandé : SPF en premier, puis DKIM (attendez la propagation — 15 à 60 min), puis activez DKIM dans le Centre d'admin M365 (bouton "Activer" par sélecteur), puis DMARC, et enfin MX si vous migrez depuis un hébergeur précédent. Publier MX avant SPF/DKIM garantit que vos premiers emails sortants seront marqués comme suspects.

Les interfaces DNS varient suffisamment entre registrars pour que les noms de champs prêtent à confusion. Voici les notes spécifiques pour chacun.

Cloudflare

Connectez-vous sur dash.cloudflare.com, sélectionnez votre zone → DNS → Add record. Pour le MX : type MX, name @, mail server = valeur fournie par M365, priority 0. Pour SPF et DMARC : type TXT, name @ pour SPF, name _dmarc pour DMARC. Important : pour les CNAME DKIM, désactivez le proxy Cloudflare (mettre sur DNS only / nuage gris) — les CNAME DKIM proxifiés cassent la vérification de signature. Pour le MX, le proxy est sans objet (MX ne se proxifie pas). Cloudflare propage généralement en moins de 5 minutes.

OVH

Espace client OVH → Web Cloud → Noms de domaine → votre domaine → Zone DNS → Ajouter une entrée. Pour SPF : choisissez "TXT", cible = la valeur SPF complète, sous-domaine vide (pour @). Pour DKIM : choisissez "CNAME", sous-domaine = selector1._domainkey (sans le domaine en suffixe — OVH l'ajoute automatiquement). Pour DMARC : TXT, sous-domaine = _dmarc. TTL recommandé : 3600 s. La propagation OVH peut prendre 2 à 4 heures en Europe.

IONOS

Espace client IONOS → Domaines → votre domaine → DNS → Ajouter un enregistrement. Pour SPF et DMARC : sélectionnez "TXT", hostname = @ pour SPF et _dmarc pour DMARC. Pour les CNAME DKIM : sélectionnez "CNAME", hostname = selector1._domainkey.yourdomain.com (IONOS n'ajoute pas le domaine automatiquement — saisissez le FQDN complet avec le point final optionnel). Vérifiez dans l'aperçu que le record affiché n'a pas de duplication du domaine.

Gandi

Connectez-vous sur admin.gandi.net → Nom de domaine → votre domaine → Enregistrements DNS → Ajouter. Gandi utilise l'éditeur de zone classique ou le nouvel éditeur LiveDNS. En LiveDNS : type TXT, name @ pour SPF (laissez name vide pour root), name _dmarc pour DMARC, name selector1._domainkey pour DKIM. Si vous éditez en mode zone classique (texte BIND), copiez directement les lignes dans le format @ IN TXT "v=spf1 ...". TTL par défaut : 10800 — changez en 3600 pour réduire le délai de propagation lors des ajustements.

GoDaddy

My Products → DNS → Manage DNS pour votre domaine. Ajoutez TXT, CNAME et MX via le bouton Add. Pour TXT SPF : Host = @, TXT Value = la valeur SPF. Pour DMARC : Host = _dmarc. Pour CNAME DKIM : Host = selector1._domainkey (GoDaddy ajoute le domaine en suffixe automatiquement). La propagation GoDaddy peut prendre 30 minutes à 1 heure. Attention : GoDaddy a tendance à créer des enregistrements MX par défaut (parking) — supprimez-les avant d'ajouter ceux de Microsoft.

Namecheap

Dashboard → Domain List → Manage → Advanced DNS. Ajoutez TXT Record (Host @ pour SPF, _dmarc pour DMARC), et CNAME Record (Host selector1._domainkey pour DKIM — Namecheap ajoute le domaine automatiquement). Le MX se configure dans l'onglet "Mail Settings" si vous utilisez un hosting Namecheap, ou directement en DNS Record sinon. Propagation : généralement sous 30 min.

Avant de déclarer la configuration terminée, vérifiez chaque record avec ces trois outils gratuits. N'attendez pas un problème de délivrabilité pour les utiliser.

MXToolbox (mxtoolbox.com)

L'outil de référence pour les DNS email. Utilisez les vérifications spécifiques :

• MX Lookup : confirme que votre MX pointe bien vers *.mail.protection.outlook.com
• SPF Record Lookup : valide la syntaxe SPF et compte le nombre de lookups DNS (maximum 10 autorisés par le standard)
• DKIM Lookup : entrez votre domaine + sélecteur (selector1 ou selector2) — vérifie que le CNAME est résolvable et que la clé publique est lisible
• DMARC Lookup : vérifie la syntaxe DMARC et affiche la politique courante

Lisez les résultats : tout indicateur en rouge est bloquant. En jaune (warning), évaluez selon votre contexte. MXToolbox explique chaque erreur avec un lien vers la RFC correspondante.

Dmarcian (dmarcian.com)

Outil spécialisé DMARC. Sa fonctionnalité la plus utile : le DMARC Inspector qui décompose votre record DMARC balise par balise et détecte les erreurs de syntaxe subtiles (ex: virgule vs point-virgule). Dmarcian propose aussi une version gratuite du tableau de bord DMARC qui agrège les rapports XML reçus sur rua@ — indispensable en phase de monitoring (p=none) pour identifier quels services envoient depuis votre domaine.

Mail-tester (mail-tester.com)

Approche différente : envoyez un vrai email depuis votre boîte M365 à l'adresse temporaire générée par le site. Mail-tester analyse le message reçu et donne un score /10 avec le détail de chaque check : SPF, DKIM, DMARC, réputation IP, score anti-spam (Spamassassin), présence dans listes noires. C'est le seul outil qui teste le flux bout-en-bout — un SPF qui passe en lookup mais échoue sur un email réel révèle parfois une incompatibilité de configuration. Visez 9/10 minimum avant de considérer la config terminée.

Lecture des résultats courants

• SPF: permerror → plusieurs enregistrements TXT SPF publiés — n'en gardez qu'un
• DKIM: no key for selector → le CNAME n'est pas encore propagé, ou vous n'avez pas activé DKIM dans le Centre d'admin M365
• DMARC: p=none → normal en phase initiale, passez à quarantine après 4 semaines de monitoring propre
• Score mail-tester < 7/10 → cherchez si votre IP est en liste noire (section "Blacklists") ou si un include SPF génère un PermError pour dépassement du seuil de 10 lookups

Passer directement à p=reject est une erreur courante qui peut bloquer des emails légitimes si un service tiers (newsletter, CRM, ERP) envoie depuis votre domaine sans être correctement authentifié. La bonne approche est le durcissement progressif en trois phases.

Phase 1 — Semaines 1 à 4 : Monitoring (p=none)

Record initial :

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1; pct=100

À p=none, aucun email n'est rejeté ni mis en quarantaine, mais vous recevez les rapports XML quotidiens sur toutes les sources d'envoi depuis votre domaine. Analysez ces rapports (via Dmarcian ou en parsant le XML) pour identifier :

• Vos propres serveurs M365 (doivent être en SPF/DKIM pass)
• Les services tiers légitimes (newsletter, ERP) — ajoutez-les au SPF ou configurez DKIM pour eux
• Les sources inconnues qui tentent d'usurper votre domaine — c'est exactement pour ça que DMARC existe

Phase 2 — Semaines 5 à 10 : Quarantaine (p=quarantine)

Après avoir corrigé tous les services légitimes identifiés en Phase 1 :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=25

Commencez avec pct=25 (seulement 25 % des emails qui échouent sont mis en quarantaine). Surveillez pendant 2 semaines. Si aucun faux positif, passez à pct=100. Les emails qui échouent DMARC arrivent en dossier spam du destinataire plutôt qu'en inbox.

Phase 3 — Semaine 10+ : Rejet (p=reject)

Une fois p=quarantine; pct=100 stable pendant 2 semaines sans incident :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100

À p=reject, tout email qui échoue DMARC est refusé par le serveur destinataire, sans atterrir nulle part. C'est la protection maximale contre le spoofing de votre domaine. Continuez à recevoir et analyser les rapports rua mensuellement pour détecter tout nouveau service d'envoi non autorisé.

Si votre domaine envoie beaucoup de newsletters via Mailchimp, Brevo ou SendGrid, configurez DKIM via l'interface de ces plateformes (elles fournissent leurs propres CNAME) avant de passer à p=reject — sinon toutes vos newsletters seront rejetées.

Voici les problèmes que nous rencontrons le plus souvent lors d'audits DNS pour nos clients Microsoft 365.

1. SPF "PermError: too many DNS lookups"
   Symptôme : MXToolbox affiche une erreur de dépassement des 10 lookups. Cause : chaque include: dans votre SPF génère un lookup récursif. Si vous avez M365 + Mailchimp + Brevo + votre ERP, vous dépassez facilement 10. Diagnostic : utilisez MXToolbox SPF pour voir le compte exact. Solution : "aplatir" le SPF en remplaçant les includes récursifs par les IPs directes via un service comme AutoSPF ou SPFFlattener.
2. DKIM "selector not found" ou "CNAME resolution failure"
   Symptôme : MXToolbox DKIM retourne "no record found". Causes possibles : (a) vous avez publié le CNAME mais n'avez pas cliqué "Enable DKIM" dans le Centre d'admin M365 — la clé n'est pas générée ; (b) votre registrar a ajouté le domaine en doublon (ex: selector1._domainkey.yourdomain.com.yourdomain.com) ; (c) la propagation DNS n'est pas terminée. Vérifiez avec dig CNAME selector1._domainkey.yourdomain.com +short depuis un terminal.
3. DMARC "alignment failure" malgré SPF et DKIM verts
   Symptôme : les rapports DMARC montrent des échecs même si SPF et DKIM passent individuellement. Cause : DMARC exige l'alignement — le domaine dans le From: de l'email doit correspondre au domaine SPF ou DKIM. Si votre ERP envoie depuis noreply@notifications.yourdomain.com mais que votre SPF couvre uniquement yourdomain.com, l'alignement strict (aspf=s) échoue. Solution : utilisez l'alignement relaxé (aspf=r; adkim=r) ou étendez le SPF au sous-domaine.
4. MX qui continue de pointer vers l'ancien hébergeur
   Symptôme : les emails entrants arrivent encore sur l'ancienne boîte plusieurs heures après la bascule. Cause : le TTL de l'ancien MX était élevé (ex: 86400 = 24h), et les serveurs en amont ont mis en cache l'ancienne valeur. Diagnostic : dig MX yourdomain.com @8.8.8.8 pour voir ce que Google résout. Prévention : baissez le TTL du MX à 300 s 48 heures avant la bascule.
5. Score mail-tester qui chute à cause de la réputation IP
   Symptôme : SPF/DKIM/DMARC sont tous verts mais le score est 6/10 à cause d'une IP en liste noire. Cause : Microsoft 365 partage ses IPs sortantes entre millions de tenants ; une IP peut être temporairement en liste noire à cause d'un autre client M365 qui a spammé. Solution à court terme : envoyez depuis une IP M365 dédiée (disponible sur les plans Enterprise) ou utilisez un service de warm-up. Solution immédiate : contactez-nous via contact@africwebhosting.com — on peut vérifier votre tenant spécifique et escalader vers le support Microsoft si nécessaire.