Un sous-domaine a-t-il besoin d’un SPF ?

Quand un sous-domaine exige son propre SPF

Appliquez cette règle à chaque chemin d’envoi en production :

• Si le sous-domaine est le vrai domaine MAIL FROM, publiez et tenez à jour le SPF à ce sous-domaine exact.
• Si le MAIL FROM est vide et que le sous-domaine figure en HELO ou EHLO, publiez et tenez à jour le SPF à ce domaine HELO.
• Si le sous-domaine n’apparaît que dans le From visible, examinez le message livré avant d’ajouter SPF. L’identité SPF peut différer.
• Si le sous-domaine n’est jamais une identité SPF, le SPF parent ne le couvre pas, mais il peut ne pas avoir besoin d’autorisation d’envoi.

Exemple courant : un expéditeur transactionnel utilise mail.yourdomain.com dans le From visible, mais un chemin de retour géré par le fournisseur sous bounce.yourdomain.com. Le SPF utile est celui de bounce.yourdomain.com, si c’est bien l’identité MAIL FROM du message livré. N’ajoutez pas de SPF à mail.yourdomain.com sur la seule foi du From visible.

Ne remplacez pas un TXT SPF existant en en ajoutant un second. Regroupez les mécanismes autorisés dans la politique SPF unique de ce nom exact, puis vérifiez le chemin d’envoi avant de retirer une autorisation existante.

Exemple d’enregistrement SPF

Exemple seulement. Ne publiez pas cet enregistrement tel quel. Utilisez les valeurs d’autorisation générées par le fournisseur et vérifiez quelle identité MAIL FROM ou HELO ses messages de production utilisent.

bounce.yourdomain.com. IN TXT "v=spf1 include:spf.example-provider.com -all"

Cet exemple autorise le fournisseur du mécanisme include à envoyer avec bounce.yourdomain.com comme identité SPF évaluée. Il ne l’autorise pas pour yourdomain.com, news.yourdomain.com ni aucun autre nom voisin.

Une preuve concrète part du message livré. Cherchez des champs comme :

Return-Path: <bounces@bounce.yourdomain.com>
Authentication-Results: recipient.example;
    spf=pass smtp.mailfrom=bounce.yourdomain.com

L’en-tête Authentication-Results, ajouté par le système de réception, peut montrer le résultat SPF et l’identité évaluée. La RFC 8601 définit l’en-tête Authentication-Results. Son format et ses propriétés varient selon le destinataire : utilisez le message livré par la route de production exacte, pas l’en-tête d’un autre expéditeur.

Vérifiez le sous-domaine selon vos preuves

Si vous avez un message livré, examinez d’abord son Return-Path et ses résultats d’authentification. Notez la valeur smtp.mailfrom si elle existe. C’est le meilleur point de départ pour savoir quel nom DNS exige une politique SPF.

Si vous avez l’accès DNS mais aucun message, listez chaque plateforme d’envoi et demandez quel chemin de retour, expéditeur d’enveloppe ou identité HELO elle utilise. L’écran de configuration d’un fournisseur montre l’identité prévue, sans prouver que le message de production l’utilise.

Validez sur quatre couches :

• Interrogez le DNS faisant autorité et au moins un résolveur public pour le domaine évalué exact, comme bounce.yourdomain.com.
• Vérifiez que le fournisseur indique son domaine authentifié ou son chemin de retour comme vérifié, s’il affiche un statut.
• Envoyez un vrai message via la plateforme et vérifiez dans les en-têtes un SPF réussi sur l’identité attendue.
• Examinez les rapports agrégés DMARC une fois accumulés pour trouver les sources ou échecs d’alignement manqués par un test.

Si SPF réussit mais que DMARC échoue, comparez le domaine authentifié par SPF au domaine From visible et revoyez DKIM pour les sous-domaines. DKIM peut fournir le résultat aligné quand SPF utilise un autre domaine. Pour l’inventaire des enregistrements DNS de messagerie, voir les enregistrements DNS d’un domaine e-mail professionnel.

Vérifiez le SPF du sous-domaine d’envoi

Commencez par le sous-domaine exact du message livré, comme bounce.yourdomain.com. Comparez le SPF public à l’identité indiquée par le fournisseur et les en-têtes de production.

Vérifiez le SPF du sous-domaine

Un test DNS ne prouve pas que tout expéditeur de production utilise ce sous-domaine, ne répare pas un chemin défaillant et ne montre pas le futur placement d’un destinataire.

Pour suivre de nombreux domaines ou sources d’envoi, Palisade est un logiciel DMARC agentique qui analyse les rapports agrégés DMARC, repère les sources d’envoi et les problèmes d’authentification ou d’alignement, et crée des tickets de correction priorisés. Il peut proposer la prochaine étape de politique DMARC à un humain, mais ne modifie pas la politique DMARC et ne garantit pas la livraison.

Commencez avec Palisade

Comparez parent et sous-domaine d’envoi sans deviner

Le SPF à inspecter est celui de l’identité évaluée par le destinataire. Ce message d’exemple utilise des domaines From visible et d’enveloppe différents :

From: Updates <updates@news.example.com>
Return-Path: <bounces@bounce.example.com>
Authentication-Results: receiver.example;
    spf=none smtp.mailfrom=bounce.example.com

Utilisez les résultats ajoutés par un système de réception de confiance. Un en-tête copié ou douteux n’est pas une preuve indépendante. Ici, l’identité SPF est bounce.example.com : vérifier seulement example.com ou news.example.com répondrait à la mauvaise question. La RFC 7208 définit l’identité MAIL FROM de ce contrôle.

dig TXT example.com +short
dig TXT bounce.example.com +short

Ces domaines ne sont pas des valeurs à déployer. Commencez par le test SPF du domaine évalué exact, lisez la valeur brute avec la recherche d’enregistrement TXT et examinez le message avec l’analyseur d’en-têtes. Gardez une délégation CNAME exigée par le fournisseur au lieu d’ajouter un TXT conflictuel à ce nom.

Enquêtez sur l’identité d’envoi avec Palisade MCP

Palisade MCP peut comparer les preuves d’authentification disponibles et expliquer le contrôle suivant. Suivez le guide d’installation MCP, puis remplacez les champs par les identités d’une même route d’envoi. Ne mettez pas de contenu privé dans le prompt.