Dernière mise à jour : juillet 2026

En bref : après ce guide, ton domaine publie un enregistrement SPF correct pour Microsoft 365 — y compris les cas particuliers de configuration hybride, de sous-domaine de newsletter et de domaines parqués.

Prérequis

  • Un locataire (tenant) Microsoft 365 avec ton propre domaine
  • L’accès à la gestion DNS de ton domaine — qui n’est pas chez Microsoft, mais chez ton fournisseur de domaine/DNS

Qu’est-ce que SPF ?

SPF (Sender Policy Framework) est un enregistrement TXT dans le DNS de ton domaine. Il liste les serveurs de messagerie autorisés à envoyer des e-mails avec ton domaine comme expéditeur. Les serveurs destinataires consultent l’enregistrement à chaque message entrant et vérifient si le serveur qui livre le message figure sur la liste. Sans SPF, n’importe quel serveur peut envoyer des e-mails en ton nom — et tes e-mails légitimes finissent plus vite dans les spams.

Pour situer les choses : SPF seul n’est pas une protection complète. Ce n’est qu’associé à DKIM et DMARC qu’il devient une base solide — et Microsoft recommande lui-même explicitement les trois.

Le point de départ chez Microsoft 365

Deux choses distinguent Microsoft 365 des hébergeurs classiques :

1. Il n’existe pas d’interface SPF dans Microsoft 365. La documentation de Microsoft le dit clairement : l’entrée TXT SPF se crée chez le registrar du domaine — aucune configuration SPF n’est disponible dans Microsoft 365 lui-même. Tu saisis donc l’enregistrement là où se trouve ta zone DNS. La manière de procéder dans chaque cas est montrée dans nos guides pour IONOS, Strato, All-Inkl et Netcup.

2. Microsoft recommande -all (hardfail). Alors que les hébergeurs allemands suggèrent presque universellement le ~all plus doux, Microsoft recommande explicitement -all pour les domaines 365 — au motif que DKIM et DMARC font de toute façon partie du tableau, et que DMARC avec ~all ne prend pas effet sans signature DKIM.

La seule exception : tu ne peux pas modifier l’entrée SPF de ton domaine *.onmicrosoft.com — celui-là est géré par Microsoft.

Guide étape par étape

1. Vérifier si SPF est déjà actif

Le plus rapide, via le terminal :

dig TXT example.com +short | grep spf1

Autre possibilité : entre ton domaine dans le scanner MXAudit gratuit — il vérifie en même temps la syntaxe de l’enregistrement et les limites de lookups. Beaucoup de domaines ont déjà un enregistrement SPF de l’hébergeur ; celui-ci doit alors être étendu pour Microsoft 365, pas remplacé.

2. Choisir le bon enregistrement

Seul Microsoft 365 envoie (le cas normal) :

v=spf1 include:spf.protection.outlook.com -all

La plupart des organisations Microsoft 365 ont besoin exactement de cette valeur include. Elle pointe vers une liste plate de plages IP Microsoft (IPv4 + IPv6) et ne coûte qu’un seul lookup DNS.

Configuration hybride avec un serveur Exchange/de messagerie local : ajoute l’IP publique de ton serveur, l’exemple de Microsoft :

v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

Envoi de newsletters/en masse via un service externe : Microsoft recommande pour cela un sous-domaine dédié (par ex. marketing.example.com), pour que la réputation de ton domaine principal reste intacte. L’enregistrement du sous-domaine (exemple de Microsoft avec le service fictif Adatum) :

v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all

Domaines parqués qui n’envoient jamais : interdis totalement l’envoi :

v=spf1 -all

3. Saisir l’enregistrement chez le fournisseur DNS

Crée la valeur choisie sous forme d’enregistrement TXT sur le domaine principal (hôte @) — chez ton registrar ou hébergeur DNS, pas dans le centre d’administration Microsoft 365. Si une entrée TXT avec v=spf1 existe déjà là, modifie-la et ajoute include:spf.protection.outlook.com — une seule entrée SPF est autorisée par domaine.

4. Penser aux sous-domaines

Selon Microsoft, chaque sous-domaine défini a besoin de sa propre entrée SPF — l’enregistrement du domaine principal ne s’applique pas automatiquement. Pour les sous-domaines non définis, DMARC prend le relais de la protection.

5. Attendre que la modification soit en ligne

Les modifications DNS prennent du temps : selon le TTL et la mise en cache, il peut s’écouler quelques heures avant que chaque serveur dans le monde voie le nouvel enregistrement.

Les composants en détail

ComposantSignification
v=spf1identifiant de version, toujours au début
include:spf.protection.outlook.comautorise l’infrastructure d’envoi Microsoft 365 (liste plate IPv4/IPv6, 1 lookup)
ip4: / ip6:autorise des serveurs individuels à toi (scénario hybride)
-allhardfail : les serveurs non listés sont rejetés — la recommandation de Microsoft pour les domaines 365

Cas particuliers pour les clouds gouvernementaux américains : GCC High et DoD utilisent v=spf1 include:spf.protection.office365.us -all à la place de l’include standard.

Vérifier le résultat

Vérifie ta configuration avec le scanner MXAudit gratuit — il montre immédiatement si ton enregistrement SPF est syntaxiquement correct et combien de lookups DNS il consomme (la limite est de 10).

Ou directement dans le terminal :

dig TXT example.com +short | grep spf1

La sortie doit contenir exactement un enregistrement avec v=spf1.

Erreurs fréquentes

Un second enregistrement SPF créé au lieu d’étendre l’existant. Placer l’enregistrement Microsoft à côté de l’enregistrement d’hébergeur existant produit un permerror — les serveurs destinataires ignorent alors totalement SPF. Toutes les valeurs include doivent tenir dans un seul enregistrement.

Sous-domaines oubliés. Chaque sous-domaine qui envoie (newsletter, système de ticketing) a besoin de sa propre entrée SPF. Le domaine principal ne les couvre pas.

~all par vieille habitude. Avec Microsoft 365, le softfail ne se justifie pas : Microsoft recommande -all, précisément parce que DKIM et DMARC s’ajoutent. Conserver ~all sacrifie de l’effet protecteur.

+all à la fin. Un +all autorise n’importe quel serveur à envoyer et rend tout l’enregistrement inutile — ne le copie pas.

Le transfert échoue. Si un destinataire fait suivre automatiquement ton e-mail, SPF échoue souvent chez le destinataire final — le serveur de transfert ne figure pas dans ton enregistrement. C’est une faiblesse de conception de SPF, pas une erreur de configuration ; DKIM et DMARC couvrent ce cas.

Pour aller plus loin