Exemples d'enregistrements SPF pour Google Workspace, Microsoft 365 et votre service d'envoi

La version courte

1. Un enregistrement, plusieurs expéditeurs. Si le courrier de vos équipes passe par un fournisseur et celui de vos applications par un service d'envoi, les deux doivent être autorisés dans le même enregistrement SPF.
2. Google Workspace seul. Google documente include:_spf.google.com pour Workspace.
3. Microsoft 365 seul. Microsoft documente include:spf.protection.outlook.com pour Exchange Online.
4. Google Workspace plus un service d'envoi. Ajoutez l'include du service d'envoi à côté de celui de Google.
5. Microsoft 365 plus un service d'envoi. Le même principe s'applique.
6. Ajouter votre propre serveur par adresse IP. Si vous exploitez un serveur qui envoie du courrier, comme une application web ou un ancien serveur de messagerie, indiquez son adresse avec ip4.

Un enregistrement, plusieurs expéditeurs

Si le courrier de vos équipes passe par un fournisseur et celui de vos applications par un service d'envoi, les deux doivent être autorisés dans le même enregistrement SPF. Chacun ajoute un include, et vous gardez un seul v=spf1 au début et un seul all à la fin.

Les exemples ci-dessous utilisent les valeurs include publiées par Google et Microsoft. Les fournisseurs les modifient parfois ; confirmez-les donc dans leur documentation actuelle avant de publier.

Google Workspace seul

Google documente include:_spf.google.com pour Workspace. Un domaine qui n'envoie que via Google publierait cet enregistrement.

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

C'est aussi le bon point de départ si vous utilisez Gmail avec votre propre domaine.

Microsoft 365 seul

Microsoft documente include:spf.protection.outlook.com pour Exchange Online. Un domaine qui n'envoie que via Microsoft 365 publierait ceci.

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

Si vous utilisez les deux fournisseurs pendant une migration, combinez-les comme indiqué plus bas, puis supprimez l'ancien une fois la migration terminée.

Google Workspace plus un service d'envoi

Ajoutez l'include du service d'envoi à côté de celui de Google. Gardez un seul enregistrement, avec les deux include avant la terminaison.

v=spf1 include:_spf.google.com include:YOUR_SPF_HOST ~all

Remplacez YOUR_SPF_HOST par la valeur de votre tableau de bord MigoSMTP, ou par celle du service que vous utilisez.

Microsoft 365 plus un service d'envoi

Le même principe s'applique. Deux include, un seul enregistrement.

v=spf1 include:spf.protection.outlook.com include:YOUR_SPF_HOST ~all

Authentifiez aussi le service d'envoi avec DKIM, afin que DMARC puisse réussir grâce à la signature DKIM lorsque SPF n'est pas aligné.

Ajouter votre propre serveur par adresse IP

Si vous exploitez un serveur qui envoie du courrier, comme une application web ou un ancien serveur de messagerie, indiquez son adresse avec ip4. Vous pouvez ajouter une plage en notation CIDR.

v=spf1 include:_spf.google.com ip4:203.0.113.10 include:YOUR_SPF_HOST ~all

N'utilisez que des adresses que vous contrôlez, et retirez-les lorsque le serveur est mis hors service.

Autres fournisseurs de messagerie

D'autres fournisseurs, comme Zoho, publient leurs propres valeurs include, et certains ont des valeurs différentes selon les centres de données. Copiez toujours la valeur depuis la page d'aide du fournisseur pour votre région, et non depuis un article de blog.

Le principe ne change pas : un enregistrement, un include par expéditeur, une seule terminaison.

Vérifier votre nombre de requêtes

Chaque include compte comme une requête, et l'include d'un fournisseur peut lui-même contenir d'autres include. Les enregistrements de Google et de Microsoft utilisent chacun plusieurs requêtes en interne ; les combiner avec quelques services peut donc atteindre la limite de dix plus vite qu'on ne le pense.

Notre vérificateur gratuit et la plupart des outils de test SPF comptent les requêtes pour vous. Si vous approchez de la limite, supprimez les expéditeurs que vous n'utilisez plus et envisagez d'envoyer différents types de courrier depuis différents sous-domaines, chacun avec son propre enregistrement.

Envoyer depuis un sous-domaine

De nombreuses équipes envoient leurs messages marketing ou transactionnels depuis un sous-domaine tel que mail.yourdomain.com. Le sous-domaine a son propre enregistrement SPF, distinct de celui de la racine, ce qui garde chaque enregistrement court et la racine propre.

N'oubliez pas que DMARC s'applique aussi aux sous-domaines ; vérifiez donc l'alignement pour le courrier du sous-domaine.

Consulter un enregistrement en ligne de commande

Vous pouvez lire l'enregistrement SPF de n'importe quel domaine avec une requête DNS. Sous Linux et macOS, utilisez dig ; sous Windows, utilisez nslookup. Les deux affichent les enregistrements TXT à la racine, et celui de SPF commence par v=spf1.

dig +short TXT yourdomain.com

Si vous voyez deux enregistrements commençant par v=spf1, fusionnez-les. Si vous n'en voyez aucun, publiez-en un. Relancez la requête après chaque modification, car votre panneau DNS peut afficher une valeur qui ne s'est pas encore propagée.

Un exemple de calcul des requêtes

Supposons qu'un enregistrement contienne include:_spf.google.com, include:YOUR_SPF_HOST et ip4:203.0.113.10. Le ip4 ne coûte rien. Chaque include coûte une requête, plus celles contenues dans l'enregistrement propre à ce fournisseur. Un fournisseur dont l'enregistrement contient trois autres include coûte donc quatre requêtes au total.

Additionnez les totaux de chaque include. Si vous arrivez à dix ou moins, tout va bien. Si vous dépassez dix, SPF échoue pour tout le monde ; réduisez donc les expéditeurs ou déplacez une partie du courrier vers un sous-domaine avant de publier.

Changer de fournisseur sans interruption

Lorsque vous passez d'un service d'envoi à un autre, conservez l'ancien include dans l'enregistrement pendant que vous ajoutez le nouveau, envoyez une petite part du courrier par le nouveau service, et ne retirez l'ancien include que lorsque l'ancien service n'envoie plus rien.

Le retirer trop tôt fait échouer SPF pour tout message qui passe encore par l'ancien service. Nos guides de migration reprennent la même approche de chevauchement pour le DNS, les clés et les modèles.

Quand SPF ne suffit pas

SPF ne vérifie que l'expéditeur de l'enveloppe et échoue en cas de transfert ; les destinataires examinent donc aussi DKIM et DMARC. Un enregistrement qui réussit SPF mais sans signature DKIM ni enregistrement DMARC n'est que partiellement authentifié.

Mettez en place les trois. Notre guide DMARC explique comment publier un enregistrement en toute sécurité et lire les rapports.

Pour aller plus loin et sources

• RFC 7208 : Sender Policy Framework (SPF)
• Google Workspace : définir votre enregistrement SPF
• Microsoft : configurer SPF pour éviter l'usurpation d'identité

Faites-le dans MigoSMTP : articles du centre d'aide

• Corriger l'erreur permanente SPF et la limite de 10 requêtes
• Authentifier un domaine d'envoi dans MigoSMTP : SPF, DKIM et DMARC
• Vérifier votre domaine d'envoi : enregistrements DNS et propagation

Guides et outils associés

• Vérificateur d'enregistrement SPF : consultez un enregistrement et comptez ses requêtes DNS.
• Générateur d'enregistrement SPF : construisez un enregistrement à partir de vos expéditeurs.
• Comment configurer DMARC : commencez avec p=none et passez à reject en toute sécurité.