Expéditeur non vérifié dans Outlook : sens et correction

Quelle méthode choisir ?

Utilisez la configuration d’envoi de la route de production en échec.

Si une seule application produit l’avertissement, examinez ses réglages d’authentification de domaine. Ne touchez pas à la configuration du courrier des boîtes Microsoft 365 sans lien, qui s’authentifie déjà correctement. Si l’application propose un return-path ou un domaine DKIM personnalisé, générez les enregistrements dans ce compte pour le domaine configuré. Ces valeurs sont propres au compte.

Une adresse IP dédiée n’authentifie pas l’identité From visible. Elle peut peser sur les décisions d’infrastructure ou de réputation, mais ne remplace ni l’autorisation SPF, ni la signature DKIM, ni l’alignement DMARC.

Si une passerelle de sécurité modifie les en-têtes ou le corps après la signature d’un service, déterminez quel système autorisé signe en dernier. Une modification ultérieure peut casser DKIM. La correction peut relever de la passerelle ou du processus de signature de l’expéditeur final.

Pour la configuration par fournisseur, voir les guides d’authentification e-mail de Palisade.

Configurer SPF et DKIM pour l’envoi vers Outlook

1. Ouvrez les réglages du système qui a envoyé le message concerné

Identifiez l’application à partir du routage et des en-têtes du message livré. Ouvrez ses réglages de domaine d’envoi ou d’authentification, plutôt qu’un réglage de boîte Outlook sans rapport.

Pour les boîtes hébergées par Microsoft, suivez la procédure d’administration Microsoft 365 documentée du tenant. Pour un expéditeur tiers, suivez sa procédure d’authentification de domaine. L’avertissement d’Outlook est une preuve côté destinataire. Il n’indique pas quelle console détient la correction.

2. Notez les identités du message concerné

Choisissez le domaine From visible affiché avec l’avertissement, puis recueillez ces preuves dans le message original :

• Domaine From visible : le domaine après @ dans l’adresse From RFC 5322 montrée au destinataire.
• Return-Path ou adresse d’envoi : l’identité d’enveloppe, si le système de réception l’expose.
• Authentication-Results : résultats SPF, DKIM et DMARC ajoutés par un système de réception fiable.
• DKIM d= : le domaine de signature dans DKIM-Signature.
• Système d’origine : le tenant Microsoft 365, l’application, le relais SMTP ou l’autre expéditeur qui a généré le message.

Exemple d’en-tête expurgé :

Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=mailer.example;
 dkim=pass header.d=mailer.example header.s=selector1;
 dmarc=fail header.from=yourdomain.com

Cet exemple montre pourquoi un indicateur d’expéditeur non vérifié peut apparaître même si SPF ou DKIM réussit. Les domaines SPF et DKIM de l’exemple sont mailer.example, alors que le domaine From visible est yourdomain.com. Un succès pour un identifiant sans rapport n’établit pas l’alignement DMARC. L’indicateur et un résultat réussi ne prouvent pas non plus que le message est malveillant, qu’Outlook a décidé uniquement d’après DMARC, ni qu’un seul changement DNS supprimera l’avertissement.

3. Publiez les enregistrements générés

Ne publiez que les enregistrements SPF ou DKIM générés par le service et le compte qui envoient le message. SPF est une politique TXT pour le domaine d’expéditeur d’enveloppe. DKIM est souvent un TXT sous _domainkey, mais certains expéditeurs délèguent par CNAME.

Enregistrement SPF : TXT

Hôte, à titre d’exemple :

yourdomain.com

Valeur, à titre d’exemple :

v=spf1 include:sender.example -all

Enregistrement DKIM : TXT

Hôte, à titre d’exemple :

selector1._domainkey.yourdomain.com

Valeur, à titre d’exemple :

v=DKIM1; k=rsa; p=ZmFrZS1leGFtcGxlLWtleS1ub3QtYS1yZWFsLWRraW0ta2V5

Ne publiez pas ces exemples. Copiez l’hôte exact et la valeur complète générés par le service d’envoi pour le compte et le domaine que vous configurez.

Un domaine n’a qu’un enregistrement de politique SPF. Après avoir confirmé que l’expéditeur l’exige, fusionnez le mécanisme requis dans la politique existante plutôt que de publier un second TXT SPF. N’écrasez pas un sélecteur DKIM actif sauf si l’expéditeur documente une procédure de rotation.

Beaucoup d’interfaces DNS ajoutent le nom de zone au champ hôte. Si la zone est yourdomain.com, saisir selector1._domainkey.yourdomain.com peut créer un nom en double. Vérifiez le nom pleinement qualifié final avant d’enregistrer.

4. Vérifiez la configuration dans le service d’envoi

Revenez à la page d’authentification de l’expéditeur et attendez son statut de vérification. Il confirme ce que cet expéditeur peut évaluer pour la configuration choisie. Un voyant vert du fournisseur ne prouve pas que l’application concernée a utilisé la route configurée pour le message marqué par Outlook.

5. Envoyez un nouveau message par la même route

Envoyez un nouveau message depuis l’application, le tenant, le relais et la passerelle en cause. Livrez-le à une boîte dont vous pouvez lire toute la source.

Ne validez pas avec un message envoyé avant le changement DNS, un test interne qui contourne le relais de production ou une autre application. Ces chemins peuvent utiliser d’autres domaines de return-path, sélecteurs, signatures et transformations.

Quel effet sur DMARC ?

DMARC compare le domaine From visible aux identifiants SPF et DKIM. La RFC 9989 définit l’alignement DMARC entre le domaine From RFC 5322 et le domaine SPF ou DKIM authentifié. SPF n’aide que si le domaine d’expéditeur d’enveloppe qui réussit est aligné avec le domaine From visible. DKIM n’aide que si le domaine de signature d= qui réussit est aligné avec lui.

Utilisez le test DMARC de Palisade pour inspecter la politique publiée du domaine From visible. Le test accepte un domaine public et peut afficher l’enregistrement DNS actuel. Il ne peut pas inspecter le message concerné, dire pourquoi Outlook l’a marqué, ni prouver que l’expéditeur de production utilise les identités authentifiées attendues.

Valider la configuration

Vérifiez le DNS

Interrogez la politique SPF ou le sélecteur DKIM exact généré pour l’expéditeur. Comparez la réponse faisant autorité avec au moins un résolveur public. Pour un contrôle indépendant, utilisez l’outil de requête DNS de Palisade, ou le test DKIM pour un sélecteur précis.

dig +short TXT selector1._domainkey.yourdomain.com
dig +short TXT yourdomain.com

Confirmez le nom final et la valeur complète. Le DNS public ne prouve pas que l’expéditeur signe les e-mails, utilise le return-path attendu ou fait l’objet d’une décision privée de Microsoft.

Statut de l’expéditeur

Vérifiez que le compte d’envoi indique le domaine ou les enregistrements comme vérifiés. Notez le domaine, le compte et l’heure de vérification. C’est une preuve côté fournisseur seulement.

Inspectez un message livré

Ouvrez la source originale d’un nouveau message de test livré. Comparez le domaine From visible, le Return-Path s’il existe, la DKIM-Signature (valeurs d= et s=) et les Authentication-Results de confiance avec les preuves recueillies avant le changement.

Utilisez l’analyseur d’en-têtes e-mail pour lire les résultats d’authentification et comparer ces identités. Fiez-vous aux résultats ajoutés par un récepteur de confiance ; un en-tête collé ne dit pas, seul, pourquoi Microsoft a affiché l’avertissement.

N’acceptez la correction que si le chemin de production donne les preuves d’authentification attendues et qu’un succès SPF ou DKIM est aligné avec le domaine From visible là où DMARC s’appuie sur ce mécanisme.

Lisez les rapports DMARC

Une fois des rapports agrégés accumulés, vérifiez si la source d’envoi réussit SPF ou DKIM et s’aligne avec le domaine From visible. Séparez la source corrigée de tous les autres expéditeurs de ce domaine. Les rapports DMARC montrent le trafic signalé dans le temps, mais ne garantissent pas qu’Outlook n’affichera plus jamais d’indicateur.

Dépannage

SPF réussit, mais l’avertissement reste

Comparez smtp.mailfrom dans les Authentication-Results fiables au domaine From visible. Un succès pour un return-path du fournisseur peut ne pas être aligné avec le domaine From. Configurez un return-path personnalisé pris en charge ou un DKIM aligné, si le service d’envoi le permet.

DKIM réussit, DMARC échoue

Comparez header.d= au domaine From visible. Une signature DKIM valide pour un domaine du fournisseur peut réussir DKIM mais échouer à l’alignement DMARC. Configurez le domaine authentifié ou de signature de l’expéditeur pour le domaine From visible.

L’expéditeur indique « vérifié », mais le message livré diffère

Inspectez le chemin de relais et le sélecteur du message. L’application contourne peut-être le profil d’envoi configuré, ou une passerelle en aval modifie le message après la signature. Testez la même route de production et déterminez quel système signe après les modifications autorisées.

Le DKIM publié ne se résout pas

Cherchez un suffixe DNS dupliqué, une valeur TXT tronquée, ou un écart entre le sélecteur du message et celui publié dans le DNS. Vérifiez le nom pleinement qualifié selon les instructions générées par l’expéditeur avant de modifier l’enregistrement.

Un nouveau SPF a cassé un autre envoi

Rétablissez la dernière politique SPF fonctionnelle, puis fusionnez le mécanisme requis dans l’unique enregistrement existant. Plusieurs politiques SPF pour un même domaine créent une configuration ambiguë que les destinataires peuvent traiter en erreur permanente.

Suivez les sources d’envoi en cause

Une fois un message de test corrigé réussi, il reste à repérer les autres sources de production du même domaine From visible qui échouent plus tard à l’authentification ou à l’alignement. Palisade est un logiciel DMARC agentique : il analyse les données des rapports agrégés DMARC, identifie les sources d’envoi et les problèmes d’authentification ou d’alignement, et crée des tickets de correction priorisés. Un humain examine les preuves et applique tout changement DNS ou de politique DMARC.

Commencez avec Palisade

Palisade ne peut retirer l’indicateur privé d’Outlook, changer la décision de Microsoft, garantir l’arrivée en boîte de réception ni prouver que tout message futur s’authentifiera.