SPF pour Microsoft 365 et Google Workspace : la configuration qui marche

Microsoft 365 et Google Workspace équipent la majorité des organisations, et leur configuration SPF est souvent la première qu'on met en place. Pourtant, c'est aussi là que beaucoup d'enregistrements partent du mauvais pied : un include mal copié, deux plateformes mélangées sans méthode, ou une limite de résolutions vite atteinte. Ce guide donne la configuration SPF correcte pour chacune, pour les deux ensemble, et surtout la stratégie pour y ajouter tes autres prestataires sans casser ton SPF.

L'include de Microsoft 365

Si ton organisation envoie via Microsoft 365 (Exchange Online), ton SPF doit inclure l'enregistrement de Microsoft :

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

C'est l'include officiel et maintenu par Microsoft. Tu n'as pas à lister des IP à la main : Microsoft tient l'enregistrement à jour derrière cet include, ce qui est exactement l'intérêt du mécanisme. Termine par -all si Microsoft 365 est ta seule source d'envoi.

L'include de Google Workspace

Pour Google Workspace (Gmail professionnel), l'include officiel est :

v=spf1 include:_spf.google.com -all

Comme pour Microsoft, Google maintient les plages d'IP derrière cet enregistrement. Attention à une erreur classique : on voit parfois des include historiques ou des plages d'IP Google recopiées à la main — préfère toujours l'include:_spf.google.com officiel, plus stable et auto-maintenu.

Les deux ensemble

Beaucoup d'organisations migrent, fusionnent ou exploitent les deux en parallèle. Dans ce cas, un seul enregistrement SPF combine les deux include :

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

Rappelle-toi la règle d'or : un seul enregistrement v=spf1 par domaine. Si tu publies un enregistrement pour Microsoft et un autre pour Google, tu crées un double enregistrement, source de PermError — et de nombreux destinataires ignoreront les deux. La bonne pratique est de tout combiner dans une seule ligne.

Le piège du décompte de résolutions

Voici ce qui surprend les équipes : ces deux include, à eux seuls, consomment beaucoup de résolutions DNS. include:_spf.google.com se déplie en plusieurs sous-include (_netblocks, _netblocks2, _netblocks3), soit environ quatre résolutions. include:spf.protection.outlook.com en consomme deux ou trois. Mets les deux ensemble, et tu es déjà à six ou sept résolutions avant d'avoir ajouté le moindre prestataire tiers.

Or la limite est de dix. Il ne te reste donc que trois ou quatre résolutions pour ton routeur marketing, ta facturation, ton outil de support… On comprend pourquoi tant d'enregistrements basculent en PermError : Microsoft et Google occupent déjà la moitié du budget.

La stratégie pour ajouter tes autres prestataires

Puisque le budget est serré, la méthode compte. Par ordre de préférence :

1. Sépare par sous-domaine. Garde Microsoft 365 ou Google Workspace sur ton domaine racine (la messagerie humaine), et fais partir le marketing depuis news.ton-domaine.fr et le transactionnel depuis notif.ton-domaine.fr, chacun avec son propre SPF. Chaque sous-domaine repart d'un budget de dix résolutions intact. C'est de loin la stratégie la plus durable.
2. Privilégie l'alignement DKIM pour les tiers. Un routeur qui signe en DKIM aligné (d=ton-domaine.fr) satisfait DMARC sans consommer de résolution SPF. C'est souvent la meilleure façon d'intégrer un prestataire sans alourdir ton SPF.
3. Fige en ip4: les prestataires à IP stables, en dernier recours, en surveillant qu'ils ne changent pas.

Évite à tout prix d'empiler les include sur le domaine racine « parce que c'est plus simple » : c'est le chemin direct vers le PermError.

Pendant une migration : les deux, temporairement

La bascule de Google Workspace vers Microsoft 365 (ou l'inverse) est un moment à risque pour ton SPF. Pendant la transition, tu envoies depuis les deux plateformes : ton enregistrement doit donc inclure les deux include simultanément.

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

Deux pièges guettent. D'abord, ne crée surtout pas deux enregistrements séparés « le temps de la migration » — c'est le double enregistrement assuré, et le PermError qui va avec. Ensuite, n'oublie pas de retirer l'include de l'ancienne plateforme une fois la migration terminée : un include orphelin consomme des résolutions pour rien, et si l'ancien service finit par fermer son enregistrement, il deviendra un void lookup. Une migration propre se termine donc par un nettoyage de l'enregistrement, pas seulement par le changement de messagerie. Le bon réflexe : note dès le départ la date prévue de retrait de l'ancien include, pour ne pas le laisser traîner des mois et te réveiller un jour en PermError.

Les pièges spécifiques

Quelques erreurs reviennent avec ces deux plateformes :

• Recopier des IP Google ou Microsoft à la main. Tu romps le lien auto-maintenu et tu t'exposes à des échecs quand les plages changent. Reste sur les include officiels.
• Oublier les sous-domaines d'envoi. Si tu envoies depuis mail.ton-domaine.fr, ce sous-domaine a besoin de son propre SPF — le SPF de la racine ne s'applique pas automatiquement aux sous-domaines.
• Confondre SPF et DKIM/DMARC. Configurer l'include ne suffit pas : pense à activer la signature DKIM côté Microsoft ou Google (via leur console), et à publier ton enregistrement DMARC.
• Mélanger des tenants. Si tu as plusieurs tenants Microsoft ou plusieurs domaines Google, chacun a sa configuration ; ne mélange pas leurs include sans vérifier ce que tu autorises réellement.

Un enregistrement complet, du réel

Prenons une entreprise typique : messagerie sur Microsoft 365, marketing via un routeur (Brevo), facturation via une appli métier, et un outil de support qui envoie des notifications. La tentation est d'écrire une seule ligne fourre-tout :

v=spf1 include:spf.protection.outlook.com include:spf.brevo.com
  include:_spf.facturation.com include:_spf.support.com -all

Déplions : Microsoft ≈ 3, Brevo ≈ 1-2, facturation ≈ 1, support ≈ 1, plus les éventuels sous-include. On est à six ou sept résolutions, peut-être plus. Ça « passe » aujourd'hui, mais sans marge, et le cinquième outil fera basculer en PermError.

La configuration durable répartit les flux par sous-domaine :

• Domaine racine (entreprise.fr) : v=spf1 include:spf.protection.outlook.com -all — uniquement la messagerie humaine.
• news.entreprise.fr : v=spf1 include:spf.brevo.com -all — le marketing, avec DKIM aligné sur le sous-domaine.
• notif.entreprise.fr : v=spf1 include:_spf.support.com -all — les notifications.
• La facturation, qui n'a qu'une IP fixe, passe en DKIM aligné sans toucher au SPF.

Chaque enregistrement reste minuscule, loin de la limite, et chaque flux peut grandir sans menacer les autres. C'est plus de travail au départ qu'une ligne fourre-tout, mais c'est exactement ce qui évite le PermError six mois plus tard, quand un cinquième outil arrive sans prévenir.

Et DMARC dans tout ça

Configurer l'include Microsoft ou Google fait passer SPF, mais ce n'est qu'une moitié du tableau. Pour que ton domaine soit réellement protégé, il faut aussi activer la signature DKIM (dans la console Microsoft 365 ou Google Workspace) et publier un enregistrement DMARC. C'est l'alignement — SPF ou DKIM aligné avec ton From: — qui fait la protection, pas le SPF seul. Les deux plateformes proposent leur DKIM en quelques clics ; ne t'arrête surtout pas au SPF. Une fois les trois briques en place, vise p=reject côté DMARC, pour que l'usurpation de ton domaine soit réellement refusée et pas seulement observée.

Vérifier ta configuration

Une fois ton enregistrement en place, contrôle-le : un seul v=spf1, syntaxe valide, décompte de résolutions sous dix, qualification -all. Notre analyseur gratuit fait tout ça en quelques secondes et déplie les include Microsoft et Google pour te montrer leur coût réel. La démarche complète est dans comment vérifier ton enregistrement. Et n'oublie pas l'essentiel : la qualification terminale doit viser -all (voir les mécanismes -all et ~all).

Questions fréquentes

Faut-il -all ou ~all avec Microsoft 365 / Google Workspace ? Vise -all une fois toutes tes sources listées. Microsoft et Google recommandent parfois ~all par prudence au démarrage, mais ce n'est pas une cible : un domaine maîtrisé se termine en -all.

L'include de Google/Microsoft suffit-il pour DMARC ? Non. Il fait passer SPF pour la messagerie de la plateforme, mais DMARC exige l'alignement avec ton From:. Pour la messagerie humaine, l'alignement est généralement bon ; pour les tiers qui envoient « en ton nom » via ces plateformes, vérifie l'alignement dans tes rapports.

Pourquoi mon SPF déborde alors que je n'ai que Microsoft et un routeur ? Parce que spf.protection.outlook.com plus un routeur qui se déplie peuvent déjà approcher dix résolutions. Sépare le routeur sur un sous-domaine, ou bascule-le en DKIM aligné.

Puis-je mettre Microsoft 365 et Google Workspace sur le même domaine ? Oui, en combinant leurs include dans un seul enregistrement. Surveille juste le décompte, car les deux ensemble consomment déjà une bonne moitié du budget.

Dois-je configurer SPF si j'utilise déjà DKIM ? Oui, les deux sont complémentaires. SPF et DKIM couvrent des cas différents, et DMARC s'appuie sur l'un ou l'autre aligné. Configure les deux — voir comment les trois protocoles fonctionnent ensemble.

Laisse Thomas composer ton enregistrement

Combiner Microsoft, Google et tes tiers sous la barre des dix résolutions est un puzzle. Thomas, ton RSSI virtuel, lit tes sources réelles, compose l'enregistrement SPF optimal (racine et sous-domaines), te dit quoi garder en include, quoi basculer en DKIM aligné, et quoi isoler sur un sous-domaine — pour un SPF propre, sous la limite, et aligné avec DMARC.

Analyse ton domaine gratuitement → ou crée un compte pour une configuration SPF qui tient la route.