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

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

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

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

La règle d'or ne souffre pas d'exception : un seul enregistrement v=spf1 par domaine. Publier un enregistrement pour Microsoft et un autre pour Google crée 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. Les deux réunis, le compteur affiche déjà six ou sept résolutions avant le moindre prestataire tiers.

Or la limite est de dix. Il ne reste donc que trois ou quatre résolutions pour le routeur marketing, la facturation, l'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 les autres prestataires

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

1. Séparer par sous-domaine. Garder Microsoft 365 ou Google Workspace sur le domaine racine (la messagerie humaine), et faire partir le marketing depuis news.exemple.fr et le transactionnel depuis notif.exemple.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égier l'alignement DKIM pour les tiers. Un routeur qui signe en DKIM aligné (d=exemple.fr) satisfait DMARC sans consommer de résolution SPF. C'est souvent la meilleure façon d'intégrer un prestataire sans alourdir l'enregistrement.
3. Figer en ip4: les prestataires à IP stables, en dernier recours, en surveillant qu'ils ne changent pas.

Empiler les include sur le domaine racine « parce que c'est plus simple » est à éviter à tout prix : 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 le SPF. Pendant la transition, le courrier part des deux plateformes : l'enregistrement doit donc porter les deux include simultanément.

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

Deux pièges guettent. D'abord, 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, il faut penser à 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 : noter 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 découvrir un PermError un beau matin.

Les pièges spécifiques

Quelques erreurs reviennent avec ces deux plateformes :

• Recopier des IP Google ou Microsoft à la main. Le lien auto-maintenu est rompu, et des échecs surviennent dès que les plages changent. Les include officiels restent la seule voie sûre.
• Oublier les sous-domaines d'envoi. Un envoi depuis mail.exemple.fr exige un SPF propre à ce sous-domaine — le SPF de la racine ne s'applique pas automatiquement aux sous-domaines.
• Confondre SPF et DKIM/DMARC. Configurer l'include ne suffit pas : reste à activer la signature DKIM côté Microsoft ou Google (via leur console), et à publier l'enregistrement DMARC.
• Mélanger des tenants. Avec plusieurs tenants Microsoft ou plusieurs domaines Google, chacun a sa configuration ; mélanger leurs include sans vérifier ce qui est réellement autorisé mène droit à l'accident.

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 qu'un 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 le From: — qui fait la protection, pas le SPF seul. Les deux plateformes proposent leur DKIM en quelques clics ; s'arrêter au SPF serait une erreur. Une fois les trois briques en place, la cible est p=reject côté DMARC, pour que l'usurpation du domaine soit réellement refusée et pas seulement observée.

La propagation DNS, à ne pas oublier

Un détail d'exploitation qu'on oublie souvent : une modification SPF n'est pas instantanée. Les résolveurs du monde entier gardent l'enregistrement TXT en cache jusqu'à l'expiration de son TTL — le changement peut donc mettre de quelques minutes à plusieurs heures à être vu partout, et pendant cette fenêtre, certains destinataires évaluent encore l'ancienne version. Avant un changement planifié (ajout d'un include, bascule de migration), il faut abaisser le TTL de l'enregistrement quelque temps à l'avance : la propagation sera d'autant plus rapide, et un éventuel retour en arrière aussi. Une fois la situation stabilisée, le TTL remonte à une valeur normale. Et un changement qui « ne marche pas » à la première minute ne prouve rien : mieux vaut interroger plusieurs résolveurs avant de retoucher l'enregistrement, sous peine d'empiler des corrections sur un simple délai de cache.

Vérifier la configuration

Une fois l'enregistrement en place, le contrôle est simple : 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 en montrer le coût réel. La démarche complète est dans comment vérifier un enregistrement SPF. Et l'essentiel ne se perd pas de vue : 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 ? -all s'impose une fois toutes les 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 le From:. Pour la messagerie humaine, l'alignement est généralement bon ; pour les tiers qui envoient « au nom du domaine » via ces plateformes, l'alignement se vérifie dans les 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. La sortie : isoler le routeur sur un sous-domaine, ou le basculer 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. Le décompte reste à surveiller, 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é. Les deux vont ensemble — voir comment les trois protocoles fonctionnent ensemble.

Thomas compose l'enregistrement

Combiner Microsoft, Google et les tiers sous la barre des dix résolutions est un puzzle. Thomas, le RSSI virtuel, lit les sources réelles, compose l'enregistrement SPF optimal (racine et sous-domaines), indique 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.

Analyser un domaine gratuitement ou créer un compte pour une configuration SPF qui tient la route.