Comment créer un enregistrement SPF pour Office 365 sans perturber mes autres services de messagerie ?

Pour créer un enregistrement SPF pour Office 365 sans perturber vos autres services de messagerie, recensez tous les expéditeurs légitimes, construisez un unique enregistrement v=spf1 qui inclut include:spf.protection.outlook.com ainsi que vos autres fournisseurs et adresses IP tout en restant sous la limite de 10 requêtes DNS (à l’aide de sous-domaines ou de l’aplatissement si nécessaire), déployez avec un qualificateur souple (~all), testez et surveillez via les données SPF/DMARC, et automatisez la maintenance avec AutoSPF pour éviter toute dérive.

Conformément à la RFC 7208, l’évaluation SPF est plafonnée à 10 requêtes de mécanismes DNS et 2 requêtes nulles par vérification - dépasser l’une ou l’autre de ces limites produit une erreur PermError qui fait échouer l’authentification de chaque message provenant du domaine.

Contexte et informations générales

Le Sender Policy Framework (SPF) est une liste d’autorisation basée sur le DNS qui indique aux destinataires quelles adresses IP et quels services sont habilités à envoyer du courrier pour votre domaine. Microsoft 365 (Exchange Online) exige que vous incluiez son infrastructure SPF publiée avec include:spf.protection.outlook.com, mais de nombreux domaines envoient également depuis un Exchange sur site, des plateformes marketing, des CRM, des systèmes de ticketing et des applications web. Si vous publiez un SPF qui ne couvre qu’Office 365, d’autres services légitimes peuvent être rejetés ; et si vous tentez de tout inclure de manière naïve, vous risquez de dépasser la stricte limite de 10 requêtes du SPF et de rompre entièrement l’évaluation.

La voie la plus sûre est méthodique : découvrez chaque source d’envoi, construisez un enregistrement exact couvrant Office 365 et toutes les autres sources, optimisez-le pour rester dans le budget de requêtes, préparez soigneusement le déploiement et assurez-en la maintenance. Si vous partez de zéro, notre guide sur la façon de configurer un enregistrement SPF couvre les fondamentaux. AutoSPF simplifie chacune de ces étapes en découvrant les expéditeurs à partir des données de messagerie réelles, en modélisant le nombre de requêtes en temps réel, en aplatissant automatiquement lorsque c’est nécessaire, et en surveillant les résultats pour que vous puissiez passer en toute confiance à une politique stricte.

Recensez chaque service qui envoie du courrier pour votre domaine

Un inventaire complet des expéditeurs évite les « ruptures » lorsque vous migrez vers Office 365 ou l’optimisez.

Ce qu’il faut lister et comment le documenter

• Sur site : la ou les adresses IP NAT publiques pour Exchange ou les relais SMTP, les smart hosts, les scanners et les multifonctions (MFP)

• Microsoft 365 : Exchange Online Protection (EOP) via include:spf.protection.outlook.com

• Plateformes tierces : ESP (par ex. SendGrid, Mailchimp), CRM (par ex. Salesforce), ticketing (par ex. Zendesk), support/chat, RH/paie, et toute application qui envoie sous votre domaine

• Infrastructure web : CMS/formulaires de contact, plateformes e-commerce, fonctions serverless

• Chemins particuliers : listes de diffusion, redirecteurs (forwarders) et expéditeurs de sous-domaines (par ex. bounce@, newsletter@, noreply@)

Méthodes pour découvrir toutes les sources

• Rapports agrégés DMARC (RUA) : énumérez les adresses IP et domaines sources observés comme envoyant en votre nom ; collectez au moins 14 à 30 jours de données

• Suivi des messages (Message Trace) et en-têtes Microsoft 365 : examinez Authentication-Results et Received-SPF pour repérer les IP/services

• Tableaux de bord des fournisseurs : la plupart des ESP affichent le ou les domaines qu’ils sont configurés pour utiliser en tant qu’expéditeur ainsi que leur include SPF

• Vérifications DNS et infrastructure : dig/nslookup de vos enregistrements MX et A (si vous vous appuyez sur a: ou mx: dans le SPF), les tables NAT du pare-feu pour le trafic sortant SMTP/25 et 587

• Entretiens avec les équipes : le marketing, le support, le produit et l’IT gèrent souvent des systèmes d’envoi différents

Lien avec AutoSPF : AutoSPF ingère automatiquement les rapports DMARC RUA, associe les adresses IP sources aux fournisseurs connus et construit un inventaire vivant. Il signale les « expéditeurs inconnus » et suggère des ajouts SPF ou une segmentation par sous-domaine, vous faisant économiser des semaines de découverte manuelle.

Construisez un unique SPF incluant Office 365 et tout le reste (sans dépasser 10 requêtes)

Le cœur du dispositif est un unique enregistrement TXT à la racine (example.com) contenant exactement une politique SPF. Le mécanisme publié par Microsoft est include:spf.protection.outlook.com. Vous pouvez assembler cet enregistrement avec notre générateur d’enregistrement SPF.

La syntaxe recommandée par Microsoft pour Exchange Online

• Office 365 uniquement :
• v=spf1 include:spf.protection.outlook.com -all

C’est la recommandation canonique de Microsoft pour Exchange Online lorsqu’il n’existe aucun autre expéditeur.

Exemples concrets d’enregistrements SPF

• Office 365 + adresses IP publiques sur site :

• v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

• Office 365 + sur site + plusieurs expéditeurs tiers :

• v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

• Office 365 + Amazon SES (régionalisé) + Mailchimp :

• v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all

• Sous-domaine délégué pour le marketing tout en gardant une racine légère :

• Racine (example.com) : v=spf1 include:spf.protection.outlook.com -all

• Marketing (news.example.com) : v=spf1 include:sendgrid.net include:servers.mcsv.net -all

Remarque : confirmez toujours l’hôte include actuel de chaque fournisseur dans sa documentation. Certains fournisseurs proposent des includes propres à une région ou à un compte qui réduisent le nombre de requêtes.

Le budget de 10 requêtes et comment rester en dessous

Le SPF comptabilise les mécanismes qui interrogent le DNS dans une limite stricte de 10 sur l’ensemble de la chaîne d’évaluation (include, redirect, a, mx, ptr, exists et macros). ip4, ip6 et all ne déclenchent aucune requête.

• Coûts courants en requêtes :

• include : 1 requête chacun (plus ce qu’ils incluent eux-mêmes)

• mx : jusqu’au nombre d’hôtes MX (plus les requêtes A/AAAA)

• a : 1 (plus une éventuelle chaîne de CNAME)

• redirect= : 1 (remplace la politique ; reste dans le même budget de 10)

• Gardez « all » en dernier ; il n’ajoute aucune requête.

Stratégies pratiques :

• Privilégiez ip4/ip6 pour vos propres hôtes statiques plutôt que mx ou a

• Réduisez au minimum les includes de fournisseurs ; supprimez les prestataires hérités

• Segmentez les expéditeurs coûteux en requêtes vers des sous-domaines (par ex. news.example.com) afin que le SPF racine reste léger

• Utilisez un aplatissement géré pour convertir les includes en ensembles d’IP actuels, avec rafraîchissement automatique

Lien avec AutoSPF : AutoSPF affiche un compteur de requêtes en temps réel pendant que vous éditez, vous avertit lorsque des includes indirects font dépasser le seuil de 10, et peut publier un enregistrement aplati en toute sécurité avec rafraîchissement automatique, pour que vous ne dériviez jamais quand les fournisseurs changent d’adresses IP.

Gérez les déploiements Exchange hybrides sans dommages collatéraux

Le mode hybride modifie l’adresse IP qui envoie réellement vers Internet ; modélisez donc votre flux de messagerie avant de publier votre SPF.

Si le serveur sur site relaie vers EOP (et qu’EOP assure la remise)

• Chemin sortant : sur site → EOP → destinataires sur Internet

• IP de connexion côté destinataire : EOP

• Recommandation SPF : include:spf.protection.outlook.com suffit ; vous n’avez pas besoin de vos IP sur site dans le SPF

• Pourquoi : le SPF vérifie l’adresse IP du client SMTP du dernier saut vers le destinataire, qui est EOP dans cette configuration

Si le serveur sur site remet directement vers Internet (ou si des applications le font)

• Chemin sortant : sur site/application → Internet

• IP de connexion : vos NAT publics

• Recommandation SPF : ajoutez ip4/ip6 pour chaque IP sortante susceptible d’envoyer sous votre domaine, en plus de include:spf.protection.outlook.com

Smart hosts et connecteurs

• Smart host tiers (par ex. passerelles de sécurité) qui assurent la remise pour vous : incluez le SPF de ce fournisseur ou ajoutez ses adresses IP sortantes

• Plusieurs points de sortie : envisagez de consolider vers un nombre réduit de NAT ou publiez toutes les IP en ip4/ip6

Le trafic entrant ne modifie pas le SPF

Le routage entrant (MX vers EOP ou vers le serveur sur site) n’affecte pas le SPF de votre domaine, mais si vous utilisez mx dans le SPF, cela ajoute des requêtes ; privilégiez des ip4/ip6 explicites pour les expéditeurs.

Lien avec AutoSPF : la « modélisation de flux » d’AutoSPF vous permet de déclarer si votre serveur sur site transite par EOP ou envoie directement ; il génère ensuite le SPF correct et met en évidence toute adresse IP non couverte détectée dans les données DMARC.

Déployez en toute sécurité : qualificateurs, tests, surveillance, retour arrière et pièges courants

Choisissez le bon qualificateur SPF pendant le déploiement

• ~all (SoftFail) : recommandé pour le déploiement initial ; les destinataires acceptent le courrier mais marquent le SPF en softfail en l’absence de correspondance

• -all (Fail) : n’appliquez cette valeur qu’une fois certain que toutes les sources légitimes sont couvertes

• ?all (Neutral) : utile pour la découverte initiale si vous n’avez pas encore de DMARC, mais n’offre que peu d’application

• est une autorisation implicite ; omettez-le par souci de concision (par ex. ip4: au lieu de +ip4:)

Plan de déploiement sécurisé :

1. Réduisez la TTL DNS de l’enregistrement TXT à 300-600 secondes, 24 heures avant les modifications
2. Publiez un enregistrement complet avec ~all
3. Activez DMARC p=none et collectez les rapports pendant 2 à 4 semaines ; confirmez un taux de réussite ≥ 98-99 % pour le trafic légitime
4. Passez DMARC en quarantine (pct=25→100 progressivement)
5. Changez le SPF en -all lorsque DMARC affiche une couverture quasi parfaite et que les configurations tierces sont stables
6. Remontez la TTL à 1-4 heures une fois la situation stabilisée

Comment vérifier et surveiller ?

• DNS : dig/nslookup -type=TXT example.com pour vérifier qu’il n’existe qu’un seul enregistrement SPF

• Messages réels : examinez les en-têtes Authentication-Results et Received-SPF ; recherchez spf=pass du côté des destinataires

• Outils Microsoft : suivi des messages (Message Trace) dans le centre d’administration Exchange ; journaux des connecteurs sortants

• Validateurs en ligne : évaluez le nombre de requêtes et l’expansion

• DMARC RUA : surveillez les tendances de réussite/échec par source ; identifiez les IP inconnues

Lien avec AutoSPF : AutoSPF propose un simulateur « what-if » pour tester les enregistrements avant publication, des analyses DMARC continues avec attribution des sources, et des alertes en cas de pic d’échecs SPF après une modification ; un retour arrière en un clic restaure l’enregistrement précédent.

Quelles sont les erreurs de configuration courantes et comment les corriger ?

• Plusieurs enregistrements SPF TXT sur le même nom d’hôte

• Symptôme : « PermError: multiple SPF records »

• Correction : regroupez les enregistrements SPF en fusionnant tous les mécanismes en un seul enregistrement v=spf1 ; supprimez les doublons

• Dépassement des 10 requêtes

• Symptôme : « PermError: too many DNS lookups »

• Correction : supprimez les prestataires inutilisés, remplacez mx/a par ip4/ip6, segmentez vers des sous-domaines, ou aplatissez avec AutoSPF

• Syntaxe include/ip4/ip6 incorrecte

• Symptôme : « PermError: invalid SPF record » ou incohérence silencieuse

• Correction : validez la syntaxe ; assurez-vous que le CIDR est correct (par ex. ip4:198.51.100.44/32 ou ip4:198.51.100.0/24)

• Placer all avant les autres mécanismes

• Symptôme : les mécanismes suivants sont ignorés

• Correction : all doit être en dernier

• Utiliser ptr ou des mx/a trop larges par inadvertance

• Symptôme : requêtes excessives, faux succès

• Correction : supprimez ptr ; remplacez mx/a par des ip4/ip6 explicites

• Redirecteurs absents de la stratégie

• Symptôme : le courrier redirigé échoue au SPF chez les destinataires

• Correction : appuyez-vous sur DKIM pour l’alignement et la réussite DMARC ; encouragez le SRS au niveau des redirecteurs

Lien avec AutoSPF : le linting d’AutoSPF signale ces problèmes en temps réel et recommande la correction précise, y compris un enregistrement fusionné sûr en cas de doublons.

Maîtrisez la complexité liée aux tiers et alignez-vous sur DKIM/DMARC ainsi que sur les cas particuliers

Stratégies face à de nombreux expéditeurs tiers

• Consolidation des fournisseurs : moins de prestataires, moins d’includes, moins de requêtes

• Délégation par sous-domaine : envoyez le marketing depuis news.example.com et le produit depuis updates.example.com ; gardez un SPF racine minimal

• Redirect pour la maintenabilité : v=spf1 redirect=_spf.example.com centralise la politique (compte toujours dans les 10)

• Aplatissement (géré) : convertissez les includes en IP ; automatisez le rafraîchissement pour suivre les changements d’IP des fournisseurs

Compromis :

• L’aplatissement réduit les requêtes à presque zéro mais peut augmenter la taille de l’enregistrement et doit être rafraîchi à mesure que les fournisseurs évoluent ; l’aplatissement géré (AutoSPF) atténue cela grâce à des mises à jour automatiques et au découpage sur plusieurs chaînes TXT

• Les sous-domaines nécessitent de reconfigurer les fournisseurs et le DNS, mais isolent les budgets de requêtes et réduisent les impacts croisés

SPF, DKIM et DMARC ensemble (avec Microsoft 365)

• Le SPF authentifie le MAIL FROM d’enveloppe ; DKIM authentifie le contenu du message ; DMARC aligne l’un ou l’autre sur le domaine From visible

• DKIM pour Office 365 : activez la signature DKIM dans Microsoft 365 ; publiez les CNAME pour selector1/selector2

• Base DMARC : v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100

• Recommandation d’alignement : utilisez d’abord l’alignement relâché (aspf=r, adkim=r) ; passez au strict pour les domaines sensibles si c’est faisable

• Redirection et listes de diffusion : le SPF échoue fréquemment après une redirection ; DKIM survit si le message n’est pas modifié ; DMARC réussit si DKIM est aligné

• ARC : envisagez d’activer ARC sur les intermédiaires que vous exploitez ; il aide à préserver les résultats d’authentification d’origine en aval

Cas particuliers : sous-domaines, hébergement mutualisé, listes et redirection

• Sous-domaines : publiez un SPF pour chaque sous-domaine qui envoie ; si un sous-domaine n’envoie pas, vous pouvez omettre le SPF ou publier v=spf1 -all pour signaler l’absence d’envoi

• Hébergement mutualisé/applications web : privilégiez un relais SMTP via EOP ou un ESP dédié pour éviter d’exposer la volatilité des IP du serveur web ; sinon, publiez ip4/ip6

• Listes de diffusion : configurez les listes pour minimiser les réécritures du sujet/du corps ; lorsque c’est possible, activez la réécriture du From: pour éviter les échecs DMARC chez les destinataires qui appliquent p=reject

• Redirecteurs : encouragez le SRS ; appuyez-vous sur DKIM pour la réussite DMARC ; maintenez le rua DMARC pour observer les ruptures

Lien avec AutoSPF : AutoSPF gère plusieurs politiques de sous-domaines, valide la présence de DKIM/DMARC et corrèle les résultats d’alignement DMARC afin que vous puissiez voir si c’est le SPF ou le DKIM qui porte le DMARC, en particulier pour le courrier redirigé.

Données originales, enseignements et exemples de résultats

• Dans une analyse de 30 jours portant sur 112 domaines de PME migrant vers Microsoft 365 (jeu de données interne AutoSPF), 71 % comptaient plus de cinq sources d’envoi distinctes ; 38 % dépassaient la limite SPF de 10 requêtes dès la première version ; 19 % publiaient involontairement plusieurs enregistrements SPF TXT.

• Après application de la segmentation par sous-domaine et de l’aplatissement géré, le nombre moyen de requêtes par domaine racine est passé de 11,8 à 4,2, et les taux de réussite DMARC pour le courrier légitime sont passés de 96,4 % à 99,2 %.

• Étude de cas (hypothétique mais représentative) : AcmeCo utilisait Office 365, un relais SMTP sur site (203.0.113.10), SendGrid, Mailchimp et Salesforce. Leur SPF initial comptait 14 requêtes effectives et générait des PermErrors intermittentes chez les grands destinataires. L’inventaire d’AutoSPF a révélé que deux anciens ESP envoyaient encore des messages de rebond (bounces). En supprimant les includes hérités, en déplaçant le marketing vers news.example.com et en aplatissant automatiquement le SPF racine, AcmeCo a publié :

• example.com : v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all (IP EOP aplaties et déchargées par AutoSPF)

• news.example.com : v=spf1 include:sendgrid.net include:servers.mcsv.net -all Résultat : le nombre de requêtes est tombé à 5 ; les softfails ont diminué de 92 % ; le taux de remise réussie est passé de 97,1 % à 99,0 % en 21 jours.

FAQ

Dois-je utiliser -all ou ~all pour Office 365 ?

Utilisez ~all pendant la découverte et le déploiement initial pour éviter de rejeter des expéditeurs légitimes que vous auriez pu manquer ; passez à -all une fois que les données DMARC montrent une couverture quasi parfaite et aucune source inconnue. AutoSPF peut recommander le passage en fonction de seuils de taux de réussite.

Dois-je inclure mes IP sur site si je route le trafic sortant via EOP ?

Non. Si tout le courrier sortant suit le chemin sur site → EOP → Internet, include:spf.protection.outlook.com suffit. N’ajoutez vos ip4/ip6 sur site que si un système envoie directement vers Internet. Le modèle de flux d’AutoSPF vérifiera le comportement réel à partir des données DMARC.

Que faire si mes fournisseurs me font dépasser les 10 requêtes ?

Consolidez les fournisseurs lorsque c’est possible, déplacez les gros expéditeurs vers des sous-domaines, et utilisez l’aplatissement géré. L’aplatissement en tant que service d’AutoSPF maintient les IP à jour automatiquement et garantit que l’enregistrement reste dans les limites de taille et de requêtes.

Puis-je avoir plus d’un enregistrement SPF ?

Non. Vous pouvez avoir plusieurs chaînes TXT qui forment ensemble une seule valeur SPF si le serveur DNS scinde les longues chaînes, mais vous devez publier exactement une politique v=spf1 par nom d’hôte. AutoSPF fusionne les doublons et publie un unique enregistrement conforme.